The short version: building a mobile app is expensive. Changing a built mobile app is more expensive. Changing an app after launch is the most expensive.

So that's why prototyping exists - to move decisions as early as possible in the process (when they're cheap) rather than as late as possible (when they're not).

A mobile app prototype is a representation of the product at a stage before significant development investment has been made. It's designed to answer specific questions about the product — does this flow make sense, does this feature work as intended, will users understand how to use this — at a cost that's a fraction of what those same questions cost when answered in code.

The businesses that skip prototyping to save time almost always spend more total time on the project than the ones that didn't. The discovery of a fundamental UX problem three weeks into development, when it requires a significant architectural change, is categorically more expensive than the same discovery during a prototype review, when it requires a designer to move some boxes around in Figma.

Stage One: Discovery and Requirements

Prototyping starts before anything is drawn or built. It starts with understanding — clearly, specifically, and in writing — what the app is for, who it's for, and what it needs to do.

This means: mapping the users and the specific problems they have, defining the core user journeys the app must support, establishing what a successful outcome looks like for each journey, and identifying any technical constraints or integration requirements that will affect how the product is built.

The output is a product requirements document — a written reference that both the product team and the development team work from. Vague briefs produce vague prototypes. Specific requirements produce specific prototypes that test specific hypotheses.

This stage is frequently underinvested in. The founders who want to "just see something" and skip to design are the ones who end up redesigning the prototype multiple times because what they saw wasn't what they meant. Requirements are cheap. Revisions are not.

Stage Two: Wireframing

With the requirements clear, wireframing translates them into the structural layout of the app — screen by screen, flow by flow.

A wireframe is a low-fidelity representation of a screen. Think rough sketch on paper or a simple grey-box layout in a tool like Balsamiq or Whimsical. No colour, no branding, no visual design — just the structural elements: where the navigation sits, what content appears where, how the user moves between screens.

Wireframes exist to answer structural questions before visual ones. Is this the right number of screens for this flow? Does this navigation pattern make sense for this type of user? Is the information hierarchy correct?

These are the cheapest questions to answer in the entire product development process. A structural change at the wireframe stage takes a designer thirty minutes. The same change at the UI design stage takes a day. In development it takes a week.

Not every app prototyping process includes a formal wireframing stage — simple apps with straightforward flows sometimes move directly to high-fidelity design. Complex apps with multiple user types, sophisticated navigation, or novel interaction patterns almost always benefit from it.

Stage Three: High-Fidelity UI Design

This is what most people picture when they hear "prototype."

High-fidelity UI design produces the visual screens of the app — real colours, real typography, real brand elements, real content — in a design tool like Figma. Every screen. Every state. Every interaction. It looks like the finished app.

This stage is where the product becomes real enough to show to stakeholders, potential investors, and — most valuably — real users. The design can be exported as a clickable prototype: you tap a button on screen one, you go to screen two. You fill in a form, something happens. You navigate through the app the way you would in the real version.

The clickable prototype is the core deliverable of the prototyping phase. It's interactive, realistic, and produces genuine user feedback that a static PDF or a verbal description never does.

The work at this stage requires skill in both UX — understanding how users think and move through interfaces — and UI — the visual craft of making something look considered and professional. These are often the same person at the junior level and increasingly separate specialisms at the senior level. A good UX/UI designer for mobile app work charges £400–£800 per day in the UK market. A full high-fidelity prototype for a focused mobile app typically takes one to three weeks of design time.

Stage Four: User Testing

Building the prototype is not the end of prototyping. Testing it with real users is.

User testing at the prototype stage is one of the most underutilised and highest-return activities in product development. It involves putting the clickable prototype in front of five to eight real people who match the target user profile, watching them attempt to complete the core user journeys, and noting where they succeed, where they hesitate, and where they fail.

The insights from five user testing sessions consistently surface the majority of significant usability problems in a product. The pattern that the sixth, seventh, and eighth user encounters is almost always the same as the one the first three encountered.

What you're looking for: moments where the user does something you didn't expect, places where they pause and look for something that isn't there, actions they take that suggest the interface communicated something different from what was intended. Each of these is information that changes the design — cheaply, before development.

User testing at the prototype stage typically produces two to four rounds of significant design revisions. Each revision is a problem avoided in development and a problem avoided in production. The economics favour testing heavily at this stage.

If you have vibe coded your mobile app, you may want to check out our article on the steps to deploy your vibe coded app.

Stage Five: Handoff to Development

A prototype that's been through user testing and revision is ready to hand to a development team.

The handoff is not just giving developers the Figma file and wishing them luck. A proper design handoff includes: documented specifications for every component (dimensions, spacing, typography, colour values), a component library that developers build from, annotations explaining interactions and states that aren't obvious from the visual design alone, and a clear understanding of any design decisions that were made for usability reasons that developers might otherwise implement differently.

Figma has built-in developer handoff features that extract CSS values and measurements automatically. Tools like Zeplin provide a more structured handoff environment. The effort invested here is paid back in fewer "this doesn't look right" conversations during development and fewer design decisions being made ad hoc by developers who shouldn't have to make them.

Mobile app prototyping has a few characteristics that distinguish it from web app prototyping and are worth knowing about.

‍

Platform conventions matter more

‍iOS and Android have distinct design languages, navigation patterns, and interaction models. A prototype designed without awareness of these conventions produces an app that looks technically functional but feels slightly wrong to anyone who uses the platform regularly. Good mobile app prototyping follows platform guidelines — Human Interface Guidelines for iOS, Material Design for Android — while making deliberate decisions about where to diverge.

‍

Touch targets and gesture interactions

‍Mobile interfaces are operated with fingers, not cursors. Tap targets need to be large enough to hit reliably. Gesture interactions — swipe, pinch, long press — need to be prototyped in a way that simulates the real experience. Figma handles this reasonably well for most gesture interactions; for highly gesture-dependent apps, tools like Principle or ProtoPie produce more realistic simulations.

‍

Device frame previewing

‍Seeing the prototype on an actual device — or at least in a device frame at the correct screen dimensions — is significantly more useful than viewing it on a desktop monitor. Figma's preview mode and various mobile preview apps let designers and stakeholders view prototypes on the actual devices the app will run on, which surfaces proportion and legibility issues that desktop preview misses.

‍

Designing for both platforms

‍If the app needs to run on iOS and Android, the prototyping process needs to account for both — either by designing a single cross-platform experience or by producing platform-specific versions where the differences are meaningful. This adds scope to the prototyping work but is significantly less expensive to address in design than in development.

The cost range is wide because scope varies significantly.

A simple mobile app with two to three core user journeys, designed by a competent UX/UI designer including wireframes, high-fidelity screens, and a clickable prototype: £3,000–£6,000. Add user testing and revision cycles: £5,000–£10,000.

A complex app with multiple user types, sophisticated navigation, many screens, and platform-specific design for both iOS and Android: £10,000–£25,000 for the design and prototype work.

These numbers include design only — no development. The prototype is the input to development, not a substitute for it. Development costs sit on top.

Our mobile app development process starts with this prototyping work — not with code.

Discovery and requirements documentation, wireframing for complex flows, high-fidelity UI design for both platforms, a clickable prototype for user testing, and a complete developer handoff. The design phase that precedes development is how we ensure the development phase doesn't produce surprises that take weeks to resolve.

For founders who've already done the prototype work elsewhere and need a development partner to build from it — we do that too.

If you're at the beginning of a mobile app project and want to understand what the right process looks like for your specific product — let's start with that conversation.

Octogle Technologies builds mobile apps from prototype to production — starting with the design and prototyping work that makes the development phase predictable. Tell us what you're building and we'll tell you what the right process looks like.