A tidy wireframe can still be wrong. The boxes are aligned, the grey rectangles look plausible, everyone nods in the review, and then the prototype gets built. That is when the problems show up: a primary action buried beneath three secondary ones, a form with no error state, a flow that quietly assumes the user has been here before.
Fifteen minutes of checking before you move into prototyping saves days of unpicking later. What follows is the pass worth running on every wireframe set: hierarchy, flow, content, accessibility, and the conversations that stop a design drifting away from what the team actually agreed.
Hierarchy and layout: does the screen read at a glance?
Start with the least forgiving test. Hierarchy is what a user takes in before they read a single word, so check it while you are still willing to move things around.
- Check 1 — The squint test. Step back from the screen, or blur it until the text is unreadable. You should still be able to point at the main action, the purpose of the page and the first thing to read. If every element is shouting, nothing is.
- Check 2 — One primary action per screen. Count the elements competing for attention. One button should look like the obvious next step, others should look secondary, and anything tertiary should be a plain link. Three “primary” buttons means a decision has been skipped.
- Check 3 — A spacing rhythm you can name. Gaps and margins should come from a small set of numbers — 4, 8, 16, 24, 32. A stray 12-pixel gap is fine if you can explain why it is there and not somewhere else.
Flow and navigation: can a stranger find their way?
Wireframes are usually reviewed one screen at a time, which is the opposite of how anyone uses them.
- Check 4 — Walk two realistic journeys, not just the happy path. Pick a returning customer and a first-time visitor, then write the steps out as a list. If a task needs more than four or five screens, ask which step could be merged or dropped.
- Check 5 — Every screen needs an exit. Back, cancel, close, skip, start again. People arrive mid-flow by mistake, and a screen that only offers “continue” traps them.
- Check 6 — Read the navigation aloud. Say each label without explaining it. If a colleague asks what “Solutions” covers, the label is doing too much work and the structure is probably carrying the strain.
Content and states: the parts everyone skips
Placeholder text is where wireframes go to hide. Real content is longer, messier and far less cooperative, and it will stress the layout in ways you want to see now rather than in build.
- Check 7 — Swap in the longest real content you have. The longest product name, a headline that runs to nine words, a reference number with no spaces in it. If the layout only survives short strings, it does not survive.
- Check 8 — Draw the empty, loading and error states. A dashboard on first run, a search with no results, a payment that fails. Each one deserves a wireframe, even if it is three boxes and a line of copy.
- Check 9 — Write the button and field labels now. “Submit” and “Continue” tell the user nothing. “Create account” and “Save address” tell them exactly what happens next, and they fit or break the button at wireframe stage.
Accessibility groundwork
You do not need a full audit yet, but a handful of checks cost almost nothing now and a great deal after the interface is built.
- Check 10 — Meaning should never rely on colour or position alone. In a grey wireframe this is easy to miss. Mark required fields with a word as well as a colour, and put instructions above the field they refer to.
- Check 11 — Draw realistic target sizes. Around 44 by 44 pixels is a widely used minimum for touch controls; on desktop, leave breathing room between adjacent links. Wireframing 16-pixel icons as taps bakes the mistake into the build.
- Check 12 — Number the focus order. Print the wireframe and write 1, 2, 3 beside every interactive element in the order a keyboard user would reach them. If that order does not match the visual one, the markup will fight the design later.
Stakeholder alignment
Most wireframe disagreements are not about layout. They are about people in the same room solving slightly different problems.
- Check 13 — Ask each reviewer to describe the screen in one sentence. “This screen lets a returning customer change a delivery address.” If two people answer differently, resolve that before anyone discusses padding.
- Check 14 — Annotate open questions instead of settling them out loud. Small numbered notes on the wireframe — “Do we have permission to show order history here?” — travel with the file. Decisions made verbally evaporate by Monday.
- Check 15 — Agree what the prototype is for. Which decision will it inform, who makes that decision, and what would change their mind? A prototype built to answer nothing in particular gets reviewed on taste.
If a screen needs a spoken explanation to make sense, the wireframe is not finished.
Run the review without triggering a redesign
Time-box it to about forty-five minutes. Walk the wireframes in flow order rather than screen order, so reviewers feel the sequence. Park visual preferences — colour, type, imagery — for the next stage, and write down anything that cannot be settled in the room. One person should own the notes and update the files the same day, while the questions are still fresh.
Before you open the prototyping tool
If time is short, prioritise three things: the squint test on your busiest screen, one journey walked end to end, and the empty and error states for anything that shows data. Those catch the majority of expensive problems.
Keep the wireframes editable and versioned, and treat each check as a question rather than a verdict. Wireframes are supposed to be wrong in cheap ways. This checklist simply makes sure they are wrong about the right things, and that the expensive mistakes stay in the sketchbook where they belong.
Photo: DS stories / Pexels
