How to make a wireframe for a web app

What a web wireframe has to answer

A web wireframe answers one question: does the structure of this page hold together before anyone looks at it. That means the regions, their order, their relative size and the labels. It does not mean color, shadow, gradients or icon choice, and a wireframe that answers the second question instead is a design that has been made to look unfinished.

The reason to wireframe a web page separately from designing it is that the desktop frame has room, and room hides problems. On a phone the space forces decisions. On a 1280-pixel-wide canvas you can put four things side by side and none of them look wrong, and then the real question of what matters never gets asked.

So the wireframe is where you decide what the page is for. One page, one job, and the regions follow from that job. A page with three equally large regions is a page whose job has not been decided.

• Structure, order, proportion and labels, and nothing else
• The desktop frame has room, and room hides priority problems
• One page, one job, and the regions follow from it

Note: A wireframe is not a rough draft of a design. It is a different artifact with a different job, and treating it as a draft is how wireframes end up full of placeholder gray boxes that nobody can read.

Start from a 1280×800 frame

Open a web frame. The default web frame in App Builder is 1280×800, and the presets include Laptop at 1280×800 and Desktop at 1440×900. Use the default for the wireframe, because 1280×800 is the frame most people will recognize, and a reviewer who says the top area feels heavy is usually reacting to the proportions of a shape they have seen a thousand times.

Build the wireframe in a web frame rather than a mobile one, even if the product is eventually responsive. A page that will later be squeezed into a phone has to be designed as a page first, because the phone version is a reflow of the page and not the other way round.

Keep the frame at one size for the whole wireframe pass. Changing presets halfway through means comparing two different canvases, and the differences you end up noticing are the ones you were not actually looking for.

• Web frames default to 1280×800
• Laptop is 1280×800 and Desktop is 1440×900
• Wireframe the page first and reflow it later

Block the regions before the details

Block the regions first: a header, a side column, a main content area, a right rail, whatever the page actually has. Draw them as plain rectangles or containers, name them, and resist filling them. The question at this stage is how much of the page each region gets and how they sit relative to each other.

Then place blocks of content inside each region, again as plain shapes. A list is a tall thin rectangle, a chart is a square, a paragraph is a block of gray lines. You can do this in minutes, and you can still change your mind in minutes.

Set the spacing with auto-layout so the regions have real numbers. The gap and padding controls run from 0 to 96, so a 16-pixel gap and 24-pixel padding is a normal choice, and it means the block map is a layout rather than a drawing. Select the blocks of a region and press Ctrl/Cmd+G to group them so they move together as you rearrange.

• Regions first, as named rectangles
• Content blocks as simple shapes inside each region
• Gap and padding from the auto-layout controls, 0 to 96
• Group the blocks of a region so they move together

Note: The component palette holds 58 kinds, and most of them are more detail than a wireframe needs. A rectangle, a Text and a Divider cover most of a block map, and a component that has not been chosen yet is a component whose size you have not decided yet.

Use real labels and realistic lengths

Labels are what a wireframe is actually for. A block marked Settings and a block marked Reports tell a reviewer what the page contains, and a page of gray rectangles with no labels tells them nothing except that you made rectangles. Use the words the product uses, in the product's capitalization.

Use realistic lengths. A block of five lines for a heading that will really be two lines, or a card labeled Read more that will really be Continue reading, means the wireframe is lying about the space. Put in the longest label you expect and see whether the region still holds it.

Where you do not know the text yet, write something real anyway. An honest placeholder at the right length is more useful than a generic one, and it keeps you from designing a region that only fits because the words were short.

• Real headings, real button labels, real product vocabulary
• The longest label you expect, at its real length
• Placeholder text at realistic length rather than lorem ipsum

Add a second state worth reviewing

One state per screen hides the decisions that only appear when something changes. Add a second state for the same screen when the change matters: the page before data loads, the page after a search that returns nothing, the state where a permission is missing. Two frames side by side are a much better conversation than a paragraph describing the difference.

A second state is also how you check that a region is real. If a right rail only exists when a user is signed in, wireframe the signed-out version and see what the page looks like without it. If the layout collapses without that region, the region was carrying more weight than you thought.

Do not build every state. Two states that matter, side by side, is usually enough to review the structure, and the rest can wait until the design is real and the behavior of the page is worth pinning down.

• A second state for the change that matters most
• Empty, loading, signed-out or error, whichever is most likely
• Two states, not every state

Note: The phone version of a web wireframe is a different question, and the mobile wireframe guide covers that separately rather than treating it as a resize of the same file.

Check the structure before you style it

Review the wireframe while it is still gray. Can someone who has never seen the product say what the page is for? Can they name the main action? Do the regions read in the order you meant, from top left to bottom right? Those three questions catch most of what styling would otherwise hide.

Then export it, so the structure exists outside the editor. The JSON export is re-importable, which means you can send it to someone, they open it in Canvasola and the frames and the layout come back, and the wireframe stays editable. PNG is for showing, JSON is for working on.

If you want the review to be about structure rather than appearance, keep the wireframe gray right up to the end. The wireframe review guide covers how to run that review, the wireframe tool guide covers what to look for in the tool itself, and the complete Canvasola guide covers the app around it.

• A stranger can say what the page is for
• The main action is obvious in the gray version
• JSON exported so the wireframe stays editable

Note: The wider product tour, including how App Builder sits alongside the canvas and the mind map, is covered in the product guide.

A checklist you can reuse

• The web frame is 1280×800, or the Laptop preset, and stays the same for the whole pass
• The regions of the page are blocked and named before anything is placed inside them
• Spacing comes from the auto-layout gap and padding controls, not from dragging
• Blocks of a region are grouped so they move together
• Every region carries a real label at a realistic length
• At least one second state exists for a change that matters
• The structure has been reviewed in grayscale before any styling
• The wireframe has been exported as JSON so it stays editable

Common mistakes to avoid

• Styling the wireframe as you go. Color and shadow make a wireframe look finished, which makes it harder to change. Keep it gray and judge the structure on its own.
• Wireframing on a phone frame. A desktop page has to be planned as a page, because the phone version is a reflow of it. Start at 1280×800 and narrow it later.
• Using placeholder blocks with no labels. A rectangle tells a reviewer nothing. The label is the information the wireframe exists to convey.
• Building every state. Nine frames of the same page is a week of work and a worse review. Two states that matter, side by side, is enough to test the structure.
• Exporting only images. A PNG of a wireframe cannot be edited, and the next version of the page starts from scratch. The JSON export comes back into Canvasola intact.

Frequently asked questions

What size should a web app wireframe be drawn at?

1280×800, which is both the default web frame in App Builder and the Laptop preset. It is a size people recognize, so a comment about a region feeling heavy means what it sounds like. Use the Desktop preset at 1440×900 later, when you are checking how much of the page is left over.

How much detail should a web wireframe have?

Enough to show the regions, their order, their relative size and the real labels. The component palette holds 58 kinds, but a wireframe needs very few of them. A rectangle, a Text and a Divider cover most of a block map, and the detail belongs in the design that follows.

Should a web wireframe be grayscale?

Yes, for the structure pass. Grayscale means nobody comments about a color that has not been decided, and it makes an empty region obvious because a white gap stands out in a way a colored one does not. Colors come back in the design stage.

How do I keep a web wireframe editable after I hand it over?

Export the JSON. It is re-importable, so the recipient opens it in Canvasola and the frames, the layout and the links come back, and the structure can be changed rather than redrawn. The PNG export is the version for looking at, not for editing.

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