Product Specification
A feature specification that covers states, edge cases and accessibility rather than only the happy path.
Definition
A specification defines what will be built precisely enough to implement and to test. Most specifications fail by describing only the successful case.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Fill it in
Loading your draft…
Saved in this browser only. Nothing is sent anywhere.
Definition
One paragraph. If it takes more, the scope is probably too large.
What the user achieves, and how you would verify it in a test.
Explicit boundaries prevent scope drift during build.
Behaviour
Steps, with the system's response at each.
Empty, loading, partial, error, success, offline, permission denied.
Zero, one, many, maximum, longest content, slowest response, permission variations.
Requirements
Keyboard, focus, labels, announcements, contrast, motion.
Every string the interface needs, written out, not described.
Anything requiring a decision before build. Assign each one.
The cases specifications usually omit
Each row is a question that gets answered either in the specification or by whoever is implementing it at the time, alone.
| Case | Question to answer | What ships without it |
|---|---|---|
| Nothing there yet | What does this show before any data exists? | A blank region that reads as a failure. |
| Too much, or too long | Maximum counts, longest string, what truncates and what wraps | A layout that breaks on the first real customer name. |
| Not permitted | Hidden, disabled with a reason, or visible and refused? | A control that fails silently for half the users. |
| Slow or offline | What is shown, what is queued, what is lost | A spinner with no end state. |
| Two people at once | Who wins, and what the loser is told | Silent overwrite, discovered later. |
| Time and place | Whose timezone, which locale, how dates and currency are formatted | A daily total that is wrong for anyone outside head office. |
| Accessibility contract | Role, name, keyboard behaviour, announced state | A feature that has to be rebuilt to be used at all. |
Specifying
Do
- Write each requirement so it can be verified, since an unverifiable requirement is a preference.
- Say what is deliberately not included, and why, so it is not re-litigated in review.
- Specify the behaviour, and leave the implementation to the people implementing it.
- Include the states and the accessibility contract in the same document, not in a separate pass that never happens.
Do not
- Do not describe only the successful path.
- Do not use words that cannot be tested: fast, intuitive, seamless, clean.
- Do not bury a decision in a comment thread. If it governs the build, it belongs in the specification.
- Do not let the specification and the built product drift apart silently. Update it, or mark it superseded.
Local chart
TPL·011 · Region VIII · Grid H3
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Often used with
These usually appear in the same screen or the same decision.
- Feature Idea to UX SpecificationAI·004 · AI workflow
- PRD to User FlowAI·002 · AI workflow
- Jobs to Be DoneRES·018 · Research method
- Design BriefTPL·010 · Template
- Story MapTPL·006 · Template
- User FlowTPL·005 · Template
- Axure RPTOOL·012 · Tool
- ConfluenceTOOL·045 · Tool
- NotionTOOL·044 · Tool
- ZeplinTOOL·043 · Tool
- Visual StatesFND·053 · UI foundation
- Design HandoffFLOW·002 · Workflow
- DiscoveryFLOW·004 · Workflow
Short definition
The one-paragraph version, for when that is all you need.
- Acceptance CriteriaTERM·095 · Term
- Edge CaseTERM·120 · Term
- HandoffTERM·112 · Term
- Happy PathTERM·119 · Term
- User StoryTERM·094 · Term