How to build an app layout concept

What a layout concept actually decides

A layout concept is the answer to a much smaller question than "what does this app look like". It is the decision about what belongs on the screen, in what order, and how much space each part gets. Two teams can disagree about a layout concept for ten minutes and skip two days of pixel work if the concept is written down first.

The useful part of the concept is that it is cheap to change. Once a screen is full of styled components, moving a block from the top to the bottom of the page costs real time and real confidence. A concept that only contains blocks, order and spacing can be rearranged in a minute, which is exactly when the thinking is still cheap.

Canvasola's App Builder is well suited to this because the same frame can hold a rough concept and a finished screen. You can start with blocks that say what goes where, present the concept to someone, and then replace the blocks with real components one at a time without rebuilding the frame.

• A concept fixes order and proportion, not colors or type
• It answers one question per screen: what is this screen for?
• It should survive being shown to someone who did not build it
• It should be quick to redraw when the answer changes

Note: If a concept cannot be sketched with four gray blocks and a spacing scale, it is usually a screen design pretending to be a concept.

Pick the frame before the content

Frame choice constrains everything else, so make it first. Canvasola opens new frames at 390×844 for mobile and 1280×800 for web, and the frame inspector offers presets for iPhone SE, iPhone 14, iPhone Pro Max, Android, Tablet, Laptop and Desktop. The preset matters less than the discipline of deciding: if the product is a phone app, do not concept it on a 1440-pixel-wide artboard and then hope the layout compresses.

Concepting in the real size also exposes problems early. A concept for a habit tracker looks comfortable on a wide screen and turns out to have no room for a fourth row on a phone. That is a cheap discovery in a concept and an expensive one after handoff.

Add a second frame when the layout genuinely differs between sizes, and keep the two side by side. A concept that works on both is usually a content priority problem, not a width problem: if the same four blocks are in the same order on both, you have a responsive concept rather than two concepts.

1. Add the frame. Choose a mobile or web frame in App Builder and set the preset to the device the product actually ships on.
2. Name it by role. Name the frame after what happens on the screen, such as "Today" or "Habit detail", so the concept reads as a flow rather than a set of artboards.
3. Decide the viewport assumption. Write down the content that is always present and the content that is conditional. Those two lists drive the layout more than any style decision.

Rank the content, then cut it

A screen has one job. Write that job as a sentence before you place anything: "the user sees what is due today and starts the next habit". Then decide which of the four roles each element plays: the primary action, the supporting content, the context and the navigation.

Most layout problems are really role problems. When a screen has two primary actions, nothing is primary. When navigation sits at the top of the screen and the primary action also sits at the top, the two compete for the same attention. A concept is the right place to notice this, because the fix is usually to move or demote a block, not to restyle it.

Rank the blocks in priority order and then cut. Anything that is not in the top three usually belongs on another screen, behind a tap, or not on the product yet. Cutting at concept stage is nearly free; cutting after the components are styled is the expensive kind of change.

• Primary action: one per screen, and it should be the largest thing you can click
• Supporting content: what the user needs to judge whether to act
• Context: title, identity, and where the user is
• Navigation: where the user can go, not where the product wants them to go

Set the rhythm with auto-layout

The single biggest time saver in a concept is refusing to drag things into place. Turn on auto-layout for the container and let the inspector set the direction, the gap and the padding. Vertical flow with a 12-pixel gap and 16-pixel padding is a defensible default for a concept, and it is a number you can argue with rather than a position you have to eyeball.

Auto-layout also makes the concept robust in a way that hand-placed blocks never are. Change the gap from 12 to 16 and every block moves together. Add a fourth row and the container grows instead of overlapping. That is what lets a concept be revised in a meeting rather than after it.

Inside each block, keep the structure just as predictable. A group with vertical flow, 8 pixels of gap and no padding is a clean row or list. A container that hugs its content avoids the empty space that makes a concept look finished when it is not.

Note: Auto-layout gap and padding are both clamped between 0 and 96 in the inspector, and a container whose width or height is zero hugs its children, so the concept never depends on a hidden fixed size.

Fix the edges with constraints

A concept that only works at one exact size is a picture, not a layout. Constraints are what turn a concept into a rule: a header can be pinned to the top and left, a list can stretch horizontally, a summary block can scale, and a floating action can stay anchored to the bottom right.

