by Format-3

Share article

{
"@graph": [
{
"@type": "Article",
"image": {
"url": "https://csuxjmfbwmkxiegfpljm.supabase.co/storage/v1/object/public/blog-images/organization-13731/1786711596990_Designer-hands-assembling-tangible-prototype.jpeg",
"@type": "ImageObject",
"caption": "Designer hands assembling tangible prototype"
},
"author": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"headline": "A step by step prototyping process product teams can actually run",
"publisher": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"inLanguage": "en-GB",
"description": "Discover a practical step-by-step prototyping process that empowers product teams to iterate efficiently, test effectively, and meet their goals.",
"dateModified": "2026-08-14T12:47:07.043Z",
"datePublished": "2026-08-14T12:47:07.043Z"
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"item": "https://format-3.co",
"name": "Format-3",
"@type": "ListItem",
"position": 1
},
{
"item": "https://format-3.co/step-by-step-prototyping-process",
"name": "A step by step prototyping process product teams can actually run",
"@type": "ListItem",
"position": 2
}
]
}
],
"@context": "https://schema.org"
}

A step by step prototyping process product teams can actually run

A step by step prototyping process is a tightly scoped, iterative loop: define the question, build the minimum artefact that can answer it, test it against real users, learn, and repeat until the metric you set at the start is met or missed. Industry guidance settles on a workable rhythm of 3 to 5 rounds per major feature, with each iteration running 1 to 14 days and tests drawing on 5 to 20 participants. That’s the whole shape of it. Everything else in this guide is detail.

Here’s the sequence, stripped to its bones:

• Prepare — align stakeholders on the problem before anyone opens a design tool.
• Define objectives — write the question the prototype must answer, and the metric that will answer it.
• Choose fidelity — match the polish level to the risk you’re testing, not to how the demo will look.
• Build the minimum prototype — the smallest thing that can be tested honestly.
• Test with real users or stakeholders — five to twenty people, structured tasks, recorded outcomes.
• Synthesise findings — turn observations into a ranked list of problems.
• Iterate — fix, rebuild, retest, usually three to five times per feature.
• Handoff or scale — pass a developer-ready package to engineering, or stop.

Tools like Figma, Framer, Sketch, and Adobe XD each handle different points on that fidelity curve, and Fictiv handles the bit digital tools cannot: physical prototypes for hardware and manufactured products. We’ll come back to all five. First, the definition problem, because most teams that struggle with prototyping are actually struggling with a category error.

Key Takeaways

The step by step prototyping process succeeds when teams define the question first, match fidelity to risk, test with 5 to 20 real users across 3 to 5 rounds, and hand engineering a fully annotated, developer-ready package.

Point: Define the question first | Details: Write the exact learning goal and success metric before opening a design tool.

Point: Match fidelity to risk | Details: Use lo-fi for structure, hi-fi for interaction, coded stubs for backend validation.

Point: Test early, test often | Details: Run 5 to 20 participants per round across 3 to 5 iterations per major feature.

Point: Iterate deliberately | Details: Budget 1 to 14 days per iteration depending on fidelity, and retest after every fix.

Point: Prepare for handoff | Details: Package interactive states, specs, and acceptance criteria before engineering starts.

Point: Consider a structured sprint | Details: Format-3 runs discovery-to-handoff prototyping sprints using this exact three-to-five-round cadence.

Table of Contents

• What is the prototyping process, really?
• Why does prototyping actually matter for the business?
• The step by step prototyping process, in full
• Which fidelity level should you actually use?
• Which methods and tools actually speed this up?
• How should you actually run the tests?
• How many rounds and how long should each one take?
• What does engineering actually need to receive?
• When is a prototype actually ready for production?
• What do experienced teams actually get right?
• The trap most teams walk into without noticing
• How Format-3 approaches prototyping for product teams
• Where to go for deeper reading and practical tools
• Sources

What is the prototyping process, really?

A prototype is a testable artefact built to answer one specific question. It is not a wireframe, not a mockup, and it is absolutely not a preview of the finished product. That distinction gets blurred constantly, and the blurring is expensive.

A wireframe shows structure. A mockup shows appearance. A prototype, by contrast, tests structure and flow at low fidelity, or interaction and visuals at high fidelity — but always in service of a question someone needs answered before money gets spent on production code. If you cannot state the question, you don’t have a prototyping brief yet. You have a design task pretending to be one.

Design thinking places prototyping deliberately as the fourth phase, sitting between ideation and testing, precisely because its job is to convert an idea into something testable before a single line of production code exists. That sequencing matters more than most teams admit.

Consider two extremes that both count as legitimate prototypes:

