Prototype design: a practical guide to making prototypes
Prototype design means creating a working model of a product or feature to explore ideas, test them with users and communicate intent to stakeholders and developers. Good prototypes are scoped to a clear question, built at the right fidelity, use realistic content, include key interactions and states, and are easy to share and update.
What a prototype is
A prototype is a model of a product or feature that lets people experience how it might work before it is fully built. Prototypes range from rough paper sketches to realistic, clickable mock-ups and even coded versions with real data. Their purpose is to make ideas concrete, so teams can explore options, test assumptions with users and align stakeholders around a shared picture.
This guide focuses on how to make prototypes. For running tests with them, see our guide to prototype usability testing, and for where prototypes fit in the wider process, our post on the UI/UX process for beginners.
Why teams build prototypes
- Explore ideas: Try several concepts quickly before choosing one.
- Test with users: Find usability problems before development.
- Align stakeholders: Give everyone the same concrete picture.
- Guide developers: Show intended behaviour more clearly than specifications.
- Pitch and fundraise: Demonstrate a product vision to investors or clients.
- Estimate effort: Help engineers understand scope and complexity.
Choosing the right fidelity
| Fidelity | How it looks | Time to make | Best for |
|---|---|---|---|
| Paper | Hand-drawn screens | Minutes | Early concepts, workshops |
| Low-fidelity digital | Grey boxes and simple text | Hours | Structure and flow |
| High-fidelity | Near-final visuals and content | Days | Detailed interactions and testing wording |
| Coded | Working code with sample data | Days to weeks | Complex interactions, performance, data-heavy flows |
A good rule is to use the lowest fidelity that can answer your current question. Low-fidelity prototypes are faster and encourage honest feedback about ideas; high-fidelity prototypes are better for testing specific details and presenting to stakeholders.
Planning what to build
- Define the question: What do you need to learn or show?
- Choose key tasks: Select the journeys the prototype must support.
- List screens and states: Include the main path and important alternatives.
- Pick the fidelity: Match effort to the question.
- Choose the tool: Use one the team knows and that supports needed interactions.
Resist the urge to prototype everything. A focused prototype that supports three key tasks well is more useful than a sprawling one that covers every screen superficially.
Building a prototype step by step
- Set up frames: Create screens at the right device sizes.
- Use components: Build from a component library to save time and stay consistent.
- Add realistic content: Use real text, names, prices and images.
- Connect screens: Link buttons and elements to destinations.
- Add transitions: Choose simple, consistent transitions.
- Design key states: Include loading, empty, error and success states where relevant.
- Test it yourself: Click through every path before sharing.
Most teams build prototypes in Figma, which supports linking screens, smart animations and interactive components. Our Figma basics guide explains these features. Specialist tools can handle more complex interactions, such as sensors, conditional logic or realistic data entry.
Realistic content matters
Placeholder text and generic images can hide real problems. Long product names may break layouts, real prices may change how people compare options and actual error messages may confuse users. Using realistic content, in the languages your users read, makes prototypes more believable and testing more reliable. For bilingual products, prototype Arabic and English versions to check right-to-left layouts and text length.
Designing states and edge cases
Real products are rarely in their ideal state. Lists may be empty, data may still be loading, searches may return no results and actions may fail. Including a few of these states in a prototype makes testing more realistic and helps developers understand what to build. Focus on the states most likely to occur in the tasks you are testing, such as a validation error in a form or an empty basket in a checkout flow.
Adding interactions
- Clickable buttons and links for the main paths
- Form fields that respond to focus and input where possible
- Dropdowns, toggles and tabs that change state
- Transitions that show where content comes from
- Back navigation and ways to exit flows
Sharing and maintaining prototypes
Share prototypes with a single link so stakeholders, users and developers always see the latest version. Add short notes explaining what is and is not included. Keep prototypes organised with clear page names, and update them as designs evolve. When handing over to developers, highlight interactions, states and edge cases they need to build. Our guide to effective design feedback helps teams review prototypes productively.
AI can now generate a first prototype from a prompt. See our Figma Make tutorial and our explainer on vibe coding for how that changes the process.
Common mistakes
- Building at higher fidelity than needed
- Prototyping every screen instead of key tasks
- Using placeholder content that hides problems
- Forgetting error, empty and loading states
- Treating the prototype as final instead of testing it
Frequently asked questions
What is the difference between a wireframe and a prototype?
A wireframe shows structure and layout; a prototype links screens together so people can interact with the design.
How long does it take to build a prototype?
From minutes for a paper sketch to several days for a high-fidelity prototype of key journeys.
Which tool is best for prototyping?
Figma is the most widely used. Specialist tools suit complex interactions or device features.
Should prototypes be coded?
Only when you need to test complex interactions, performance or real data. Most questions can be answered with design-tool prototypes.
Can prototypes include real data?
Coded prototypes can connect to real or sample data. Design-tool prototypes usually use realistic but static content.
Who should build prototypes?
Usually designers, but product managers and developers can build simple prototypes too, especially for early ideas.
How many screens should a prototype have?
Only as many as needed to support the tasks you want to test or show, often between five and twenty.