AI / Design Communication & Image Prompting
Turn a Requirement into a Design Spec
The developer who picks it up should not need to ask you anything
Turn the requirement below into a design spec (no code). Include: 1) The actions the user must complete, in order; 2) The UI elements and states at each step; 3) Exceptions and edge cases; 4) What not to do (explicit exclusions); 5) Acceptance criteria. [requirement]
How to use
Write the exclusions first; most rework comes from what nobody wrote down.
Good for
- The requirement is clear in your head but goes to a developer or contractor who lacks the context — pinning the action order, each step's states, and the exclusions removes most of the back-and-forth.
- You want to self-check for gaps before a requirements review — writing the spec exposes the exception cases nobody thought about, which beats being caught out in the meeting.
Not for
- The requirement is still exploratory and may be thrown out entirely — a detailed spec now is fancy packaging for a draft; align direction with low-fidelity sketches first.
- It hinges on hard technical constraints (performance ceilings, third-party API limits) you do not understand — the spec will describe something impossible; check feasibility with the developer first.
Example
Input
Build 'invoice header management': users save common invoice headers, pick one at checkout, and can also add one on the spot
What you get
Steps are written out: enter checkout, tap 'choose header', the list marks a default, selection returns and fills the field. Exceptions cover empty headers, the 20-item cap, malformed tax IDs, and concurrent edits. Exclusions are explicit: no edit history, no automatic company-registry validation. Acceptance criteria are checkable sentences, e.g. 'returning to checkout shows the header filled in and not directly editable'.
Common mistakes
- Writing only the happy path and leaving exceptions and edge cases blank — the developer guesses, and the gap surfaces during integration, which is the most expensive time to find it.
- Skipping 'what not to do' as optional — without exclusions the developer adds features on their own reading, and both scope and schedule slip.
Try tweaking it like this
- Move 'what not to do' to item 1 and require a reason for each — boundaries first make every later step easier to write and easier to defend in the meeting.
- Add 'every acceptance criterion must be writable by QA as a single test case' — vague lines like 'the experience should feel smooth' get filtered out on the spot.