What prototyping is and why fidelity matters
A prototype is a representation of your product that you can test before building it. The purpose is always the same: answer a question with the least effort. "Will users understand this navigation?" "Does this checkout flow make sense?" "Is this layout better than that layout?" The form of the prototype should match the question you're asking — nothing more.
Fidelity describes how closely the prototype resembles the final product. Low fidelity (sketches, paper prototypes) is fast and cheap, ideal for exploring broad concepts and testing structure. High fidelity (interactive prototypes with real content) is slower and more expensive, ideal for testing specific interactions and visual design. The critical mistake teams make is using high fidelity too early — spending days on pixel-perfect mockups before validating the underlying concept.
The fidelity trap
High-fidelity prototypes create a dangerous illusion of completion. Stakeholders see polished screens and assume the design is final. Users focus on visual details instead of structural issues. The team becomes emotionally attached to the execution. Use low fidelity when the question is "should we build this?" and high fidelity when the question is "how should we build this?"
The fidelity spectrum
Fidelity Levels Framework
Use this to choose the right level of detail for your current question.
Sketch (lowest fidelity)
Pen and paper, whiteboard, sticky notes. Minutes to create. Tests: concept viability, information hierarchy, flow logic. Disposable by design — the goal is to generate and compare options, not to preserve them.
Wireframe (low-mid fidelity)
Gray boxes, placeholder text, basic layout. Hours to create. Tests: content structure, page layout, navigation flow, information density. No color, no images, no brand — forces focus on structure and hierarchy.
Mockup (mid-high fidelity)
Visual design applied. Real typography, color, imagery. Tests: visual hierarchy, brand expression, readability, aesthetic appeal. Static — no interactions. The gap between mockup and interactive prototype is where many teams stall.
Interactive prototype (high fidelity)
Clickable, sometimes animated. Simulates real interactions. Tests: task completion, navigation comprehension, interaction patterns, edge cases. Can range from "click-through hotspots" to near-functional code prototypes.
Paper prototyping
Paper Prototype Testing Core Method
Use when: exploring early concepts, testing with stakeholders, or validating flow logic before any digital work.
Draw each screen on a separate piece of paper. One person plays the "computer" — when the user taps a button (points to it), the operator swaps in the next screen. This forces you to think through every path, every state, and every response. The low visual fidelity means users focus on structure and flow, not aesthetics. Paper prototypes are fastest for testing navigation structures, information architecture, and multi-step flows. They're also the best equalizer — everyone can draw boxes and arrows, regardless of tool proficiency.
The sticky note variant
For flows with many decision points, use sticky notes on a wall instead of paper sheets. Each sticky note is a screen or state. Arrows between them show the flow. This makes it easy to rearrange, add branches, and see the entire flow at once. It's particularly effective for team workshops where multiple people are contributing ideas simultaneously.
Low-fidelity wireframes
Wireframing Core Method
Use when: defining page structure, content hierarchy, and layout before visual design.
Wireframes are the blueprint. Gray boxes for images, lines for text, rectangles for buttons. No color, no typography decisions, no branding. The constraint is the point — it forces everyone to discuss what belongs on the page and where, without getting distracted by how it looks. Key wireframe decisions: what content appears above the fold, what the primary action is, how navigation works, where secondary information lives. Use real content lengths (not "lorem ipsum") to expose layout problems early — a headline that's 4 words behaves differently from one that's 12 words.
Lorem ipsum is dangerous
Placeholder text hides layout problems. Real content has variable lengths, different languages have different text expansion (German is ~30% longer than English), and actual data reveals edge cases that "User Name" and "Lorem ipsum dolor" never will. Use representative content as early as possible — even rough drafts are better than filler text.
Interactive prototypes
Click-Through Prototypes Core Method
Use when: testing navigation flows, task completion, and screen-to-screen transitions.
Link static screens with hotspot areas — click a button, transition to the next screen. Tools like Figma, InVision, and Marvel make this simple: upload your designs, draw hotspots, link to target screens. No animation, no dynamic content, no conditional logic. The strength is speed: you can have a testable flow in minutes after completing your designs. The limitation: users can only follow pre-defined paths, so unexpected behaviors and edge cases aren't testable.
High-Fidelity Interactive Prototypes Core Method
Use when: testing specific interactions, animations, form behavior, or when you need stakeholder buy-in.
These simulate the actual experience: transitions, animations, conditional logic, input handling. Built in tools like Figma (Smart Animate + variables), ProtoPie, Framer, or code (HTML/CSS/JS). The trade-off: high-fidelity prototypes take significantly longer to build and are harder to change. Use them when the question is about interaction quality, not information architecture. The danger is building a prototype so complete that it becomes the product — if that's happening, you should be building the real thing instead.
Wizard of Oz and concierge prototypes
Wizard of Oz Prototype Core Method
Use when: testing a concept that requires backend functionality you haven't built (AI features, personalization, complex algorithms).
The user interacts with what appears to be a working product, but a human behind the scenes is manually producing the responses. Testing a chatbot? A team member types the responses in real time. Testing a recommendation engine? A person manually selects the recommendations based on the user's input. This lets you validate the concept and the user experience before investing in engineering. Named after the Wizard in Oz who operated a spectacular machine from behind a curtain.
Concierge Prototype Core Method
Use when: validating a service concept before building any technology.
Deliver the entire service manually, person to person. No technology needed. If you're building a meal planning app, do the meal planning for 10 users manually via email. If you're building an appointment booking system, handle bookings via phone calls. This validates demand, reveals the actual user workflow, and surfaces requirements that would be invisible on a whiteboard. The concierge approach is slower per user but generates the richest learning about what the product actually needs to do.
Choosing fidelity for your situation
Fidelity Decision Guide Framework
Use this to decide how much fidelity your current situation needs.
Use low fidelity (paper, wireframes) when: You're exploring multiple concepts. The question is about structure, not aesthetics. You need to iterate quickly. You're early in the design process. You want unbiased feedback focused on flow and content.
Use high fidelity (interactive prototypes) when: The concept is validated and you're refining the experience. The question is about specific interactions or visual design. You need stakeholder or client approval. You're preparing for usability testing with task-completion metrics. You need to communicate motion or transition behavior.
Use Wizard of Oz when: The core value depends on technology you haven't built. You need to validate AI, personalization, or algorithmic features. Building even a prototype is expensive relative to the learning.
Testing with prototypes
Prototype Usability Testing Core Method
Use when: you have a prototype at any fidelity level and need to validate it with users.
The test setup depends on fidelity. Paper prototypes: facilitate in person with one person playing the computer. Wireframes: screen share or print, walk through the flow. Click-through prototypes: give the user the link and a task, observe where they get stuck. Interactive prototypes: run a standard usability test with think-aloud protocol. Regardless of fidelity, the core method is the same: give the user a realistic task ("You want to book a flight from London to New York for next Tuesday"), observe their behavior, and note where they hesitate, err, or succeed.
Set expectations about fidelity
Before testing, tell users what level of fidelity to expect. "This is a rough sketch — I'm interested in whether the flow makes sense, not how it looks." Without this framing, users of low-fidelity prototypes will comment on visual design, and users of high-fidelity prototypes will assume everything is final. Managing fidelity expectations is part of the test protocol.
Templates and checklists
[What specific question will this prototype help us answer?]
[Paper / Wireframe / Click-through / Interactive / Wizard of Oz]
[Which screens or flows are included? What's explicitly out of scope?]
[Who will test? How many users? What tasks? What's the success criterion?]
- The question this prototype answers is written down and agreed on
- Fidelity level matches the question (not higher than needed)
- All screens in the core flow are built and linked
- Happy path is complete and testable end to end
- Key error states and edge cases are represented (if high fidelity)
- Representative content is used instead of placeholder text
- Test tasks are written from the user's perspective, not the product's
- Stakeholders understand the fidelity level and won't treat it as final
- A plan exists for what happens after testing (iteration, not just results)
Real-world examples
Case study
PillPack: concierge-to-product pipeline
PillPack (now Amazon Pharmacy) started as a concierge prototype. The founders manually sorted and packaged medications for a small group of users, delivering them by hand. This validated the core value proposition — people wanted pre-sorted medication packets — before any technology was built. The concierge phase also revealed critical operational requirements (pharmacy regulations, insurance integration, medication interaction checks) that would have been invisible in a traditional prototype. The manual service became the specification for the automated system.
Why it works: The concierge approach validated demand, revealed hidden complexity, and generated the operational knowledge needed to build the real product — all before writing a line of code.
Case study
Airbnb: paper prototyping their early growth
Airbnb's early design process relied heavily on storyboarding and paper prototyping. When redesigning their booking flow, the team sketched dozens of variations on paper, testing the flow with users by physically swapping cards. The paper format forced focus on the fundamental question: "What information does a guest need, and in what order, to feel confident enough to book a stranger's home?" The answer — photos first, then reviews, then price, then booking — became the foundation of their listing page hierarchy.
Why it works: Paper prototyping at the right moment (early, when the question was about information hierarchy) produced a structural insight that still shapes the product years later.
Case study
Google's HEART framework: testing at every fidelity
Google's design teams use different fidelity prototypes for different HEART metrics. Paper prototypes test Task Success (can users complete the flow?). Wireframes test Engagement (does the structure support exploration?). Interactive prototypes test Adoption (do users understand how to start?) and Retention (do users return?). The fidelity matches the metric: you don't need pixel-perfect screens to measure whether someone can find the search bar.
Why it works: Matching prototype fidelity to the measurement goal prevents over-investment in polish before validating fundamentals.
Common pitfalls
Going high-fidelity too early
Starting with interactive prototypes before validating the concept wastes time and creates emotional attachment to unvalidated ideas. A beautiful prototype of the wrong solution is still the wrong solution. Start rough, validate the structure, then increase fidelity incrementally.
Prototyping the entire product
A prototype should test a specific question about a specific flow. Prototyping every screen, every state, and every edge case creates a second product that's almost as expensive to maintain as the real one. Scope ruthlessly: what's the one thing you need to learn? Prototype only that.
Never testing the prototype
Some teams build prototypes that go straight into stakeholder presentations without ever being tested with users. A prototype that wasn't tested with users is a pitch deck with interactions — it demonstrates the vision but doesn't validate it. The purpose of a prototype is learning, not persuasion.