UI and UX design
Interactive prototype design
An interactive prototype is a clickable model of a website or app that lets people try a task before any code is written. It might be a set of linked wireframes or a near-final design with transitions and realistic content. Prototypes are used to test whether people can complete tasks, to show stakeholders how something will work, to explore ideas quickly and to give developers a clear picture of intended behaviour. The key decision is how much to build: enough to answer the question being asked, and no more, because time spent polishing a prototype is time not spent learning from it.
This page covers fidelity, what to link, content, test tasks, limits of prototypes and what happens after testing. LetGetGrow provides wireframes, interface design, prototypes, design systems and usability reviews, with the scope, cost and timeline set out in a custom quotation.
Illustrative diagram
- Question
- Tasks
- Build
- Test
- Decide
Choosing fidelity
| Question | Suitable prototype |
|---|---|
| Can people find their way? | Linked low-fidelity wireframes |
| Do people understand the steps? | Mid-fidelity screens with real labels |
| Does the visual design communicate? | High-fidelity screens |
| How should transitions feel? | High fidelity with animation for specific moments |
Start with the question
Write down what the prototype must help you decide. 'Can new customers book a delivery slot without help?' leads to a prototype of that path only, with the screens and choices it involves. 'Does the new home page make the offer clear?' needs fewer clicks but realistic visual design. A clear question keeps the prototype small and the test focused.
Link what will be tested
A prototype does not need every link working. Link the paths in the test tasks, plus obvious alternatives people might try, and make other areas show a simple 'not part of this test' message. That way participants are not stuck, and the prototype takes days rather than weeks.
Realistic content
Placeholder text hides problems. Real product names, prices, error messages and long names show whether layouts cope and whether people understand the words. Where data is sensitive, use realistic made-up examples.
From question to findings
Question
What must we decide?
Output: Test goal
Tasks
What participants will try.
Output: Test script
Build
Screens and links for those tasks.
Output: Prototype
Test
Sessions with users.
Output: Notes and recordings
Decide
What to change.
Output: Findings and next steps
A simple test script
Before
- Explain it is the design being tested, not them
- Ask them to think aloud
Tasks
- Realistic scenarios, not instructions
- Three to five tasks per session
After
- What was easy or confusing
- Anything they expected but did not find
How many people
Nielsen Norman Group's guidance is that small qualitative tests with around five comparable users, repeated as the design improves, uncover many problems. If your users fall into distinct groups, test with a few from each. Small tests find problems; they do not measure how often something happens.
Example: a quote request form
Illustrative example — not a client case study
Situation: A removals firm wants to know whether customers can request a quote online.
- The team writes one question: can a customer describe their move and get to a quote request without calling?
- A mid-fidelity prototype links only the quote path, with realistic room lists.
- Five recent customers try it; three struggle with the step asking for item volumes.
What this shows: The step was redesigned before any code was written. This example is illustrative.
What prototypes cannot show
Prototypes do not show real performance, real data volumes or how people behave over weeks of use. They are a model. Treat findings as strong signals about understanding and flow, and plan to check again once the real product is live.
Prototypes for stakeholders
A clickable prototype often explains an idea better than a slide deck. When showing it to stakeholders, be clear which parts are fixed and which are open, so feedback focuses on what can change.
After the test
Summarise what happened on each task, rank the problems by how much they got in people's way, and decide what to change. Update the prototype and, if the changes are large, test again with a few new people. Keep the findings with the design files so developers and later designers understand why the design looks the way it does.
Remote or in person
Prototypes can be tested in person or over a video call with screen sharing. Remote sessions make it easier to reach people across the country; in-person sessions let you see how people hold a phone or use the product in context.
Tools
Design tools such as Figma support linked screens, overlays, transitions and shareable links, which is enough for most tests.
Questions about interactive prototype design
What is an interactive prototype?
A clickable model of a site or app for trying tasks before build.
How polished should it be?
Only as polished as the question needs.
Does every link need to work?
No; link the tested paths and likely alternatives.
How many people should test it?
Around five comparable users per round, more for distinct groups.
What can prototypes not show?
Real performance, data volumes and long-term use.
Why use real content?
Placeholder text hides layout and wording problems.
Sources referenced
Platform features, guidance and rules change. We check the current versions before committing to an approach. This page is general information, not legal advice.
- Nielsen Norman Group: Why you only need to test with 5 users (opens in a new tab) — reviewed 2026-11-03
Request a Custom Quote
Ask about Interactive prototype design
Thank you — your enquiry has been sent.
We have received your message and will reply by email. If you need to add anything, email info@letgetgrow.com.