A wireframe exists to start an argument. Not about the font or the brand color, but about the thing that decides whether a product works: what is on each screen, and in what order a person meets it. This walkthrough takes you from a blank page to a structure your team can argue with, usually in less than an hour.
The steps are tool-agnostic. Paper, whiteboard, or canvas, the process is the same. If the vocabulary is new, the wireframing pillar covers what a wireframe is and where it sits in the design process.
Before you draw: inventory the content
The most common wireframing mistake happens before the first box. People open a blank screen and start arranging, without knowing what they are arranging.
Spend ten minutes listing everything the screen has to carry:
- The task: what a person came here to do, in one sentence.
- The content: every piece of information they need to do it.
- The actions: every button, link, and input the task requires.
- The states: what the screen shows when it is empty, loading, or failing.
Write this as a plain list. For a checkout page the list might read: order summary, item count, shipping address, payment method, total, place order button, edit cart link, error state for a declined card. Now you are arranging known parts instead of inventing them mid-drawing.
Step 1: sketch the flow before the screens
Screens do not exist alone. Before drawing any single screen, draw the path between them: a row of small rectangles, one per screen, with arrows showing how a person moves forward and how they back out.
For a signup flow that might be four boxes: landing, account details, plan choice, confirmation. Seeing the row often kills a screen before you draw it. If the plan choice can live on the account details screen, you just saved a step, and you found that out for the cost of four rectangles.
Step 2: grey boxes only
Now draw the screens. The rules are strict because they protect you:
- Rectangles for images, with an X through them.
- Horizontal lines for text. A thick line for a heading, thin lines for body.
- Plain outlined rectangles for buttons, labeled with their verb: "Place order", not "Submit".
- Real hierarchy, fake content. Position and size carry the meaning; the words inside mostly do not, except on buttons and headings.
No color. No type choices. Nothing that looks designed. The moment a wireframe looks finished, feedback shifts to how it looks and away from whether it works. Keeping fidelity low is a reviewing strategy as much as a drawing one; the fidelity guide covers when to turn that dial up.
Size the boxes honestly. If the order summary needs half the screen, give it half the screen. A wireframe where everything fits comfortably is usually a wireframe that is lying about the content.
Step 3: annotate behavior
A static drawing cannot show what happens when someone taps. Notes can. Next to each interactive element, write one short annotation: "opens date picker", "collapses on scroll", "disabled until address is valid".
Annotations are where wireframes earn their keep in engineering handoffs. The drawing shows structure; the notes show behavior; together they are a brief precise enough to build from, which is exactly how agent canvases use them.
Step 4: review with the team
Put the wireframe in front of people and ask two questions:
- Walk me through it: can a colleague narrate the task from the drawing alone, without you explaining? Where they stall, the structure is unclear.
- What is missing: check the drawing against the inventory from step zero. Every listed item should be present or consciously cut.
Expect the review to be blunt. That is the payoff of grey boxes: nobody hesitates to criticize a drawing that took eight minutes.
Step 5: iterate, then raise fidelity
Redraw fast and redraw whole. It is quicker to draw a second version than to nudge the first one into agreement. Keep the discarded versions visible next to the current one; the comparison is often what settles the argument.
When the structure stops changing between reviews, you are done wireframing. What happens next depends on your workflow. The traditional route is a mockup, then a prototype, then a build. On a canvas with an agent, the route is shorter: the wireframe and its annotations become the brief, and the agent builds the working screen next to the drawing. If you want to try that loop, you can generate a wireframe from a sentence and go from grey boxes to a running interface on the same surface.
Either way, the discipline holds: decide structure in cheap drawings, and spend the expensive tools on a structure that has already survived an argument.