Design Spec Writing

Why Most Specs Fail

Engineers don't read specs because specs are usually:

1. Too long (nobody reads 40 pages)
2. Too vague ("the button should feel responsive")
3. Out of date (the design changed but the spec didn't)
4. Redundant with the Figma file (so why bother?)

What a Good Spec Contains

1. Overview (1 paragraph)

What this feature is, who it's for, and why it exists. Link to the product brief.

2. User Flow (visual)

Flowchart or numbered steps showing the complete path. Include error paths and edge cases.

3. Screen-by-Screen Spec

For each screen:

## [Screen Name]

**Entry point:** How does the user get here?
**Primary action:** What's the main thing they do?
**Exit points:** Where can they go from here?

### States
- Default: [description + link to Figma frame]
- Loading: [description]
- Empty: [description]
- Error: [description + error messages]
- Success: [description]

### Interactions
- [Element]: [Behavior on click/hover/focus]
- [Element]: [Behavior on click/hover/focus]

### Content
- [Field]: [Character limits, formatting rules]
- [Field]: [Validation rules, error messages]

### Edge Cases
- What happens when [unlikely but possible scenario]?
- What if the user [does something unexpected]?