• A paper sketch of three screens, tested with five colleagues in a corridor, answering “does this navigation make sense?”
• A coded stub that calls a real payment API in a sandbox, answering “does our checkout flow survive a failed transaction gracefully?”

Both are prototypes. Neither is a wireframe, and neither is production-ready. The fidelity difference exists purely because the questions differ. Interactivity should scale with the risk of getting the answer wrong, not with how impressive the thing looks in a stakeholder meeting.

Why does prototyping actually matter for the business?

Prototyping exists to kill expensive assumptions before they become expensive code. Three risks show up again and again in product work, and each one costs roughly ten times more to fix after launch than before it:

• Wrong requirements — building the right solution to the wrong problem.
• Unusable flows — a technically correct feature that nobody can operate without a manual.
• Stakeholder misalignment — three departments approving three different mental models of the same feature.

Tie that to outcomes and the case writes itself: faster time-to-market because engineering builds once instead of three times, and lower rework because the expensive mistakes surface on paper or in Figma rather than in a sprint retrospective six weeks after launch. Teams that treat collaboration between design, product and engineering as a continuous thread through prototyping, rather than a handoff event, tend to catch misalignment weeks earlier than teams that don’t.

A note on the numbers that anchor this whole process: industry guidance recommends 5 to 20 participants per usability test round and 3 to 5 rounds of iteration per major feature. Fewer than five users and you risk chasing noise rather than signal. More than twenty and you’re usually paying for confirmation, not discovery. Most usability problems worth fixing surface well within that band.

The step by step prototyping process, in full

This is the operational core: the sequence a cross-functional team runs for one scoped feature, from a standing start to a decision.

1. 
   Prepare and align stakeholders. Get design, product, and engineering in one room (or one thread) before scoping begins. Success looks like a shared one-page brief everyone has actually read. Typical artefact: a problem statement with a named owner. Time: half a day.
   
2. 
   Define learning goals and success metrics. Write the exact question the prototype must answer and the number that will tell you if it succeeded (“80% of test users complete checkout without help”). Vague goals produce vague prototypes. The SDLC prototyping model estimates 0.5 to 2 days for this step, and it’s worth every hour.
   
3. 
   Choose scope and fidelity. Decide what’s in the prototype and what’s deliberately faked. Rule of thumb: match fidelity to the risk, not the audience’s expectations. Budget 0.5 to 1 day.
   
4. 
   Sketch and map user flows. Draw the paths before you build screens. This is where structural problems get caught cheaply, on paper, before anyone touches a design tool. Estimated 1 to 5 days depending on flow complexity.
   
5. 
   Build the minimum prototype. Build only what’s needed to test the stated question. Depending on fidelity, this stretches from a single afternoon of paper cutouts to three weeks of coded stubs; the SDLC estimate runs 1 to 21 days across that whole range.
   
6. 
   Recruit and run tests. Five to twenty participants, structured tasks, someone taking notes who isn’t also running the session. Allow 1 to 7 days including recruitment.
   
7. 
   Analyse and prioritise findings. Convert raw observations into a ranked severity list. Don’t fix everything; fix what blocks the metric. Roughly 1 to 3 days.
   
8. 
   Iterate and re-test. Rebuild the failing parts, retest with a fresh or partially overlapping group. Most features need three to five loops through steps 5 to 8 before the metric stabilises.
   
9. 
   Decide: handoff, scale, or stop. If the metric holds across two consecutive rounds with no new critical issues, move to handoff. If it’s still failing after five rounds, question the premise, not just the pixels.
   

For a single critical flow under time pressure, that whole sequence compresses into a 7-day sprint: goals and fidelity on day one, sketching and building days two to four, testing day five, synthesis day six, and one rapid iteration on day seven. It’s tight, and it works precisely because it forces you to skip anything that doesn’t serve the question. This mirrors the 7-day sprint plan documented for validating a critical flow, rather than a made-up shortcut.

Rapid prototyping practice adds one more discipline worth adopting outright: start low fidelity and apply RITE, Rapid Iterative Testing and Evaluation, to act on findings immediately rather than batching fixes for a future sprint. Batching fixes feels efficient. It usually just delays the bad news.

Pro Tip: Watch for the moment your team starts polishing shadows and micro-animations on a prototype meant to answer “does anyone understand this navigation?” That’s the pretty trap, and it burns days on a question nobody asked. If the fidelity of the artefact has outgrown the fidelity of the question, stop and strip it back.

Which fidelity level should you actually use?

Fidelity is a tool, not a status symbol. Pick the lowest fidelity that can honestly answer your question, and resist the pull towards more polish than the question requires.

