How to Prototype an App: Tools, Fidelity and Testing

This guide is for founders, PMs and designers who want to test an app idea before paying to build it. Knowing how to prototype an app well saves more money than any other design skill, because it lets you find the problems while they cost minutes instead of sprints. You will get the fidelity levels and when to use each, a tool comparison, a step-by-step build process, and a testing script you can run with five people this week.

TL;DR: Decide what question the prototype must answer, then build the lowest fidelity that can answer it. Prototype one or two key flows, not the whole app. Test with about five target users, give them realistic tasks, stay quiet while they think aloud, and fix the patterns you see before testing again.

What a prototype is (and is not)

A prototype is a simulation of your app that people can interact with, built to learn something. It is not the app, and it does not need real data, a backend, or every screen.

The most useful way to plan one is to write down the question first:

• •"Do people understand what the app does from the first screen?"
• •"Can a new user book a class in under a minute?"
• •"Which of these two onboarding approaches do people finish?"
• •"Will developers understand how this gesture should feel?"

Each question needs a different prototype. A gesture question needs high fidelity; a comprehension question can be paper.

The fidelity levels

Two rules of thumb:

• •Testers judge what you show them. Polished screens get feedback about colours and fonts; rough ones get feedback about the flow. Match fidelity to the feedback you want.
• •Fidelity can be mixed. A high-fi core flow with grey placeholder screens around it is perfectly fine.

If you are still at the layout stage, start with our guide on how to wireframe an app and come back here when you have screens to link.

Choosing a prototyping tool

For a wider ranking focused on realism, see our list of the best mobile app prototyping tools.

Step-by-step: building a prototype

1. Write the test question and success criteria

"Can first-time users find and book a 7am yoga class within 90 seconds without help?" A sharp question keeps the prototype small.

2. Pick one or two flows

Prototype the core loop and maybe one risky moment (payment, permissions, a novel interaction). If you are not sure which screens matter, our MVP app design guide helps you narrow the list.

3. Map the flow before designing

List the screens and taps in order, including the decision points: start → schedule → class detail → choose time → confirm → success. Note what happens if something goes wrong.

4. Design the screens at real device size

Use a real frame, such as a 393 by 852pt iPhone or a 412 by 915dp Android phone, so text sizes and tap targets are honest. You can generate a first draft of these screens in floow from a short description, then adjust them before linking.

5. Use realistic content

Real class names, real times, believable prices, real-length names. "Lorem ipsum" and "Title here" hide layout problems and confuse testers.

6. Link the interactions

• •Every button in the tested flow must work.
• •Add a "dead end" screen ("This part isn't built yet — please go back") for taps outside the flow, so testers do not get stuck.
• •Use platform-standard transitions: push for drilling down, modal for tasks, sheets for options.

7. Run it on a phone

Always test on a real device. Scroll length, thumb reach and text size feel completely different on a 6-inch screen than on a laptop. Figma's mobile app, ProtoPie Player and similar viewers make this easy. For presentations, the phone mockup generator frames screens nicely, but test on the real thing.

8. Do a dry run

Ask a colleague to complete the tasks. Fix broken links and confusing placeholder screens before real participants see them.

How to test a prototype

Recruit the right people

Test with people who match your target users, not friends who will be kind. Write a quick persona with the user persona generator and recruit against it. Nielsen Norman Group's well-known guidance is that testing with around five users uncovers most of the usability problems in a design, and that several small rounds beat one big one.

Write tasks, not instructions

Bad: "Tap the Schedule tab and choose a class." Good: "You want to go to a yoga class before work tomorrow. Use the app to book one."

Tasks describe a goal; instructions give away the answer.

Run the session

1. •Explain that you are testing the app, not them, and that there are no wrong answers.
2. •Ask them to think aloud.
3. •Give one task at a time.
4. •Stay quiet. When they ask "What should I do?", reply "What would you do if I weren't here?"
5. •Note where they hesitate, misclick, backtrack or comment.
6. •After each task, ask: "How easy or hard was that, on a scale of 1 to 5? Why?"

Sessions of 20–30 minutes are usually enough. Record (with permission) so you can rewatch.

Moderated vs unmoderated

Analyse in one hour

Write each problem on a note: what happened, on which screen, how many participants hit it. Group similar notes. Rank by how many people hit it and how badly it blocked them. Fix the top three and test again.

Copy-and-paste test plan

Goal: Can new users book a class in under 90 seconds without help?
Prototype: High-fi, iOS, flows: browse schedule → book class → confirmation
Participants: 5 people who attend fitness classes at least twice a month
Tasks:
  1. Find a yoga class tomorrow before 9am and book it.
  2. Check what you need to bring to that class.
  3. Cancel the booking.
Measures: task success, time on task, ease rating 1–5, observed hesitations
Debrief questions:
  - What did you expect to happen when you tapped Book?
  - Was anything confusing or missing?
  - Would you use this instead of what you use today? Why?

Common prototyping mistakes

• •Prototyping the whole app. You run out of time before testing anything.
• •Too much polish too early. Feedback becomes about visuals, and you become attached to the design.
• •Testing on a desktop browser instead of a phone.
• •Leading the participant with hints, or explaining the design before they try.
• •Testing with the wrong people, such as teammates who already know the app.
• •No question. A prototype without a test question becomes a demo.

FAQ

What is the difference between a wireframe and a prototype?

A wireframe is a static layout showing structure and content placement. A prototype is interactive: you can tap through it to simulate using the app. Wireframes can become low-fidelity prototypes once you link them together.

How long does it take to prototype an app?

A paper prototype takes an hour or less, a low-fidelity clickable prototype of one flow takes a few hours, and a high-fidelity prototype of a core flow usually takes one to a few days. AI design tools can shorten the high-fidelity step considerably.

Can I prototype an app for free?

Yes. Paper prototyping is free, and Figma's free plan supports clickable prototypes and mobile preview within its limits. Several AI design tools also have free tiers that are enough for a small test.

How many people should test my prototype?

Around five people per round who match your target users is a widely used rule from Nielsen Norman Group. Fix the problems you find and run another round, rather than testing with many people at once.

Design it with floow

Generate realistic screens for the flow you want to test, then link and refine them. Try this prompt in floow: "Design a 5-screen iOS booking flow for a yoga studio: class schedule for tomorrow, class detail, time selection, confirm booking, and success screen with add-to-calendar."