How to Wireframe an App: Sketch to Clickable Screens

This guide is for founders, PMs, developers and new designers who need to plan an app's screens before anyone designs pixels or writes code. You'll learn a step-by-step wireframing process, from listing screens to sketching, building grey-box layouts and linking them into a clickable prototype you can test, plus the mobile layout rules that keep wireframes realistic.

TL;DR: Wireframe in this order: define the core task, list every screen, sketch fast on paper, rebuild the best sketches as grey-box digital wireframes at real device size, annotate behaviour, then link them into a clickable prototype and test with five users. Keep it grey until the structure works.

What a wireframe is for

A wireframe is a simplified layout of a screen that shows structure, content and hierarchy without visual design: no brand colors, no final imagery, minimal styling. Its job is to make decisions cheap. Moving a box in a wireframe takes seconds; moving a feature after it's built takes days.

Wireframes answer three questions for every screen:

1. •What is this screen for? One primary job.
2. •What does the user need to see and do? Content and actions, in priority order.
3. •Where does it lead? Every exit and every way back.

Fidelity levels

Most of the value is in low and mid fidelity. Our comparison of Balsamiq vs Figma for mobile wireframes covers which tool suits which stage.

Step 1: Define the core task and the flow

Before drawing a screen, write down the one task that makes your app worth using, and the steps to complete it. For a plant-care app: "Add a plant and get a watering reminder."

Then sketch the user flow as boxes and arrows: open app → onboarding → add plant → set reminder → home with plant. Our guide to the ecommerce user flow shows how to map entry points, decisions and edge cases in detail; the same method applies to any app.

Step 2: Build a screen inventory

List every screen the flow implies, plus the ones people forget. A typical MVP inventory:

Write it as a checklist. You'll tick screens off as you wireframe them, and the empty and error states will remind you they exist. For guidance on the first-run screens specifically, see the onboarding screen design playbook.

Step 3: Sketch fast on paper

Paper is the fastest wireframing tool there is, and it stops you from polishing too early.

1. •Print or draw phone outlines at a realistic proportion (roughly 9:19.5 for modern phones).
2. •Use a thick marker, so you can't add tiny details.
3. •Try Crazy 8s for the most important screen: fold a sheet into eight panels and sketch eight different layouts in eight minutes. The goal is quantity; the third idea is often better than the first.
4. •Sketch every screen in the inventory at least once, roughly.
5. •Pick the strongest version of each screen, or combine parts of several.

Draw with simple conventions: a box with an X for images, horizontal lines for text, rounded rectangles for buttons, a magnifier for search.

Step 4: Rebuild as digital grey-box wireframes

Now move to a digital tool at real device size. This is where wireframes become realistic.

Set up the frame

• •Choose a base device. 393 × 852 pt (recent iPhone) or 412 × 915 dp (typical Android phone) are good defaults. Check other sizes with the device size reference.
• •Mark the safe areas: status bar and Dynamic Island at the top, home indicator at the bottom.
• •Set a layout grid: 16–20 side margins and an 8-point spacing system.

Use real platform structure

Wireframing rules that save time later

• •Use real content, not lorem ipsum. Real headlines, realistic names and plausible numbers expose layout problems early.
• •Stay in greyscale. Use only two or three greys plus white. Color invites opinions you don't need yet.
• •Use one font at three sizes: title, body, caption.
• •Make the primary action obvious with a dark filled button, and keep it in the lower half of the screen within thumb reach.
• •Build reusable components (list row, card, button, input) so changes propagate.
• •Show scroll: let long screens extend past the device height, with a line marking the fold.

Step 5: Wireframe the states

Every data-driven screen has at least four states. Wireframe each one:

1. •Empty: first use, no data yet. Explain the screen and offer one action ("Add your first plant").
2. •Loading: skeleton placeholders in the shape of the content.
3. •Populated: the normal state, with realistic amounts of content, including long text.
4. •Error: what went wrong and how to recover ("Couldn't load your plants. Try again").

Also consider partial states (one item vs. a hundred) and offline behaviour. These are the screens developers end up inventing on their own when wireframes skip them.

Step 6: Annotate behaviour

Wireframes show layout; annotations explain behaviour. Add short notes beside each screen covering:

• •What each tap does and where it leads.
• •Validation rules ("Name required, max 40 characters").
• •Data sources ("Shows plants sorted by next watering date").
• •Conditional content ("Paywall shown only if user is on free plan").
• •Edge cases ("If no reminders are set, show the reminder prompt card").

Number your annotations and keep them short. A developer should be able to read a screen and its notes and know what to build.

Step 7: Link screens into a clickable prototype

Connect the wireframes so people can tap through the flow on a real phone. Most tools, including Figma, support linking frames with tap interactions and previewing on a device. Keep transitions simple: push for forward navigation, modal slide-up for creation flows and sheets.

Our roundup of the best mobile app prototyping tools compares options if you need more realistic interactions.

Step 8: Test with five users

Grey-box prototypes are ideal for testing structure because people comment on flow, not colors.

1. •Give each person a realistic task: "You just bought a fern. Add it and make sure you'll remember to water it."
2. •Ask them to think aloud. Don't help.
3. •Note every hesitation, wrong tap and question.
4. •After five sessions, fix the biggest problems and test again if the changes were large.

Nielsen Norman Group's long-standing guidance is that around five users per round reveals most usability problems, so several small rounds beat one large one.

Step 9: Move to high fidelity

Once the structure tests well, apply visual design: typography, color, imagery and components. This is where AI tools can speed things up: you can generate polished first drafts in floow from your screen inventory and annotations, then compare them against the tested wireframes to make sure nothing structural changed.

Wireframe review checklist

• • Every screen in the inventory exists, including empty, loading and error states.
• • Each screen has one clear primary action.
• • Frames are at real device size with safe areas marked.
• • Navigation follows platform conventions (tab bar or navigation bar).
• • Touch targets meet 44pt (iOS) or 48dp (Android).
• • Real content is used, including long names and large numbers.
• • Every tap has a destination, and every screen has a way back.
• • Annotations cover validation, data and conditional logic.
• • The prototype was tested with at least five users.

FAQ

What is the best tool to wireframe an app?

Paper is best for early exploration. For digital wireframes, Figma is the most common choice because you can move straight to high fidelity in the same file, while Balsamiq is popular for deliberately sketchy, low-fidelity layouts. Whimsical and FigJam work well for combining flows and wireframes.

How long does it take to wireframe an app?

For a focused MVP of 10–15 screens, expect a day or two of sketching and two to four days of digital wireframes, annotations and a test round. Larger apps take proportionally longer.

Should wireframes be in color?

No. Keep wireframes in greyscale so feedback focuses on structure and flow. Color, imagery and brand come in the high-fidelity stage.

What's the difference between a wireframe and a prototype?

A wireframe is a static layout of one screen. A prototype links screens together so people can tap through a flow, and it can be built from wireframes or from high-fidelity designs.

Do I need wireframes if I use AI design tools?

They still help. A quick sketch or screen inventory gives the AI a clear brief and gives you a structure to check the output against. Many AI tools also accept a photo of a sketch as input.

Design it with floow

Turn your wireframes and screen inventory into polished iOS or Android screens on floow.design, then refine through chat and export to Figma or code. If you're earlier in the process, our guide on how to make an app covers validation and scoping first. Try: "Design a plant-care app from this inventory: welcome, add plant (photo, name, species, light level), set watering reminder, home list sorted by next watering with an empty state, and plant detail. Clean iOS style, soft green accent, 44pt tap targets."