• Lo-fi (paper, rough sketches) tests structure and flow. Use it for “does this navigation make sense” or “is the information architecture right.”
• Mid-fi (linked wireframes) tests content comprehension and basic task flow without visual distraction.
• Hi-fi (interactive visuals) tests micro-interactions, visual hierarchy, and stakeholder buy-in on the actual look and feel.
• Coded prototypes test backend integration, performance under real conditions, and edge cases that only show up when the thing is actually wired to a system.

The UX Design Institute is explicit on this trade-off: hi-fi prototypes cost more in time and tooling, and should only be built when the extra fidelity produces learning you couldn’t get more cheaply.

Fidelity category: Lo-fi (paper/sketch) | Best for: Structure, flow, information architecture | Fidelity supported: Lo-fi only | Speed: Hours | Cost: Very low | Recommended round: Round 1, early exploration

Fidelity category: Mid-fi (linked wireframes) | Best for: Content comprehension, task sequencing | Fidelity supported: Lo-fi to mid-fi | Speed: Hours to 1 day | Cost: Low | Recommended round: Round 1 to 2

Fidelity category: Hi-fi (interactive visuals) | Best for: Micro-interactions, visual hierarchy, stakeholder demos | Fidelity supported: Mid-fi to hi-fi | Speed: 2 to 5 days | Cost: Moderate | Recommended round: Round 2 to 4

Fidelity category: Coded prototype | Best for: Backend integration, performance, real edge cases | Fidelity supported: Hi-fi to coded | Speed: 1 to 3 weeks | Cost: High | Recommended round: Final validation round

Moving fidelity up costs more than time. It costs objectivity, too: the better something looks, the harder it is for reviewers to see it critically, and the more expensive it becomes to throw away when testing proves the concept wrong. Climb the fidelity ladder only when the question genuinely demands it.

Which methods and tools actually speed this up?

Method choice should follow directly from the fidelity decision above, not from whichever tool happens to be open on your laptop.

Paper prototyping remains the fastest way to kill a bad structural idea; it costs nothing and forces brutal honesty because nobody mistakes a napkin sketch for a finished product. Linked wireframes step things up to testable flows without visual noise. Digital clickable prototypes handle the interaction and visual layer. Coded stubs handle backend truth. Physical prototyping enters the picture the moment your product leaves the screen.

Here’s where the five tools that dominate this space actually earn their place:

• Figma is the default for linked wireframes through hi-fi interactive prototypes, and its collaborative canvas makes it the natural home for the middle of the workflow. Master components, timed delays, and table-of-contents frames cut repetitive build time dramatically, and reusing a component library across a project means a fix in one place propagates everywhere instead of requiring twenty manual edits.
• Framer pushes past Figma’s interaction ceiling when a prototype needs to feel closer to production, real scroll physics, actual code components, and live data bindings, making it the better choice when the question is specifically about interaction feel rather than structure.
• Sketch still serves teams with established component libraries built up over years, particularly for hi-fi visual design work that feeds into a separate prototyping layer.
• Adobe XD suits teams already embedded in the Adobe ecosystem, offering solid linked-wireframe and hi-fi prototyping without forcing a tooling migration.
• Fictiv covers the ground none of the above can touch: physical, manufactured prototypes for hardware products, on-demand CNC machining, 3D printing, and injection moulding for teams validating a physical object rather than a screen.

Observation Mode and prototype-level navigation features also matter more than most teams realise, because they let a remote stakeholder or test participant move through a prototype without the friction of screen-sharing instructions. For higher-fidelity tests, wiring a lightweight mock API into your coded stub, rather than building the real backend, lets you validate integration behaviour weeks before the actual service exists.

How should you actually run the tests?

A test session without structure produces anecdotes, not data. Structure it the same way every time: a short brief that doesn’t leak the answer, a set of realistic tasks, encouragement to think aloud, an observer taking notes who isn’t the one facilitating, and a debrief that asks open questions before closed ones.

Recruitment follows the same 5 to 20 participant band mentioned earlier, and the rationale holds up under scrutiny: five users typically surface the majority of usability problems in a single flow, while pushing towards twenty makes sense when you’re testing a flow with multiple distinct user segments who might behave very differently. Beyond twenty, most teams are paying for statistical comfort they don’t actually need at the prototype stage.

Capture both kinds of data. Quantitative: completion rate, time on task, error rate, and a single-item ease rating or a full System Usability Scale score if you want something comparable across rounds. Qualitative: the moments where someone hesitates, mutters, or takes a path you didn’t design for. The qualitative data usually tells you why the quantitative number moved.

