🎯 Learning Objectives
By the end of this lesson, you will:
- Understand why design files are a form of specification
- List all interactive states that must be present in any design
- Apply a 4-area checklist when reviewing Figma mockups
- Know the golden rule: "If it's not in the mockup, it's not a requirement"
🎨 Figma Is a Spec
When a developer asks "what should the button look like when it's disabled?" — the answer should be in the Figma file. If it isn't, the developer will invent an answer. The QA tester will test against a different assumption. The designer will be surprised by the result.
Design mockups are specifications. They just use pictures instead of words.
Reviewing them requires the same systematic approach as reviewing a text spec. And it's most valuable before development starts.
📋 The Mockup Review Checklist
Area 1: Interactive States ⚡
Every interactive element must have designs for all possible states:
| Component | States to check |
|---|---|
| Buttons | Default, Hover, Active/Pressed, Focused, Disabled, Loading |
| Input fields | Default, Focused, Filled, Error, Disabled, Read-only |
| Links | Default, Hover, Visited, Active |
| Checkboxes/Radios | Unchecked, Checked, Indeterminate (checkboxes), Disabled |
| Dropdowns | Closed, Open, Selected, Disabled |
| Cards/List items | Default, Hover, Selected, Loading skeleton |
💡 Tip: Open Figma and systematically click through every component. For each one, ask: "Is there a frame for every state in this list?"
Area 2: Content States 📄
The mockup might show a full list — but what happens in edge cases?
| Content state | What to check |
|---|---|
| Empty state | What does the user see when there's no data? Blank screen? Illustration? Call to action? |
| Loading state | Is there a skeleton screen or spinner design? |
| Error state | What does the page/component look like when something fails? |
| Single item | Does the list design still work with just 1 item? |
| Long content | Does the card design handle very long names or descriptions? |
| Truncation | Where does text truncate? With "..." or without? |
Area 3: Grid, Spacing & Typography 📐
Design consistency issues will become implementation inconsistencies:
- Does the spacing follow the grid (e.g., 8px grid)?
- Are font sizes consistent with the design system?
- Are component names in Figma consistent across all screens? (e.g., "Primary Button" everywhere, not "Button" in one place and "CTA" in another)
Area 4: Responsive Breakpoints 📱
If the product supports multiple screen sizes:
- Is there a design for each breakpoint? (e.g., 320px mobile, 768px tablet, 1280px desktop)
- Does the navigation work at each size?
- Do long lists become scrollable at mobile?
- Are touch targets large enough at mobile (minimum 44×44px)?
🌍 The Golden Rule
"If it's not in the mockup, it's not a requirement."
When a developer asks "what should happen when X?" and there's no design screen for X — they make something up. That something becomes the implementation. That implementation gets tested against an expectation that also doesn't exist in writing.
This is how "it works as designed" and "this is a bug" can both be true at the same time.
Your job in a design review: find every X that doesn't have a screen.
📝 How to Leave a Design Review Comment
Leave comments directly in Figma (or whatever tool your team uses). Be specific:
Weak comment: "Missing states."
Strong comment:
"Button on this screen doesn't have a disabled state designed. The spec says the Submit button should be disabled until all required fields are filled in. Could we add a disabled variant?"
Good design review comments:
- Reference the specific component and screen
- Link to the spec if possible
- Describe the expected state
- Ask a question, don't demand a change
💡 Pro Tips
💡 Tip 1: Make "all interactive states" your default checklist item. You'll be amazed how often the hover and disabled states are missing.
💡 Tip 2: Test long text in designs mentally. If the product name is "A" in the mockup, ask: what happens when it's "A Very Long Company Name That Wraps Around"? If the design breaks — flag it.
💡 Tip 3: Annotate your Figma comments like bug reports: component, location, expected, actual, severity. This makes them much easier to act on.
📋 Summary
- Figma mockups are specifications — review them with the same rigor as text specs
- Interactive states: every button/input/dropdown needs all states designed
- Content states: empty, loading, error, long text, single item
- Grid & spacing: consistency with design system
- Responsive: all breakpoints covered
- Golden rule: if it's not in the mockup, it's not a requirement
Up next: the most overlooked design problem — the screens that don't exist yet.