How to review a wireframe

Read the flow before the pixels

A wireframe review goes wrong when it starts with the pixels. Walk the frames in order first, because a flow that does not make sense cannot be rescued by a better arrangement of blocks on any single screen. Present mode exists for this: ArrowRight or Space moves to the next frame, ArrowLeft goes back, and Esc leaves the presentation.

Walk it silently once before you say anything. Note where you hesitate, where you read a label twice, and where you cannot tell what happens next. Those pauses are the review, and they are worth more than any comment about a single block, because they are the places where a real user would stop as well.

• Walk the frames in Present mode before commenting on any one of them
• Write down the pauses rather than the details
• Name each screen in a sentence as you go past it
• Settle the flow before you settle the individual screens

Note: Present mode is driven by the keyboard rather than a pointer, and the only navigation it follows is a prototype link set on a frame with On tap go to. It shows the order of your screens and nothing more, which is exactly what a flow review needs.

Can you say what matters on each screen?

The second question is whether the reviewer can say what matters on each screen without being told. Strip a frame down to its heading and ask what the screen is about. If the answer is not obvious, the hierarchy is not doing the work, and no amount of extra polish will fix that.

Use the layers panel rather than squinting at a full frame. It shows the structure of a frame as an indented tree, and every row has controls to hide, show and lock a component, so you can strip a screen to one level and check whether it still explains itself. Locking is worth doing as well, because it stops the review from accidentally nudging a block that was fine.

• Hide everything but the heading and ask what the screen is for
• Use the hide, show and lock controls in the layers panel while you ask
• If the answer needs a sentence, the screen is missing something
• Ask the same question of every frame in the flow

Note: Lock the components you are not reviewing, because a nudged block during a conversation reads as a change of intent rather than a slip of the mouse.

Is the spacing doing the work?

Third question: would the screen still read if the styling were removed? A wireframe that depends on a subtle background to pull two blocks together is using color to do a job that spacing should do. Look for elements that should be together and check whether they sit closer than the elements around them.

The numbers make this easy to judge. Every gap and every margin should come from a short scale rather than from wherever a block happened to land, and the auto-layout gap and padding in the inspector both run from 0 to 96, so every value on a sensible scale is available. A screen with a 13 pixel gap next to a 16 pixel gap has an accident in it.

• Would the screen still read with the styling taken away
• Grouped elements sit closer together than the elements around them
• Every gap on the screen comes from the same short scale
• The frame margin matches on both sides and on every screen

Are the states drawn or assumed?

Most wireframe reviews skip this question, and most wireframe reviews should not. A screen drawn with content in it hides three other screens: the empty state, the loading state and the error state. Each has a different layout, and each is a place where a product usually falls apart, because it gets designed last and rarely at all.

Ask which states the flow can actually reach. A list can be empty on the first run. A search can return nothing. A form can fail validation. A request can take long enough that the user acts twice. Each of those needs a frame, and the empty state in particular is a screen with a job of its own, which is why Canvasola has an Empty state component in the library.

• Ask which states the flow can reach: empty, loading, error, too much data
• Each state needs its own frame, because nothing simulates inside a mockup
• The Empty state component covers the most common one
• Copy the frame rather than rebuilding it for every state

Does the type scale hold together?

Fifth question: does the type behave as a scale? Look across the frames rather than at one screen, and check that the same job is set at the same size everywhere. A heading at 24 pixels on one screen and 26 on another is the kind of detail nobody can see in a meeting and everybody feels in the finished product.

Check the three roles separately. The screen title should be the largest text on the frame, a block title should be clearly smaller, and body text should be the smallest of the three and by far the most plentiful. When a caption is set at the same size as body copy, the screen has two levels where it claims to have three.

• The same job is set at the same size on every frame
• Title, block title and body form three distinct levels
• Captions are smaller than body copy
• The longest label on the screen has been read aloud

Note: Type questions belong to the build rather than to the wireframe, so a comment about the exact point size is usually a comment that has found the wrong document.

Turn comments into a change list

The last step decides whether the review was worth the meeting. Every comment that survives becomes a line in a change list, and every line carries three things: the frame it applies to, the change in a sentence, and whether it is a decision or a fix. Anything that fits none of those is a preference, and preferences belong on a separate list.

Write the list in the project rather than in a chat, and keep it next to the mockup. Ten specific changes are a short afternoon of work, and a paragraph of feedback is a second meeting. The layout concept guide covers the stage before the wireframe, and the mockup tutorial covers the stage after it.

Then export the frames as PNG at 2×, which produces a file you can attach to the change list and read by someone who will never open the editor. The wireframe guide covers the block-first method behind the frames, and the multi screen flow guide covers building the sequence the review walks through.

• Every comment becomes a line with a frame, a change and a kind of work
• Separate the decisions to make from the preferences to ignore
• Keep the list in the project rather than in a chat thread
• Export the frames as PNG at 2× so the reviewer sees the frames

Note: The app template gallery holds 54 templates across 8 categories, which is a fast way to borrow a structure for a flow you are stuck on rather than starting from an empty frame. A review of a borrowed structure is also a review of a decision you did not make, so ask why it is there.

A checklist you can reuse

• The flow was walked in Present mode before any comment was made
• The pauses during that walk were written down
• Every screen can be named in one sentence
• Hiding everything but the heading leaves a screen that still explains itself
• Every gap on every frame comes from one spacing scale
• The empty, loading and error states are either drawn or listed
• The type scale is identical on every frame of the set
• Every comment became a line in a change list

Common mistakes to avoid

• Reviewing one frame at a time. Looking at a screen in isolation misses the flow, and the flow is where most of the real problems live. Walk the frames in order first.
• Mixing preferences into the feedback. A remark about a color nobody asked to change sends the builder off to fix something that was not broken. Keep preferences on their own list.
• Skipping the states. A wireframe with content in it hides the empty and error screens, and those are the layouts that usually break. Ask which states the flow can reach.
• Reviewing at full zoom. Everything looks balanced when you are close enough to read it. Step back and ask the questions at the size the screen will be seen.
• Leaving the comments in the meeting. Feedback given out loud is lost or remembered differently by each person. Write the change list before anyone leaves the call.

Frequently asked questions

How do I present a wireframe in Canvasola?

Present mode walks the frames in order with the keyboard: ArrowRight or Space for the next frame, ArrowLeft for the previous one and Esc to leave. A prototype link set on a frame with On tap go to is followed when it exists, and otherwise the order advances linearly. There is no pointer navigation in that mode, so the review runs from the keyboard.

Should a wireframe review include the styling?

Not on the first pass. Review the flow, the hierarchy, the spacing and the states while the frames are still plain, because those are the decisions that cost the most to change later. A second pass can look at color and type, and the light and dark theme toggle in the toolbar makes that second pass quick.

What should I export for a review?

PNG of all the frames at 2× gives you a file you can attach to a change list and read without opening the editor at all. The static HTML and CSS export is also available when the reviewer wants to see the text at its real size, though that file carries no interaction of any kind, so it shows the layout and nothing about behavior.

What is the fastest way to check whether a screen has a hierarchy?

Open the layers panel, hide everything except the heading, and ask someone what the screen is for. If they cannot say in a few words, the screen is relying on explanation rather than on structure. The panel offers hide, show and lock, so you can strip a frame down to its skeleton without moving anything.

How many comments should a review produce?

Ten specific changes is a healthy number for a set of frames. More usually means the review mixed decisions with preferences, and fewer may mean the reviewer was reading the structure rather than critiquing it. Sort the notes into changes to make and things to ignore, and only the first list needs work.

This guide is part of the design foundations collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.