A grounding statistic worth keeping in view: the same guidance behind the 3 to 5 iteration recommendation also underpins the sample size logic. Enough rounds at the right sample size surfaces the issues that actually block your metric, without inflating the schedule chasing edge cases nobody will hit.

Moderated remote testing, with an observer present on a call, catches hesitation and confusion in real time. Unmoderated testing scales further and cheaper but loses the nuance of watching someone’s face when a flow confuses them. In-person testing remains the gold standard for physical products or anything involving Fictiv-manufactured hardware, where you need to watch someone’s hands, not just their screen.

How many rounds and how long should each one take?

Plan for three to five rounds per major feature. That’s not an arbitrary buffer; it maps to how usability problems actually surface. The first round typically exposes the loudest structural issues. The second and third rounds catch what the first round’s fixes accidentally broke. By round four or five, you’re usually polishing rather than discovering, which is your signal to stop.

Iteration duration scales with fidelity. A paper-prototype loop can run in a single day. A mid-fi wireframe loop typically takes two to five days. A coded-prototype loop, especially one touching real APIs, can stretch to two weeks. The SDLC prototyping model’s 1 to 14 day range per iteration reflects that full spread rather than a single fixed number.

A sample two-week cadence for a mid-fi feature might look like this: days one and two for goal-setting and sketching, days three to seven for building and internal review, days eight and nine for user testing, day ten for synthesis, and days eleven to fourteen for one full iteration and retest. That’s one complete loop in two weeks, which is workable for most product teams without derailing a broader sprint calendar.

RITE, Rapid Iterative Testing and Evaluation, compresses this further by fixing issues between individual test sessions rather than waiting for a full round to finish. It’s aggressive and it’s not for every team, but for a genuinely critical flow under deadline pressure, it can turn a two-week cadence into something closer to a week. Teams exploring a broader non-linear approach to product innovation often find RITE fits naturally alongside it, since both reject the idea that iteration has to be strictly sequential.

What does engineering actually need to receive?

A prototype that never becomes implementable was a research exercise, not product work. The handoff package is what separates the two, and it needs to include realistic content rather than lorem ipsum, accurate spacing and typography values, every interactive state a component can be in (default, hover, error, loading, empty), and annotated specifications for anything animated or logically conditional. Developer-ready handoff also demands clear acceptance criteria, so an engineer building the feature knows exactly what “done” looks like without guessing.

Deliverable: Interactive flow with all states | Typical owner: Designer | When to produce it: End of final testing round

Deliverable: Spacing, typography, and colour specs | Typical owner: Designer | When to produce it: Immediately after fidelity is finalised

Deliverable: Component states (hover, error, loading, empty) | Typical owner: Designer, with engineering review | When to produce it: Before handoff meeting

Deliverable: API contracts or mock endpoints | Typical owner: Engineer, with product input | When to produce it: During coded prototype stage

Deliverable: Acceptance criteria and test cases | Typical owner: Product manager, with designer input | When to produce it: Before handoff meeting

Deliverable: Accessibility notes (contrast, focus order, labels) | Typical owner: Designer | When to produce it: Before handoff meeting

The decision on whether to evolve the prototype’s actual code into production, or discard it and build fresh from the specification, comes down to how the prototype was built. A coded stub built with production-grade patterns and proper state management is often worth keeping and hardening. A prototype thrown together in a rapid tool purely to answer a UX question should usually be treated as disposable, its value fully captured in the annotations rather than in the code itself. Trying to productionise scaffolding that was never meant to survive contact with real infrastructure tends to cost more than starting clean.

When is a prototype actually ready for production?

Three signals together, not one alone, tell you it’s time to stop testing: the prototype meets its stated success metric, no new critical issues have surfaced in the last two rounds, and technical feasibility has been validated rather than assumed. Miss any one of those and moving to production is a bet, not a decision.

Before scaling, run a short risk pass covering the things testing at prototype fidelity rarely catches: performance under real production load, security implications of the actual data flowing through the feature, regulatory requirements relevant to your sector (particularly sharp in healthcare or igaming products), and, for anything physical, manufacturing tolerances and supply constraints that a Fictiv-style rapid-manufacturing partner would flag early.

If the answer is genuinely “we don’t know yet” on feasibility, that’s not a reason to push forward optimistically. It’s the reason the coded-prototype stage exists. Skipping it to hit a launch date is how teams end up rebuilding a feature twice.

What do experienced teams actually get right?

The teams that consistently ship well-tested products share a small set of disciplines, and none of them are complicated. They avoid the pretty trap, deliberately testing with something ugly enough that nobody in the room mistakes it for finished work. They test early, often before there’s anything resembling a real interface, and they build only what’s needed to answer the specific question on the table that week, resisting the urge to add “just one more screen” while they’re in the tool anyway.

