Design review checklist: 10 things to check before you ship
The bugs that embarrass you in production are rarely exotic. They're the truncated heading on mobile, the button that still says “Submit” instead of “Start free”, the empty state nobody designed because nobody's account was ever empty. Builders can't see these — after three days inside a feature, your brain renders what it meant, not what's there. A design review checklist works because it forces fresh eyes down a fixed path, and a fixed path doesn't skip things. Here's the ten-point website QA checklist we run before anything ships, and how to run it in about twenty minutes.
How to run the review
Three rules before the list. Review on the real thing — staging on an actual phone and an actual laptop, not the design file and not localhost. Capture as you go — screenshot every issue the moment you see it and pin the exact element; by the end you have a numbered fix list, not a memory test. Don't fix while reviewing — context-switching into your editor halfway through guarantees the second half of the checklist never happens.
The checklist
1. Read every word out loud
Copy errors survive because everyone skims. Reading aloud catches the doubled word, the heading that lies about the section, the button that describes the old flow. Pay special attention to microcopy — placeholders, validation messages, empty-state text — which is written last and reviewed never.
2. Squint at the hierarchy
Step back and squint until you can't read the text. Is the most important thing on the page still obviously the most important thing? If your eye lands on a decorative element or a secondary card first, the hierarchy needs work before the pixels do.
3. Check spacing rhythm
Inconsistent spacing is the tell of a rushed build. Related items should sit closer than unrelated ones, gutters should repeat the same few values, and nothing should touch an edge it doesn't mean to. One pass, top to bottom, only looking at gaps.
4. Resize until it breaks
Drag the window from phone width to ultrawide, slowly. Watch for text truncating mid-word, images stretching, cards refusing to wrap, and the layout snapping awkwardly between breakpoints. Then repeat on a real phone, where hover styles vanish and your thumb is the pointer — tap targets under about 44px will punish you here.
5. Feed it ugly data
Your test data is polite: short names, one-line titles, perfect images. Production data isn't. Try the 47-character name, the item with no image, the zero-results search, the user with 300 entries. Every list needs an answer for “none” and “far too many”.
6. Visit every state
The happy path is one state of many. Loading (on throttled 3G, not office wifi), empty, error, partially-filled, logged-out, expired-session. If a state exists, someone will see it — better you than a customer with a screenshot on social media.
7. Walk the keyboard path
Unplug the mouse. Tab through the page: can you reach every control, see focus at all times, submit the form, escape the modal? Five minutes of keyboard-only use finds accessibility gaps that audits charge thousands to list.
8. Check contrast and colour
Grey-on-white designs fail quietly for anyone in sunlight, over 40, or colour-blind. Run the main text and button combinations through a contrast checker, and make sure nothing communicates by colour alone — statuses need labels or shapes too.
9. Test the actual actions
Click every button and submit every form — on staging, with the network tab open. Broken form handlers, missing redirects and double-submit bugs all hide behind buttons that look finished. If it can be clicked, click it.
10. Do the five-second first impression
Fresh eyes, five seconds on the landing screen: what is this product, what should I do next, do I trust it? You've read the page a hundred times; someone else hasn't. Grab whoever's nearby, show them the screen, and listen.
When to run it — and who should
The checklist earns its keep at three moments: before any public launch (obviously), before each client review round (so the client's feedback is about the design, not the typos), and after any “quick change” that touched layout or copy — the innocuous edits cause a surprising share of production embarrassments.
Who runs it matters more than teams expect. The builder is the worst candidate for their own work; their brain autocorrects the page. The ideal reviewer is someone adjacent — another developer, the PM, a designer from a different project — who knows what the product does but didn't watch this feature grow. On solo projects where adjacent humans are scarce, leave a gap: review tomorrow morning what you built this afternoon, on a different device than you built it on. Distance in time substitutes tolerably for distance in person.
Turn the findings into fixes
A checklist that produces a Slack message of vague concerns has wasted its twenty minutes. Every issue you caught should already be a numbered, pinned item with a note — which is exactly what a Fixa board gives you if you captured as you went. From there, the list works itself: statuses flip as fixes land, the export drops into your tracker or your coding agent, and “did we fix 6?” has a colour-coded answer.
Run the ten points before every ship — on a free board, on your next release. The first time this checklist catches the truncated heading before your biggest client does, it will have paid for every twenty-minute session you'll ever run. For the team-wide version of this workflow, see how startups and agencies run their review rounds.