Set constraints while the concept is still blocky. It takes seconds, and it forces you to state what happens when the frame changes size, which is a question the concept should answer anyway. When a later reviewer asks what the layout does on a smaller phone, you can show it rather than guess.

Scale constraints are worth using sparingly in a concept. A heading that scales with the frame is fine; a card that scales can produce unreadable text. Stretch and pinned constraints cover most real cases and are much easier to reason about.

1. Pin the header. Set the header to stay at the top and left so it does not float when the frame is resized.
2. Stretch the content. Let the main content stretch horizontally so rows grow with the frame rather than staying at a fixed width.
3. Anchor the action. Keep the primary action anchored to the bottom so the decision to act stays in the same place as the frame grows.

Check the concept at three sizes

Present the concept as a concept. Say what question the screen answers, then ask the reviewer to describe the screen back to you. If they describe the order, the hierarchy worked. If they describe the color, the visual layer is doing the work that the layout should be doing.

Check the same concept at three sizes: the smallest device you support, the device you designed for, and the largest layout the screen is ever shown in. The frame inspector presets make this fast, and the differences you find are usually about content priority rather than pixels.

Use realistic content while checking. A concept with "Lorem ipsum" hides the exact problem that will appear later, which is a label that is twice as long as the one you assumed. Short, real sentences cost nothing at this stage and save a redesign.

• Ask the reviewer to describe the screen back to you in one sentence
• Use the real length of the longest label you expect
• Check the smallest supported device, not only the largest
• Name the one decision the concept is asking for

Hand the concept to a wireframe

When the concept holds up at three sizes, it is ready to become a wireframe: the same structure, now filled with the real components. Swap each block for the component it will become, a Nav bar, a Card, a List item, a Stat, and the order you agreed stays intact because the container is already laid out.

Hand over the concept with a written note. List what is decided, what is deliberately deferred, and which questions are still open. A wireframe plus three sentences of context is a much better starting point for a team than a wireframe alone, and it stops the review from reopening decisions you already made.

Keep the concept frame in the same project as the wireframe. The wireframe guide covers the block-first method in more detail, and the mockup tutorial covers the full path from a blank frame to an exported flow.

Note: Write down what you deliberately left out. A concept that says "no search on this screen" is far more useful than a screen that silently omits it, because the next person will not have to guess whether the omission was an accident.

A checklist you can reuse

• The frame is the size the product actually ships on
• The screen has one stated job, in one sentence
• Exactly one element is the primary action
• Lower-priority blocks were cut rather than shrunk
• Spacing comes from auto-layout numbers, not from dragging
• Constraints are set for the header, the content and the action
• The concept was checked on the smallest supported device
• Labels are real text at realistic length
• The concept has been presented and understood by someone else

Common mistakes to avoid

• Concepting at desktop size. A layout planned on a wide artboard hides the pressure a phone screen puts on the same content. Concept in the shipping size, or add a mobile frame before the review.
• Styling before structure. Color, shadow and type make a concept look finished, which makes it harder to change. Keep the concept gray and let the visual layer come later.
• Two primary actions. When everything is important, nothing is. Demote one action to a secondary style and check whether the screen becomes obvious.
• Hand-placing every block. Positions that were dragged cannot be reviewed as a rule. Convert the arrangement to auto-layout so the spacing becomes a number someone can agree with.
• Skipping the constraints. Without constraints a concept only works at the exact size you built it. Set them now, while changing them is still cheap.

Frequently asked questions

How long should an app layout concept take?

The first concept of a screen is a few minutes of blocks and a decision about order. The slow part is usually the discussion, and the point of the concept is to have that discussion before the work, not instead of it.

Should a layout concept include real components?

Start with blocks so the structure is visible. Once the order is agreed, replace the blocks with the real components, for example a Nav bar, a Card or a List item, and the structure stays intact because the container is already laid out.

Do I need a different concept for mobile and web?

Start with one concept and a content priority list, then adapt it. If the same blocks in the same order work on both sizes, the concept is responsive. If they do not, the difference in priority is worth making explicit before you build.

Can I show the concept to stakeholders before it is polished?

Yes, and you should. Present mode walks through the frames in order, so a gray concept is easy to present. Present the concept as a decision to be made, not as a design to be approved, and say which decision you need from the room.

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.