How to make an app wireframe

Decide the screen's job before you draw anything

Before the frame or the blocks, write one sentence describing what this screen is for. Not what it contains, but what the user is there to do: check today's tasks, choose a plan, confirm a delivery. That sentence is the only thing you need to decide first, and it is the thing reviewers most often never hear said out loud. The mockup tutorial starts from the same sentence and carries it into a styled set.

A screen with one job has an obvious hierarchy, because you can rank everything on it against that job. A screen with two jobs has none, and that shows up later as two equally loud primary actions.

If you cannot write the sentence, the screen is not specified yet. Go and find out what it is for, because a wireframe drawn before that answer will only encode your guess, and nobody notices the guess until the screen is built.

• One sentence per screen, written before the first block
• Name the user action, not the content list
• If the sentence needs an 'and', split the screen in two
• Say the sentence out loud to one colleague before you continue

Note: The sentence is a working tool, not a document. Write it, use it, and rewrite it when the conversation changes your mind.

Set the frame to the device you are designing for

Now pick the device. App Builder opens a mobile frame at 390×844, and the frame inspector offers presets for iPhone SE 375×667, iPhone 14 390×844, iPhone Pro Max 430×932, Android 412×915 and Tablet 820×1180, alongside the web sizes Laptop 1280×800 and Desktop 1440×900. A custom frame can be any size, down to a minimum of 120×120. The mobile screen guide covers what to do once the size is right.

Choose the size the product actually ships on rather than the size that is easiest to lay out. The narrower the frame, the more content competes for the same vertical space, and a wireframe that only works on a wide screen is a wireframe for a product that does not exist.

Add a second frame only when the layout genuinely differs between phone and tablet, and not otherwise. If the same blocks in the same order fit both, you have one design, and you have learned that it is responsive.

1. Add the frame. Open App Builder, choose Add mobile frame, and set the Preset dropdown to the device you are designing for.
2. Type exact values if needed. Fill in the W and H fields when your device is not in the list, keeping the frame at least 120×120.
3. Name the frame. Use the frame Name field to name the screen after its job, such as Today or Plan detail, so the frame list reads as a flow.

Note: The frame name is the only label the inspector gives you, and it is worth setting before you add blocks. Later, when you have six screens, that name is how you will find the one you meant.

Build the wireframe from blocks, not drawings

Put components in the frame rather than drawing shapes. The palette holds 58 component kinds, and the ones that carry structure in a low-fidelity pass are List item, Divider, Image, Avatar, Heading, Text, Button, Input, Card, Search and Tabs. They already look like interface parts, so a reader gets the structure without any styling from you.

Group what belongs together. Select two or more siblings and press Ctrl/Cmd+G to turn them into a single group, and Ctrl/Cmd+Shift+G to ungroup when the structure changes. Grouping gives you one thing to move instead of five, and it makes the auto-layout inside a container behave the way you expect.

Let the grid do the aligning. The placement snap grid in App Builder is 8 pixels, so elements land on a shared rhythm as you drag them, and arrow keys nudge a selection by 4 pixels, or 16 pixels with Shift. Nothing needs to sit on a pixel that you guessed.

• Blocks come from the component palette, not from the canvas drawing tools
• Group related blocks with Ctrl/Cmd+G, release them with Ctrl/Cmd+Shift+G
• Align across the six alignment positions, and distribute with 3 or more selected
• Keep the 8 pixel grid as the shared rhythm for every edge

Note: The freeform canvas and the App Builder are different surfaces. Drawing tools live on the canvas; inside a frame you are arranging interface components, and the 8 pixel grid is what keeps that arrangement tidy.

Write real labels instead of lorem ipsum

The labels are the content decision, and placeholder text hides it. A list of Item 1, Item 2 and Item 3 says nothing about how long the real entries are or whether one needs a second line. Write the actual words: Tuesday 7am, Quarterly review, Order #4821.

Length matters more than wording. Take the longest label you expect in that slot and put it in the block. If it wraps onto three lines, the block was never going to be that size, and you have just saved the argument that would have happened later.

This is also the cheapest moment to check whether the content is right. Reading your own labels in order tells you whether the screen makes sense as a sequence, and a screen that reads as a strange list of words is telling you the information hierarchy needs another pass.

