Lab 8 — Digital Showroom Visual Review
START HERE · YOUR LAB FILES
Open these resources
Each card opens the supplied file. Keep these alongside the lab; open the same paths in your downloaded course folder when using your AI.
- 1PLATFORM_GUIDE.mdCourse guide · read before starting
PLATFORM_GUIDE.md - 2allocation-requirements.mdSupplied evidence · read this source
fixtures/allocation-requirements.md
Underlined filenames throughout the steps are clickable. A file you create yourself links to saving instructions, not a nonexistent download.
On this page
SESSION 08 / 35-minute practice lab / within a 2-hour session
Show whether a visual or keyboard problem prevents a person from using the product.
Matched annotated captures, a targeted accessibility result, an evidence packet and an intentional-change example.
Before you start · recall, then check
What made your regression observation reproducible? Apply the same idea to two screenshots taken on different machines.
Use about two minutes of the existing arrival/discussion time. Try in your own words, then check the source with a partner or coach. This is ungraded practice, not a new submission.
Need a hand? A supported route
Start with one viewport and keyboard journey; record the baseline before comparing candidates. Use the platform guide if Tab skips controls. A screenshot can suggest a problem, but it cannot establish keyboard behavior.
Time: 35 minutes
Team: groups of three
Quick start
First action: Open the local Launch preview and record your browser/viewport/zoom.
Finish with: Matched captures, accessibility evidence, a finding and an intentional-change note.
Step-by-step help for Session 08 — smaller steps, checkpoints and troubleshooting. Saving and asking for help.
Mac / Linux / Windows
Submission: prepare the deliverables below using the public-safe packet and review workflow. One PR per lab; private review is equally available. Never publish grades or personal information.
Record OS/browser/version, CSS viewport, zoom and display scaling. Use the platform guide's capture and keyboard routes; on macOS check Keyboard Navigation if Tab skips controls. Compare screenshots within the same OS/browser baseline; font smoothing differences alone are not bugs. The included target is the local launch preview; phone-width emulation is not a real-device test.
See the platform guide and included local lab track.
Scenario
The Community Launch preview lets visitors choose a package. Marketing says it “looks fine,” but a visitor reports trouble using it on a phone. Test R7 against both candidates. There is no menu, modal or overlay in this target.
Mission
Conduct a visual, responsive, and keyboard-accessibility review without confusing aesthetic preference for a defect.
Test matrix
| Viewport | Required check |
|---|---|
| Desktop 1440px | capture each candidate; activate Choose package and verify “Package selected” |
| Tablet 768px | readable labels, preview containment and reachable controls |
| Mobile 375px | compare document width to viewport; inspect clipping and reachability of Choose package |
| Keyboard-only | Tab to Choose package, check visible focus and activate with Enter or Space; verify the resulting text |
Keep OS/browser, viewport and zoom identical for each A/B comparison. Reload before each interaction run. Inspect the caption's computed foreground/background colors; measure contrast before making a numeric claim. A passing keyboard check is valid evidence—do not invent a focus trap.
For an approved intentional change, switch Theme from Community festival to Creative pop-up shop. The heading is designed to change to the selected theme; compare that change separately from layout defects. Candidate B is a comparison implementation, not an automatic accessibility certification.
Deliverables
- annotated screenshots with viewport and build details;
- targeted accessibility-check result;
- one evidence packet written in user-impact language;
- one intentional visual change that should be approved rather than reported as a defect.
Stretch
Use an AI visual review to generate hypotheses. Validate or reject each one through DOM, keyboard, or reproducible viewport evidence.
Product Studio homework — Make the product feel intentional
Refine typography, spacing, color and useful states. Record two design iterations overall, matched before/after captures, keyboard navigation, 375/768/1440-width and zoom checks; fix a real usability issue.
Budget two to three hours, including evidence and review preparation; ask for coaching or scope adjustment if blocked. Record progress using the milestone template in your own product repository, not the practice packet. See the complete project roadmap, GitHub workflow and small-model guide. The practice lab above remains separate from your individual product.
Leave with a next step
Use the existing closing/debrief time: explain one claim you verified, one limit and your next action. Reuse the lab’s artifacts; this adds no separate worksheet or graded test.
Practice evidence uses the lab submission workflow. Product Studio work belongs in your own product repository. These are different destinations.
Product Studio roadmap · Sharing and review guide
Opening the next session does not mark this one complete. Progress tracking is optional and does not award a credential.