Specs
The morning change design is approved. At 11 p.m., a developer opens the file and wonders: what happens if a subscriber taps Change at 7:29 and confirms at 7:31? The screens do not say. So the developer guesses, and the guess ships. A spec exists so that nobody has to guess.
The rule
A good spec answers the developer's questions before they are asked.
A spec (specification) turns a design into instructions someone can build and test. It covers:
- Structure and style, through components and tokens rather than hand-measured pixels: "Card / default, Button / primary / large, spacing
space-4." Design tools have inspect modes that show sizes and token names automatically, so the spec does not repeat them. - Behaviour: what each interaction does, including rules and timing. "The change window closes at 7:30 a.m. by the server's clock."
- States: every state of every component and screen. The next lesson covers these.
- Content: exact wording, maximum lengths and formats, such as "₹90" and "7:30 a.m.".
- Data: what the screen needs from the backend, such as the cook's name and the change deadline.
- Acceptance criteria: testable statements of done, often in the shape Given… when… then…
The inspect mode shows what the screen looks like. The spec's real value is everything a static screen cannot show: rules, intent and what happens in between.
Handoff is also a conversation, not a file thrown over a wall. Developers should see the design early, while it can still change, and walk through it with you before building.
The shortcut
Walk the flow as a sceptical developer and write down every "what if?" you hit: what if it is late, empty, slow, long, repeated, or wrong? Each answer goes into the spec.
Point to the parts
The Today card uses Card / default and Button / primary / large. Spacing and colour come from tokens, so no hand measurements are needed.
A spec is never quite finished at handoff. When a developer's question exposes a gap, write the answer into the spec itself, not only into a chat thread, so the next person who reads it gets the same answer.
Drills
Answer fast — trust the rule.
What does a spec add that a design tool's inspect mode cannot show?
Which of these is a testable acceptance criterion?
Why write "Button / primary / large" and space-4 instead of drawing measurements such as 47 px?
When should developers first see the morning change design?
Remember
- A good spec answers the developer's questions before they are asked.
- Shortcut: walk the flow as a sceptic; late, empty, slow, long, repeated, wrong?
- Trap: a spec that repeats what inspect mode shows but leaves out the rules.