Stakeholder demos deserve a different fidelity rule to internal testing. A hi-fi, polished prototype earns its keep in front of an executive sponsor who needs to approve budget on the strength of a five-minute walkthrough. That same polish is often wasted, or actively counterproductive, in front of five test users who should be judging structure, not surface. Matching fidelity to audience, not just to question, is a distinction that a lot of otherwise-competent teams miss.

Pro Tip: Keep two versions of the same prototype in flight when your audiences diverge sharply: a rough, honest build for usability testing, and a polished build for stakeholder demos pulled from the same underlying component library. It costs a little extra setup time and saves you from a stakeholder anchoring on cosmetic feedback during a session meant to surface structural problems.

A workable agency-style checklist for any team running this process:

• Scope: is the question this prototype answers written down somewhere everyone can see it?
• Fidelity: does the build match the risk being tested, not the audience’s expectations?
• Test plan: are sample size, tasks, and success metrics defined before recruitment starts?
• Documentation: is every round’s findings log kept somewhere searchable, not scattered across Slack threads?
• Handoff: does the final package include states, specs, and acceptance criteria, not just static screens?
• Decision log: is there a written record of why the team chose to iterate, scale, or stop at each round?

That last point gets skipped constantly, and it’s the one that saves the most pain eighteen months later when someone new joins the team and asks why a feature works the way it does. Documented decision trails turn “we think we decided this for a good reason” into an actual answer.

The trap most teams walk into without noticing

Here’s a claim I’ll stand behind even though it makes some teams uncomfortable: most prototyping failures aren’t fidelity failures, they’re courage failures. Teams know a flow is confusing after round one. They see it in the test recordings. And then they ship a slightly-improved version anyway, because round two means admitting round one wasn’t good enough, and nobody enjoys standing in front of a stakeholder saying “we need more time.”

The step by step prototyping process only works if the team is willing to be embarrassed by round one. If your first prototype makes everyone in the room a little uncomfortable with how rough it looks, you’ve probably built the right thing. If it looks impressively finished and everyone nods approvingly, ask yourself what question it was actually built to answer, because a genuinely testable prototype rarely survives its first contact with real users without looking a bit foolish. The polish comes later, once the structure has earned it.

How Format-3 approaches prototyping for product teams

Format-3 runs this exact discipline for clients across healthcare, entertainment, energy, igaming, and SaaS, and the pattern holds regardless of sector: teams that skip straight to hi-fi builds spend more time in rework than teams that spend a week being deliberately rough first. Rather than a generic design retainer, Format-3 structures rapid prototyping sprints around a single scoped question, moving from discovery through a developer-ready handoff package in the same rhythm outlined above, three to five rounds, real users, no polish before the structure is proven.

That end-to-end capability, design, engineering, and delivery under one roof, means the handoff checklist in this guide isn’t theoretical for Format-3’s teams; it’s what actually gets passed to the engineers building the production version. If your team is staring down a feature with more open questions than confidence, a discovery conversation costs nothing and tells you fast whether a structured sprint would save you a quarter of rework. Explore Format-3’s services to see how a scoped prototyping sprint could fit your next release.

Where to go for deeper reading and practical tools

For teams building out their own version of this workflow, a handful of sources are worth bookmarking directly rather than relying on secondhand summaries.

• UXPin’s guide to prototype types and fidelity covers the full range from paper to coded prototypes with practical detail on choosing between them.
• The UX Design Institute’s prototyping guide is a strong reference for the lo-fi versus hi-fi decision and when each earns its cost.
• Figma’s own best-practices documentation walks through master components, Observation Mode, and other tactics that shave real hours off build time.
• The SDLC prototyping model breakdown is the clearest source available for realistic per-phase time estimates, including the 7-day sprint plan referenced earlier.
• UX Pilot’s rapid prototyping and RITE method guide is worth reading in full if your team wants to move faster between rounds without losing rigour.
• Mural’s breakdown of prototyping within design thinking is useful context for teams trying to place prototyping correctly relative to ideation and testing phases.

Between those sources and the sequence laid out here, a product team has everything needed to run a first prototyping sprint this week rather than next quarter.

Sources

• What Is a Prototype? A Complete Guide to Types, Fidelity, and Tools (2026)
• Prototyping: The Complete Guide for UX Designers
• Prototyping model in SDLC explained: step-by-step guide
• Rapid prototyping for product design in 8 steps
• Five ways to improve your prototyping workflow

By Format-3

Press & Media

More thoughts

Thought leadership creates value, builds knowledge and takes a stand, bridging the gap between traditional and digital platforms