DSN 325 · UI Design & Design Systems · Week 6 of 7
Slow Down
Three QA passes, a slop hunt, and a workflow that actually works.
Fast weeks make things. Slow weeks make things right. This week you inspect last week's build like a professional — three passes, documented fixes — then push past the prototype: a working version of your core flow where the empty, loading, and error states actually function.
This week at a glance
Wed 11:59 pm
Studio A: QA Pass — three passes, documented fixes (early on purpose: Studio B builds on it)
Fri 11:59 pm
Studio B: End-to-End Working Flow — edge states functioning
Fri 11:59 pm
Discussion: Share thread — The Slop I Caught
Fri 11:59 pm
Field Work: Case Study Scouting — post your findings
Sun 11:59 pm
Replies: share thread (2 classmates) and Field Work (1 classmate)
1The three passes
Design QA is inspection with a checklist, not a vibe check. You'll run three passes over your prototype, in this order, and log every issue and fix.
Pass 1 — Usability
Walk your flow as a stranger. Use the Week 1 heuristics as your checklist: does every screen tell you where you are? Can you undo? Are the words the user's words? Does anything make you think twice?
Pass 2 — Accessibility
The measurable one. Contrast ratios on every text/background pair (4.5:1 body). Keyboard: can you reach and use everything with Tab and Enter alone? Focus visible on every interactive element? Touch targets big enough? Run an automated scan too — then catch what it missed, like you practiced in Field Work.
Pass 3 — Consistency
Your kit is the law. Every button, every spacing value, every color in the build gets checked against it. AI tools drift — a near-match teal here, a 14px gap in a 16px rhythm there. Zoom in. This is where the subtle slop hides.
What a QA log entry looks like
Issue, location, pass that caught it, severity, fix. One line each. Screenshots for anything subtle.
Do — issue / where / fix, one line eachDon't — "looks good overall" is not a QA log
2Make it real: the end-to-end flow
What "working" means
Using an AI coding tool (Claude, Lovable, Codex — your pick), build your core flow so a user can actually:
Start the task and move through it
Hit the empty state — first use, nothing there yet, with a way forward
See the loading state — something honest happens while they wait
Recover from an error — something fails, the message says what and what to do, and the user gets back on the path
Finish — and know they finished
No accounts, no databases, no app stores. Simulated data is fine — a "Fail this request" test button is a legitimate way to show your error state. The point is that the states are real behavior, not pictures.
The trap this week: polishing the happy path and bolting on sad states at 11 pm Friday. Build the error state early — it's the hardest one to fake and the first one the share thread will test. Your classmates will be clicking your flow trying to break it. Give them nothing.
3How to do this week's work
Studio A first — QA the prototype, due Wednesday. Three passes in order: usability, accessibility, consistency. Include the mobile check: your flow at 375px wide, everything that breaks logged. Log every issue: what, where, which pass, severity, fix. Fix what you log. Studio B builds from this — that's why it's due early.
Screenshot the subtle ones. The 2px drift, the near-match color. These are your share-thread material and your case-study evidence.
Studio B — build the working flow. Feed your QA'd design to your coding tool. Direct it screen by screen — piecework mode. Get the happy path working, then break it on purpose: build empty, loading, and error for real.
Test like an enemy. Refresh mid-task. Submit nothing. Submit garbage. Every dead end you find now is one your classmates can't find Friday night.
Post to the share thread: QA findings + working flow link. Lead with the subtlest catch. Then reply to two classmates — test-drive their flows and report one thing that held and one that didn't.
Field Work — scout case studies. Read two real portfolio case studies from the curated list. Note where each shows decisions versus just screens, and where you stopped reading. Next week you write your own; know what good looks like first.
AI this week, both directions: the coding tool builds your flow (disclose, as always — your prompts and corrections belong in the disclosure). And AI can help audit — ask it to review your build against WCAG. But remember your Field Work finding: automated checks miss things. The scanner is a pass, not a verdict. Your eye makes the verdict.
4Resources
Everything here is free. Start with the starred items.
★The A11y Project Checklist — Your itemized accessibility pass.
How to Meet WCAG — Quick Reference — W3C. The full rulebook, filterable.
Web Accessibility for Designers — WebAIM. One page, a designer's view.
Accessibility Dos and Don'ts posters — UK Home Office.
axe DevTools — Deque's free browser extension. Your automated scanner.
★10 Usability Heuristics — Nielsen Norman Group. Week 1's list, now your checklist.
Inclusive Components — Heydon Pickering. How components should behave for everyone.
QA checklist and accessibility checklist — two course handouts. Your three passes get documented on these.
Build walkthrough and starter scaffold — course handout plus a working demo file. How to push past a prototype so the empty, loading, and error states really function.
Your build tool — Claude, Lovable, or Codex. Whichever your test drive and Week 5 build earned trust in.
Design QA and accessibility audit walkthroughs — Video; Deque and Chrome Developers both have good ones.
Case Study Scouting — for Field Work. The curated case-study list comes with this week's materials. Bestfolios if you want more than the curated two.
5Before you submit
All three QA passes run, in order, on the whole flow
QA log: every issue with what / where / which pass / severity / fix
At least one subtle catch screenshotted (drift, near-match color, missing focus)
Contrast measured on every text pair; keyboard walk completed
Working flow: start → empty → loading → error → recovery → done, all functioning
I tried to break my own flow and fixed what broke
Both posted to the share thread, subtlest catch first
AI disclosure covers the audit help and the build direction
Field Work posted: two case studies scouted with notes