UX9: Design systems and handover
Handover and checking the build
🎯You'll be able to
Hand designs to developers with everything they need, and review the built product against the design.
🏠The everyday picture
An architect gives builders drawings with measurements, materials and notes, then visits the site to check the walls are where they should be. A drawing alone doesn't build a house.
📘What it really is
- What developers need:
- the journey and flows, including errors and empty screens (UX4);
- every screen at phone and wider sizes;
- components and tokens by name, not pixel values ("primary button",
--space-4); - every state, with behaviour ("Continue is disabled until a time is chosen; pressing it early shows 'Choose a time first'");
- accessibility notes: names, roles, states, focus order, what is announced;
- content: the exact words, including error messages;
-
what's out of scope.
-
Acceptance criteria: testable statements, like the kit's tests: "Every page passes axe with no serious problems"; "the details are kept after Change time".
-
Talk early and often: short check-ins while building catch problems sooner than a big review at the end.
- Review the build (design QA): compare with the design at real sizes, try each state, use the keyboard and a screen reader, and log differences with screenshots and the expected behaviour.
📝A worked example
Input: a handover note for the slot screen.
| Item | Note |
|---|---|
| Component | Time slot (button.slot), primary button (.btn.btn-primary) for Continue |
| States | Default, selected (aria-pressed="true", tick), focus, disabled (booked) |
| Behaviour | Choosing a time updates the status line Selected: HH:MM on <date>; Continue enabled after a choice |
| Announcements | The status line uses role="status" |
| Layout | Grid repeat(auto-fill, minmax(7rem, 1fr)), gap --space-3 |
| Acceptance | Test 3 (keyboard), test 7 (targets), test 8 (320 px) |
Expected output: a developer can build the screen from the note and the component page without asking what happens when.
🌍Where it's used
- Product teams with a design QA step before release.
- Agencies handing over to a client's developers.
- Open-source projects, where contributors build from written specifications.
📝Case scenario
A handover file showed every screen but not the error states. Developers invented their own messages: "Validation failed (code 7)". Users complained. The team added an error-state page and exact wording to every handover after that.
🖱️Try it
Write a handover note for the details screen, following the table above. Success: it covers components, states, behaviour, announcements, content and acceptance criteria, and names tokens instead of pixel values.
⚠️Common mistakes
- Pixel values instead of tokens. Sign: "16px gap". Fix:
--space-4. - Missing states and words. Sign: developers write error messages. Fix: include exact content and every state.
- No build review. Sign: differences found by users. Fix: design QA before release.
🛠️For your project
The kit's acceptance tests are a model for handover criteria; the capstone's README section for the next team is a handover.
✅Quick check
Why name tokens and components in a handover instead of pixel values?
Show the answer
So developers use the system and the build stays consistent when tokens change.
What is design QA?
Show the answer
Reviewing the built product against the design: sizes, states, keyboard, screen reader and content.