• Use the real words the product will show
• Test with the longest label that can appear in the block
• A label that needs two lines means the block needs two lines
• Keep the wording consistent between screens of the same type

Note: Real labels also protect you later, when the wireframe becomes a styled mockup and somebody asks what each field is for. The answer is written on the screen already.

Keep it grayscale so the structure does the talking

A wireframe in one flat tone forces the layout to carry the meaning. If a screen still reads correctly when everything is gray, then the order, the grouping and the sizes are doing the work, and the screen is reviewable on its structure rather than on its color.

Canvasola's two theme token sets are light and dark, and the toolbar's Toggle dark theme button moves between them. Neither is a grayscale palette, so keeping the wireframe neutral is a choice you make in the inspector: leave the fills and text at their defaults, and reserve any accent color for the single primary action.

Two things break a neutral wireframe fastest. The first is a colored status that carries meaning on its own, such as a red badge with no word in it. The second is a special treatment on a block that only looks important because it is the only one with a shadow. Neither survives contact with real data.

• One flat tone for every block, so position and size carry meaning
• No color-only status: put the word next to the color
• No shadows, no gradients, no illustrations in a structural pass
• Review the frame in the light theme before adding any accent

Note: GRAYSCALE is for the first pass. Once the structure is agreed, a second pass in the real theme is worth the extra time, and the very same frames can hold it.

Run a five-question check before you share it

Before the file leaves your machine, run five questions over the frame. They take two minutes, catch most of what a reviewer would otherwise point out, and cost less than a round of comments on a shared document.

The point of the check is not to make the wireframe perfect. It is to arrive with the obvious things already settled, so the review is about the parts that genuinely need a decision. The wireframe tool guide covers the tool choices behind this pass.

• Can I say the job of this screen in one sentence?
• Can I name what every block on it is?
• Is the order of the blocks obvious without an explanation?
• Is there exactly one thing the user is meant to do next?
• Do I know what I deliberately left out of this screen?

Note: If the answer to the fourth question is no, that is the most valuable thing you can learn before the meeting. A wireframe is cheap to change, and a mockup is not.

A checklist you can reuse

• The job of the screen is written down in one sentence
• The frame preset matches the shipping device
• Every block is a component from the palette
• Related blocks are grouped with Ctrl/Cmd+G
• Edges land on the 8 pixel grid
• Every label is real text and as long as the real thing
• The five-question check was run before sharing

Common mistakes to avoid

• Starting with the blocks. Without the sentence first, the screen fills up with everything you can think of. Decide the job, then decide what earns a place.
• Using the wrong device size. A wireframe on a 430-pixel frame will not survive a 375-pixel phone. Set the preset the product ships on.
• Drawing instead of using components. A hand-drawn rectangle has to be relabeled and re-sized by hand later. A List item already knows what it is.
• Leaving placeholder text in place. Lorem ipsum hides the longest-label problem until the screen is styled. Use the real words now.
• Skipping the grayscale pass. A colored wireframe gets a comment about the color. A gray one gets a comment about the structure, which is the useful one.

Frequently asked questions

How long should it take to wireframe one app screen?

The first pass on a simple screen is a few minutes once the frame is set. The time goes on deciding what belongs on the screen, not on the mechanics. If you spend twenty minutes on one screen, the job of that screen has not been agreed, and no tool fixes that.

Do I need every screen of the app wireframed?

No. Wireframe the screens that carry the risk: the entry point, the main task and the moment the user decides. The wireframe tool guide covers where the low-fidelity pass pays for itself, and the mobile screen guide covers styling the result.

Can I keep the same wireframe and make it high fidelity later?

Yes, and that is the cheapest route. The frames, the auto-layout structure and the labels survive, so you restyle the same project rather than rebuilding it. The mockup tutorial picks up from a structure and turns it into a finished screen set.

What is the one thing a wireframe cannot tell you?

How the screen will feel to use, because nothing in a wireframe responds to a tap. Canvasola's prototype links are set at frame level with On tap go to, and Present mode advances with the keyboard, so a wireframe tells you the order of the screens but not the feel of moving between them.

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.