Design Review Checklist
A structured checklist for PM-led design reviews. Covers usability, accessibility, edge cases, copy, responsiveness, and handoff readiness — so nothing slips between design and build. Free to copy, download, and use. No signup required.
# Design Review Checklist **Feature:** [Feature name] **Designer:** [Name] **PM Reviewer:** [Name] **Date:** [Date] **Status:** [ ] Draft [ ] Reviewed [ ] Approved [ ] Needs revision --- ## 1. Requirements alignment | Criterion | Pass | Notes | |---|---|---| | Designs cover all user stories in the PRD | | | | Acceptance criteria are visually satisfied | | | | Out-of-scope items are not designed (no scope creep) | | | | Success metric is measurable from the designed flow | | | **Gaps / missing requirements:** [List any PRD requirements not addressed in designs] --- ## 2. User flows & edge cases | Criterion | Pass | Notes | |---|---|---| | Happy path is clear and complete | | | | Empty state is designed (no data, first-time user) | | | | Error states are designed (API failure, validation errors) | | | | Loading states are designed (skeleton screens or spinners) | | | | Confirmation / success states are designed | | | | Destructive action warnings are present (delete, cancel) | | | | Timeout / session expiry handling is designed | | | **Missing states:** [List any states that need to be designed before handoff] --- ## 3. Usability | Criterion | Pass | Notes | |---|---|---| | Primary action is visually prominent (clear CTA hierarchy) | | | | Navigation / back behaviour is intuitive | | | | Form validation messages are specific and actionable | | | | No more than one primary CTA per screen | | | | Task can be completed in ≤ 5 steps (or justified if more) | | | | Cognitive load is acceptable — no screen is overwhelming | | | **Usability concerns:** [Note any flows that feel confusing or require explanation] --- ## 4. Copy & content | Criterion | Pass | Notes | |---|---|---| | All copy is final (no "Lorem ipsum" or placeholder text) | | | | Button labels are action-oriented (verb + noun) | | | | Error messages explain what went wrong and what to do | | | | Empty state copy sets expectation and provides next action | | | | Tone is consistent with existing product voice | | | | Character limits are tested (truncation handled gracefully) | | | **Copy issues:** [List any placeholder copy or tone inconsistencies] --- ## 5. Accessibility | Criterion | Pass | Notes | |---|---|---| | Colour contrast meets WCAG AA (4.5:1 text, 3:1 UI elements) | | | | Interactive elements are not colour-only (icons, labels) | | | | Focus order is logical for keyboard navigation | | | | Form inputs have labels (not just placeholder text) | | | | Images have alt text noted in spec | | | | Touch targets are ≥ 44×44px on mobile | | | **Accessibility gaps:** [List any accessibility issues to resolve before handoff] --- ## 6. Responsiveness & platform | Criterion | Pass | Notes | |---|---|---| | Mobile (375px) breakpoint is designed | | | | Tablet (768px) breakpoint is designed (if applicable) | | | | Desktop (1280px+) breakpoint is designed | | | | No horizontal scroll on mobile | | | | Native patterns used where appropriate (bottom sheets, swipe) | | | --- ## 7. Design system consistency | Criterion | Pass | Notes | |---|---|---| | Components are from the existing design system | | | | New components are documented / added to system | | | | Spacing follows the grid (4pt or 8pt system) | | | | Typography matches type scale | | | | Colours are from the defined palette | | | **New components / deviations:** [List any net-new components that need to be built or any intentional design system deviations] --- ## 8. Handoff readiness | Criterion | Pass | Notes | |---|---|---| | All assets are exported (icons, images, custom graphics) | | | | Interaction notes are annotated (animations, transitions, timing) | | | | Prototype link is available for engineer reference | | | | Responsive specs are annotated for all breakpoints | | | | Design file is organised and named correctly | | | --- ## 9. Open questions | Question | Owner | Due | |---|---|---| | [Question 1] | | | | [Question 2] | | | --- ## Review decision - [ ] **Approved** — ready for engineering handoff - [ ] **Approved with minor changes** — changes listed above, no re-review needed - [ ] **Needs revision** — re-review required before handoff **Reviewer sign-off:** ____________________ Date: ________
How to use this Design Review template
Review flows, not screens
The most common mistake in design reviews is evaluating individual screens in isolation. Walk through the complete user flow — from entry point to success state — for each user story. A screen that looks fine in isolation often reveals a broken transition or missing state when viewed as a sequence.
Prioritise edge cases over happy path
The happy path is usually well-designed. The edge cases — empty states, error states, loading states, character limit overflow — are where designs break down in production. Allocate at least 30% of your review time to edge cases.
Don't approve placeholder copy
Lorem ipsum and placeholder text hide real problems: a button label that's 3 words in English might be 8 words in Hindi and break the layout. A generic error message ('Something went wrong') that ships because review didn't flag it becomes permanent. Require final copy before handoff.
Check accessibility early, not at the end
Accessibility issues found in design review take 10 minutes to fix. The same issues found in QA take hours of engineering rework. Colour contrast, touch target size, and keyboard focus order are all visible in design files before a line of code is written.
Want a Design Review grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
Who should run the design review — PM or design lead?
Both should be present, but the PM leads the requirements-alignment and user flow sections while the design lead leads the design system and handoff readiness sections. The review is collaborative — it's not a PM gatekeeping design, it's PM and design ensuring nothing is missed before engineering starts.
Should engineers attend the design review?
At least one engineer should attend, specifically to flag technical feasibility concerns and to ask questions about interaction annotations. Engineers who attend the design review start the sprint with significantly better context than engineers who only see the Figma link in a Jira ticket.
What if a design review blocks the sprint start?
If blocking issues are found, fix them before engineering starts — not in parallel. The cost of a 2-day design fix before development is dramatically lower than a 2-day design change after 5 days of engineering work. If the issues are minor, approve with conditions and ensure changes are made before the component is built.
How detailed should annotations be in the handoff?
Annotations should answer the questions engineers will ask: 'What happens when the user hovers?', 'What's the animation timing?', 'What are the truncation rules?', 'What happens if this string is 100 characters?'. If an engineer has to guess, the annotation is insufficient.
Other free templates