Short answer: A mobile app layout is a fixed vertical order: context at the top, content in the middle, one primary action near the bottom, navigation last. Choose the device frame first, sequence the content by what the user came to do, repeat the same blocks with the Nav header and Tab footer, then re-check on the smallest phone you support.
The zones of a phone screen
A phone screen is a stack of four zones, and most layout mistakes come from putting something in the wrong one. The context zone at the top tells the user where they are, the content zone holds what they came to see, the action zone carries the one thing they should do next, and the navigation zone at the bottom lets them move elsewhere. Fix that order once and every screen in the product inherits it.
The order is a claim about attention, not a matter of taste. When the action sits above the content, the screen reads as a form to be completed. When navigation sits at the top, the screen reads as a list of destinations rather than a place the user is in. Decide which zone owns the content and which owns the action, and apply it to the next screen as well.
- Context zone: the screen title and the Nav header component
- Content zone: the only part allowed to change length
- Action zone: one primary action within thumb reach
- Navigation zone: the Tab footer, in the same spot every time
- The zones are positions, so the content is the only part that grows
Note: The four zones are a convention you enforce, not something the editor draws for you. App Builder will happily stack a Tab footer above your content if you drag it there, so the discipline has to come from you.
Start from the frame, not the artwork
The usual way to start a phone layout is to draw the screen you can picture and fit a device around it later. That order produces artwork with a frame attached. Start from the device instead: choose the frame, set the preset, and let the available width and height push back on the content before anything is drawn.
App Builder opens a mobile frame at 390 by 844, and the frame inspector offers presets for iPhone SE 375 by 667, iPhone 14 390 by 844, iPhone Pro Max 430 by 932, Android 412 by 915 and Tablet 820 by 1180. There is also a Custom option where you type a width and a height yourself, down to a minimum of 120 by 120.
- Add the frame. Open App Builder, choose Add mobile frame from the palette, then set the Preset dropdown in the frame inspector to the device the product ships on.
- Name the screen. Fill in the Name field with the job of the screen, such as Today or Plan detail, so the frame list reads as a sequence rather than a pile of artboards.
- Reserve the device areas. Leave room at the top for a status bar and at the bottom for a home indicator, because a frame draws the device's nominal size and adds neither for you.
Note: The layout concept guide covers the same four zones at concept stage, where the blocks are still placeholders.
Order content by what the user came to do
Content order should follow the sequence of the user's questions, not the order of your fields. Someone opening a screen is working out three things: what am I looking at, is it wrong, and what do I do about it. Put the blocks in that order and the screen explains itself without a paragraph of guidance.
The test is quick. Read your blocks from top to bottom and turn each one into the question it answers. When the questions come out in a sensible order, the layout is doing the work. When the third question turns out to be what this is, the screen is out of order.
- Answer the first question in the top third of the screen
- Move anything that interrupts the sequence onto another screen
- Use real labels, since a placeholder hides a long word
- Keep the same order for screens that do the same job
Note: A help link, a settings shortcut and a promotional banner are all real things that real products carry, and all three usually belong somewhere the user goes looking for them rather than pushed into the flow.
Give the screen one primary action
One screen, one primary action. Everything else is supporting, contextual or navigational, and a reader should be able to tell those apart without reading the labels. When two buttons look equally available, the user has to read the screen before acting, and that reading time is the real cost of an undecided layout.
Where the action sits matters as much as how it looks. On a phone the bottom of the content column, just above the navigation zone, is the easiest place to reach with a thumb, so a commit action belongs there. A control that must stay in view while content scrolls is a different case and wants a floating action button instead.
- One action gets the strongest treatment of size, contrast and position
- Secondary actions move up into the content rather than sitting beside the primary one
- A persistent control becomes a floating action button, not a full-width bar
- Action labels name the outcome, such as Send or Save
Note: The Call to action component in the library panel gives a consistent button shape, and the Button kind in the palette carries the styling options. Neither picks the action for you.
Repeat blocks with the library components
Most phone screens are built from a few repeated shapes, and Canvasola provides seven insertable reusable components for them: Stat card, List row, Form field, Call to action, Empty state, Nav header and Tab footer. Put the Nav header at the top of every screen and the Tab footer at the bottom of every screen, and the set starts to look like one product rather than a stack of unrelated pages.
The two navigation components arrive at 390 pixels wide, which matches the default mobile frame, so they meet the edges without adjustment. A list is one List row copied, and each copy keeps the same height, icon slot and text position, so ten rows read as ten rows instead of ten separate decisions.
- Nav header on every screen, Tab footer on every tab
- One List row shape, copied, for every repeated entry
- Form field for every input, so labels and hints line up
- Empty state wherever a list can come back with nothing in it
Note: You cannot define your own reusable components in App Builder, so the seven listed above are the entire library. Design around them rather than planning a component you would have to rebuild by hand later.
Check the smallest supported phone
Take the design to the smallest phone you support and look again. iPhone SE at 375 by 667 has 15 fewer pixels of width and 177 fewer of height than the 390 by 844 default, which is enough to push a two-line label onto three lines and drop an action below the fold. The design does not change when the frame does; the content has to respond.
Fix what breaks by reordering rather than shrinking. A smaller type size is a decision you will have to defend later, while a reordered screen is not. When the content is genuinely too long for the smallest phone, that is a content problem, and the answer is usually a shorter label or fewer items on screen.
Then check the largest preset, iPhone Pro Max at 430 by 932, for a different reason. A layout that survives a small phone can look stranded on a large one. The spacing guide covers the numbers that keep a stretched row honest, the mobile screen guide covers the styling pass, and the mockup tutorial covers the whole sequence from a blank frame.
- Re-check every screen at the iPhone SE preset
- Reorder or shorten before reducing a type size
- Check the largest preset as well, for content left stranded
- Record which sizes you checked beside the mockup
Note: Resizing a frame re-applies the constraints you set on its children, so a screen that survives a resize is one with real rules behind it. Nothing reflows the content for you, which is exactly why the check has to be done by hand.
A checklist you can reuse
- Every screen in the flow uses the same four-zone order
- The frame preset matches a device the product ships on
- Blocks are ordered by the sequence of questions the user asks
- Exactly one element is the primary action on each screen
- Nav header and Tab footer stay in the same place on every screen
- Lists are built from copies of a single List row
- The design was re-checked at the iPhone SE preset
- Labels are real words rather than placeholders
Common mistakes to avoid
- Starting from the artwork. A screen drawn to a picture and fitted to a phone afterwards ends up with content fighting the width. Set the frame first and let it push back.
- Two actions of equal weight. Two full-width buttons at the bottom force a reading pause before every tap. Demote one and move it into the content.
- Content placed in the navigation zone. Anything above the Tab footer competes with the content for the same strip of screen. The bottom belongs to navigation and the action.
- A different list row on every screen. Rebuilding a repeated shape by hand is how a flow loses its consistency. Copy one List row and change the text inside it.
- Checking only on the design phone. The device you drew on is the one that hides the problems. Check the 375 pixel preset before the screen is called done.
Frequently asked questions
What size should a mobile app layout be drawn at?
Use the preset for the phone the product ships on. App Builder opens mobile frames at 390 by 844 and offers iPhone SE 375 by 667, iPhone 14 390 by 844, iPhone Pro Max 430 by 932, Android 412 by 915 and Tablet 820 by 1180. Designing at 390 and checking at 375 catches a row that stops fitting.
How many destinations should a Tab footer hold?
Four or five is the usual range, and the Tab footer component is built for that kind of row. Keep the set small enough that every label fits its slot without shrinking, and keep the same destinations on every screen so the footer never moves under the thumb.
Can I reuse a custom block across screens?
Not as a reusable component. App Builder offers seven insertable components and you cannot add your own, so a block you invent has to be copied and pasted. Copies keep their structure but not a live link, so a change to the original has to be repeated by hand in every place you used it.
How do I decide what belongs at the top of the screen?
Ask what the user needs to know before they can read anything else, which is usually which screen this is and what the content is about. A Nav header holding the screen title answers both in one element. Data points belong in the content column, where they can be scanned.
Lay out the first screen in four zones.
Open App Builder, add a mobile frame at the preset you ship on, and place a Nav header, the content and a Tab footer in that order.
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.