Most usability trouble in an app shows up long before anyone writes production code, as long as someone taps through a stand-in first. That stand-in is an app prototype, a set of linked screens that behaves like the product just enough to test navigation and task flow.
Designers and product managers use one to test with real users. Founders pull it out to show stakeholders how the app should behave, and developers get a build reference from it later.
Rough versions are fine for this. Virzi, Sokolov and Karis ran two experiments at CHI 1996 and found substantially the same usability problems with low-fidelity and high-fidelity prototypes.
Fidelity does skew other things, though. Sauer and Sonderegger’s 2009 experiment with 60 participants (Applied Ergonomics) suggested that computer prototypes overstate task time, while reduced-fidelity ones inflate aesthetic ratings.
What Is an App Prototype?
Before any production code exists, people can still tap through a product. Designers make that possible by linking screens together, so a tester can finish a task like signing up or placing an order on a stand-in for the real thing.
App prototyping sits under software prototyping, applied to mobile and web interfaces.
What an app prototype contains
Screens come first, everything from onboarding to checkout. Hotspots go on top of them, which are tap targets placed on buttons, icons or headings. Transitions animate the move from one screen to the next, and the navigation flow decides the order in which screens connect. Sample content fills the gaps, whether that’s placeholder or pre-written text, images and data.
Figma’s Help Center shows how these pieces connect. Each link between screens holds a trigger, one or more actions and animation settings, and any button, icon or heading can serve as the hotspot (as of October 2026).
What an app prototype leaves out
There’s no database behind the screens, no server logic and no real user accounts. Whatever data appears is sample content, and the designer pre-sets every response.
Clickable doesn’t mean coded. The server side of the app is back-end development work that comes later.
Why Build an App Prototype Before Development?
Teams build one to find usability problems, win stakeholder sign-off, show investors a believable product, and give developers a build reference. All of that happens before production code exists, so a change at this stage costs a redraw instead of a rewrite.
Kara Pernice of Nielsen Norman Group made the cost case in 2016. A redesign after launch pays for new code and a fresh QA pass. Revised documentation too. A prototype change pays for none of that.
Usability testing
NN/g treats a user interface prototype as a hypothesis, a candidate design that gets tested by watching real users work with it. Sessions tend to surface dead ends in navigation and labels people misread. Sometimes a step feels missing altogether.
Stakeholder approval
A clickable prototype replaces a slide that describes the app with the app itself, screen by screen.
Pernice adds a warning. A rough prototype tells executives the design is unfinished, while a polished one tempts them to approve it for release. Match the polish to the decision you’re asking the room to make.
Investor demos
Kevin Systrom built a prototype of Burbn, the check-in app that later became Instagram, and an investor committed $250,000 while the product was still an idea (Fortune, 2014).
The money backed the concept, not the feature list. Burbn carried too many features, and the team rebuilt the product around photo filters and basic sharing.
Developer handoff
An approved prototype becomes the reference developers build against. They read the screen inventory and layout from it, along with the tap targets and where each one leads, and then the transitions and their order.
A mobile application development team that starts from these answers has fewer open questions about behavior.
App Prototype Types by Fidelity and Interactivity
Two things separate app prototypes from each other. Fidelity covers how closely the thing matches the final product, and interactivity is simply how much of it responds when someone taps.
Nielsen Norman Group’s 2016 framework breaks fidelity down by interactivity, visuals, and content and commands, and a single prototype can rank high on one and low on another.
Low-fidelity prototypes
Sketches, paper screens and plain wireframes sit at the low end. The extreme case is a paper prototype, hand-drawn screens that a team member swaps in by hand as the tester taps.
Preparation takes less time, and changes can happen mid-session. Testers feel less pressure to succeed, and designers stay willing to throw ideas away.
The cost is the human “computer.” A wrong page shown after a tap can distort how testers think the app works, and NN/g recommends piloting the setup before any real session.
Mid-fidelity prototypes
Mid-fidelity just means mixed. One typical mix is clickable screens with grey boxes standing in for imagery but real button labels and menu text.
It’s the level where flows get tested without paying for visual polish.
High-fidelity prototypes
High fidelity suits workflow checks and UI components such as mega menus and accordions. It also works for judging affordance, page hierarchy, type legibility and image quality (Nielsen Norman Group).
The price is that every possible tap needs a pre-set response, and a polished look invites premature sign-off. Testers do behave more realistically here, because the prototype looks like live software.
Static, clickable and functional prototypes
A static prototype is just screens shown in sequence, with a team member playing the computer. Clickable ones have every tap target wired to a response before the session. Go further and you get logic-driven versions, where responses branch on conditions and variables. Functional prototypes sit at the far end, with real data and working code behind the screens.
Figma’s Conditional action runs one set of actions when an if statement is met and another when it is not, and it is available on paid plans (Figma Help Center, as of October 2026).
Nielsen Norman Group warns that clickable prototypes take time because the designer sets a response for every possible action. Figma’s model shows why: every interaction needs its own trigger and action, so effort grows with each tap target a flow needs.
Functional prototypes cross into build territory, which is why teams usually reach them through code or a low-code builder rather than a design tool.
How to pick a fidelity level
Pick the lowest fidelity that can still answer the question the test asks.
If the question is whether the flow makes sense, sketches or grey-box screens will do. If it’s whether people can find and read things, use clickable screens with real labels and layout. Judging how the interface looks and responds needs high fidelity.
NN/g lists the goal of the test, the completeness of the design, the tools in use and the help available as the factors behind the choice, and the rule above is a shortcut for the first one.
Starting in a polished design tool is the common default. It is rarely the cheapest way to learn whether a flow works.
How an App Prototype Differs From a Wireframe, Mockup, MVP and Proof of Concept
Between static design and working software sits the prototype. A wireframe shows structure and a mockup shows appearance, but the prototype is the one that shows behavior. Past that point, a proof of concept tests feasibility, and an MVP is real software in users’ hands.
| Deliverable | What it shows | Working code | Question it answers |
|---|---|---|---|
| Wireframe | Layout and structure | No | Is the structure right? |
| Mockup | Static visual design | No | Does it look right? |
| Prototype | Linked screens that respond to taps | No | Can people use it? |
| Proof of concept | A narrow technical experiment | Yes, often throwaway | Can it be built? |
| MVP | A launchable core product | Yes, production | Will customers want it? |
Sketch’s guide calls a mockup a high-fidelity render of the finished look and a prototype an early model focused on functionality.
Where the prototype sits in the workflow
- User flow
- Wireframes
- Mockups
- Prototype
- Development
The prototype takes the structure and visuals that came before it and adds behavior. Wireframing settles structure first, before color, imagery or interaction come in.
Is a prototype a stage or a property?
Builder.ai’s glossary calls prototyping the final stage of app design, after wireframes and mockups. Sketch and Decode Agency see it differently. To them, a wireframe or mockup that gains interactivity already counts as a prototype.
The disagreement is about naming, not about the work. The label follows interactivity, and the usual order still puts it last.
Prototype versus MVP
Eric Ries defines an MVP by what it teaches. It is the version of a product that allows “the maximum amount of validated learning about customers with the least effort” (Lean Startup).
A prototype only tests whether people can use a design. An MVP has to be real enough to launch, because what it tests is whether customers want the product.
Future Processing adds a planning use: a working prototype gives the team a basis to estimate the time and money an MVP will need.
Prototype versus proof of concept
A proof of concept answers one technical question, such as whether an integration can work at all, and usually runs on throwaway code no user sees (Kanerika). A prototype assumes the build is possible and tests whether people can use the design.
If the main risk is technical, run the proof of concept before designing screens.
Which Tools Build an App Prototype?
For most teams Figma is the default answer, since one file holds the design, the clickable prototype and the developer handoff. Balsamiq is quicker for low-fidelity flows. Axure RP and ProtoPie handle logic-heavy interactions better, and FlutterFlow makes sense when the build is supposed to become a working app.
| Tool | Best for | Pricing model | Main limit |
|---|---|---|---|
| Figma | Clickable flows, shared files, developer handoff | Free Starter plan, paid per-seat plans | Dev Mode is missing on Starter |
| Sketch | macOS interface design with prototype sharing | Per-editor subscription or Mac-only license | Editors work in the Mac app |
| Axure RP | Conditional logic and dynamic content | Per-user subscription | More tool than a first test needs |
| ProtoPie | Complex interactions, device sensors | Free plan, paid per-user tiers | Depth exceeds a simple flow’s needs |
| Balsamiq | Low-fidelity wireframes with linked screens | Per Space by project count, unlimited users | Sketch-style look only |
| FlutterFlow | Functional prototypes that grow into apps | Free plan, then paid tiers | Build effort, not design effort |
The table lists pricing models, not amounts, because plans change often. A wider roundup of prototyping tools covers more names than these six.
Design tools for clickable prototypes
On Figma, the Professional plan’s Full seat costs EUR 16 a month on annual billing and EUR 20 on monthly billing, and it bundles Dev Mode, FigJam and Slides (Figma Help Center, seat structure rolled out March 11, 2025).
Sketch’s Standard plan bundles the Mac app, a web app and a Workspace for sharing prototypes, and unlimited viewers join free (Sketch).
Axure RP models complex flows without production code, using variables, conditions, adaptive views and dynamic panels. ProtoPie prototypes can connect to device features such as sensors and cameras.
Balsamiq stays deliberately small. TechRadar’s review says it aims to be a wireframing tool and nothing more, which puts it with the wireframing tools rather than the full design suites, though it can link wireframes into clickable flows.
No-code builders for functional prototypes
FlutterFlow builds apps visually on Flutter, and its Free plan is aimed at learning and prototyping (FlutterFlow docs).
FlutterFlow announced new pricing in June 2025 and, effective August 18, 2025, retired its Standard, Pro and Teams plans in favor of Free, Basic, Growth and Business, with Enterprise continuing as before. Existing accounts moved to the new plans by September 18, 2025. Older reviews still quote plan names that no longer exist.
A functional prototype answers questions a clickable one can’t, such as whether real data flows work, but it costs build time that a design file doesn’t.
What happened to Adobe XD
Adobe XD is in maintenance mode. Adobe’s support page promises bug and security fixes for existing customers and a significant notice period before support ends (Adobe, as of October 2026).
Creative Bloq reported that Adobe had already stopped selling XD individually and shipped no major updates before the Figma merger was called off. In January 2024 an Adobe spokesperson told Bloomberg the company had no plans to invest further in XD.
Sources disagree on when this started. Bloomberg reports that Adobe put XD in maintenance mode when it agreed to buy Figma in 2022, an Adobe community thread says May 2023, and Adobe’s own page gives no date.
Treat XD as a source of old files, not a place to start new work.
How to Build an App Prototype
Start with one flow, draw its screens, link them with tap targets and test the result before adding anything else. Staying narrow keeps every added screen tied to a question the test needs answered.
- Pick the one task the test must cover, such as onboarding or checkout.
- Sketch or wireframe each step of that flow.
- Match iOS or Android conventions for controls and movement between screens.
- Reuse buttons, headers and form fields from one shared library.
- Add hotspots, transitions and sample content to link the screens.
- Run the flow yourself first, then with real users.
Match iOS and Android conventions
Platform habits decide how a prototype should feel. Apple’s interface guidelines for iOS cover gestures, virtual keyboards and voice, plus input from the device’s gyroscope and accelerometer (Apple Developer, as of October 2026).
Google’s counterpart rests on the Material Design principles. Its latest version, Material 3, splits guidance into foundations, styles and components (Material.io, as of October 2026).
Where builds go wrong
These mistakes come up a lot.
- Prototyping every screen of the app instead of the flow under test.
- Rebuilding components by hand on each screen, so buttons and headers drift apart.
- Shipping one bloated file to a testing platform. Maze’s Help Center says file structure directly affects how a prototype loads, and it recommends a dedicated lightweight page for testing.
Handing the finished prototype to developers
Figma announced Dev Mode at ConFig 2023 to simplify and speed up designer-to-developer handoff (TechRadar).
Anyone with a Full or Dev seat can open it, and a free View seat still allows basic inspection: properties, measurements, copied code and exported assets (Figma Help Center).
The ready-for-dev view, available on the Organization and Enterprise plans, lists designs marked with a status and highlights any design updated since its first handoff (Figma Help Center, June 2025).
How to Test an App Prototype With Real Users
Give 5 users from one target group a realistic task and watch where they hesitate or tap the wrong thing. Fix what you find, then run another round with new users until the main flows work.
Moderated or unmoderated sessions
In a moderated session a facilitator watches live, explains the prototype medium beforehand, and checks whether an idle tester is waiting for a response or thinks the task is done (Nielsen Norman Group). Static and paper prototypes need this mode because a person plays the computer.
Unmoderated testing lets people work alone on their own schedule. Maze’s guide says this mode suits high-fidelity prototypes that need little explanation.
Tools for running prototype tests
Two platforms import Figma prototypes directly.
- Maze builds a test from the prototype’s share link and reports usability metrics, A/B comparisons and heat maps for each screen.
- UserTesting’s Figma integration captures click events and heatmaps through the Figma API.
Both have catches. Maze imports one prototype per test, and it requests read-only access to all of a user’s Figma files (Maze Help Center, Figma Help Center). UserTesting requires each user to connect their own Figma account, with Navigation tasks as the fallback.
How many users to test
Nielsen’s number comes with conditions, and later research disputes it.
These are the figures that come up most.
- 5 users per qualitative usability study (Nielsen Norman Group, 2012)
- 83 NN/g consulting studies, where testing more users added no appreciable insights
- 3 to 4 users per group when audiences overlap
- At least 20 users for quantitative studies
- 18 users found under half of one site’s predicted problems (Spool and Schroeder, CHI 2001)
Both positions are on record. Nielsen says to spend extra budget on more studies, not bigger ones.
Spool and Schroeder tested a complex site. William Hudson, reporting in the SIGCHI Bulletin, read the gap as a task-scope problem: well-defined tasks need about five users per test, while large sites need more test series.
A single focused flow sits on the five-user side of that line. A full app with many flows does not, so run several small rounds, each aimed at one flow.
When an App Prototype Falls Short
Anything that depends on a running system is outside a prototype’s reach, from real response times to unplanned taps, missing states and AI behavior. A prototype can look right on every screen and still say nothing about how the product performs.
A tester may tap something the designer never linked, and the session stalls. Responses arrive on cue every time, so load times and network failures go untested. Empty, loading and error screens are easy to leave out. And AI features show scripted outputs, not model behavior.
NN/g’s script for an unwired tap is to say the page is not working, ask what the tester expected, and offer the closest available screen.
For AI features, NN/g points to Wizard of Oz testing, where a person simulates the responses before the AI exists. The prototype shows the interface, not the model.
Tools such as ProtoPie narrow the gap for hardware-driven features by reading device sensors and cameras. They still simulate the app.
When a smoke test beats a prototype
Eric Ries described a smoke test as a way to measure whether customers want a product before it is built. His own IMVU team spent six months building an instant-messaging add-on that customers did not want (Lean Startup).
Prototype when the doubt is about the interface. When the doubt is about demand, test demand first.
Using a design system tool for UI can help teams organize reusable components and keep the visual experience consistent throughout the prototype. This makes it easier to refine the design while maintaining consistency as the product evolves.
App Prototype FAQ
How much does an app prototype cost?
Mostly designer time, not software. Figma, ProtoPie and FlutterFlow all offer free plans, and paid tiers bill per seat, per editor or per project count.
Budget scales with the number of flows built. For the full build, see the breakdown of mobile app development cost.
Who builds an app prototype?
A UX or product designer usually builds it, working from approved wireframes. Product managers and founders also build simple ones in Balsamiq or Figma.
FlutterFlow suits teams that want a working version assembled visually. Developers join when the prototype has to run real logic.
How long does it take to build an app prototype?
No authoritative benchmark exists, because time follows scope and fidelity. GV’s design sprint builds a realistic prototype in one day by covering only the customer-facing surface.
Nielsen Norman Group lists shorter preparation as a benefit of low-fidelity versions.
Should an app prototype be thrown away after testing?
Partly. Keep the screens and components, and discard the wiring.
Developers can inspect the same design file in Figma’s Dev Mode, while the hotspots and transitions only simulate behavior and get rebuilt as production code.
Does a web app need a different prototype?
Yes, in its conventions rather than its method. A web prototype tests responsive layouts and browser behavior, while a mobile one follows platform patterns from Apple and Google.
Material Design covers the web as well as Android, and Figma and Axure RP handle both.
What is a design sprint prototype?
GV’s five-day design sprint has the team build a facade on Thursday, realistic enough to test and nothing more.
On Friday it goes in front of five target customers in one-on-one interviews, so it covers only the surface those customers touch.
The Smallest App Prototype Worth Building First
Start with a low-fidelity, clickable version of one core flow and test it with about five people from one target group.
The sequence runs cheapest evidence first.
- Name the riskiest assumption about the interface
- Sketch the one flow that tests it, on paper or in Balsamiq
- Raise fidelity only when a finding demands it
A sketch tested with five users surfaces substantially the same problems as a polished file, so the budget saved on visuals pays for a second and third round.
The trade-off is look and feel. A rough version cannot show how the finished design will land, so that question waits for a high-fidelity pass.
Once the flow passes testing, the mobile app development process takes the approved screens into build.
- Protecting Users and Brand Standards Across Image-Driven Platforms - November 10, 2026
- Go Cheat Sheet - November 9, 2026
- Build or White-Label Software? How Software Teams Decide What to Resell in 2026 - November 9, 2026
