The ‘minimum viable prototype’: how much reliability is really needed to answer your question?

In design, we’re often taught that prototypes flow linearly: sketch, wireframe, high-fidelity mockup, interactive prototype, coded MVP. This is a process of fidelitybut not necessarily a process of learn. The result is teams spending weeks polishing a Figma prototype to test a basic user flow, or engineers building a fully functional product to answer a question that a simple conversation could have solved.

The real skill is not in building prototypes. It’s under construction the least amount of prototype needed to learn the most important thing. This is the Minimum Viable Prototype (MVPt): the simplest and fastest artifact that reliably tests your specific hypothesis.

The decision framework: match loyalty with your demand

Stop asking, “Which tool should we use?” Start asking, “What should we learn?” Your prototype is an experiment. First define the hypothesis.

1. Hypothesis: “Is this concept fundamentally valuable or understandable?”

You test: The core idea, metaphor or value proposition.

• Minimum feasible prototype: A storyboard or an outline of a value proposition.
• Tool: Paper, whiteboard, a simple digital sketch.
• Why it works: You need story and response, not interaction. Show a series of 3-4 panels that represent the user’s problem and how your concept solves it. Present it and ask, “Does this seem like it would solve a real problem for you?”
• Example: Testing a new “family calendar” concept. Don’t design screens. Draw a mom who sees a notification that soccer practice is being rescheduled, easily swaps times with another parent, and updates the calendar for the entire family. The test is the “aha!” moment, not the button style.

2. Hypothesis: “Does this information architecture or workflow make sense?”

You test: Structure, hierarchy and navigation logic.

• Minimum feasible prototype: A low-fidelity wireframe or a clickable wireflow.
• Tool: Figma/FigJam in wireframe mode, Balsamiq, or even paper with an overlay linking tool like Marvel.
• Why it works: You need to test categorization and flow without the distraction of visual design. Use gray boxes, lorem ipsum and simple links. The user’s ability to find an important piece of information or complete a multi-step task is the benchmark.
• Example: Test a new dashboard layout. Create wireframes with boxes labeled “Monthly Revenue Chart,” “List of Recent Activities,” “Quick Stats.” Ask the user to ‘find where you can see which customers were late paying’. If they click the right box, your IA will work.

3. Hypothesis: “Do users understand what this UI element is and what it does?”

You test: Clarity of capabilities, labels and visual hierarchy.

• Minimum feasible prototype: A high-fidelity, static mockup of a single state or critical screen.
• Tool: Figma, Sketch, Adobe XD.
• Why it works: You need realistic images to test immediate understanding. Present one screen or a comparison of two variants (A/B). Ask the 5-second test question: “What can you do on this screen? What is the most important element?”
• Example: Testing a new pricing table. Design it with the final typography, colors and styling. Question: “Which plan seems best for a small team of five?” If they hesitate or misinterpret the features, your visual communication has failed.

4. Hypothesis: “Can users successfully complete this specific, interactive task?”

You test: The usefulness of a specific interaction sequence.

• Minimum feasible prototype: A high-fidelity, interactive prototype of a single, directed stream.
• Tool: Interactive features in Figma, Protopia, Framer.
• Why it works: You have to simulate the feeling of the interaction. The prototype should only contain the ‘happy path’ and key error states for that one flow. The click goal, feedback, and transition are what you evaluate.
• Example: Testing a new payment flow. Build a prototype that goes from shopping cart to order confirmation. Can they enter promotional codes, select shipping, and understand the progression steps? The interactivity here is non-negotiable.

5. Hypothesis: “Does this feel good? Does it work in real-world conditions?”

You test: The holistic experience, technical feasibility and performance.

• Minimum feasible prototype: A coded prototype in the target environment.
• Tool: HTML/CSS/JS, React/Vue prototype, a no-code tool like Webflow.
• Why it works: For testing complex animations, real form validation, actual API calls, or real mobile device behavior, only code gives you real reliability. The ‘feel’ of a native swipe gesture or the loading time of an image grid is impossible to perfectly recreate.
• Example: Testing a new drag-and-drop interface or real-time collaboration feature. You need to test the latency, the tactile feedback, and the edge cases that Figma can’t simulate.

The anti-pattern: the ‘just in case’ prototype

The most common waste is building an interactive prototype with high fidelity if your question is about concept value. You spend days connecting every screen, polishing micro-interactions, only to find out in the first 30 seconds of testing that users don’t even want the feature. You tested the reliability of interactions when you needed to test concept validity.

The MVPt mantra: Start with the question, not the tool

Use this script on your next kickoff:

1. “What is the biggest unknown we have about this design?”
2. “Let’s formulate it as a testable hypothesis: ‘We believe that [doing X] will result [user outcome Y].’”
3. “What’s the simplest artifact we can create to prove or disprove that?”

This disciplined approach saves your most valuable resources: time and attention. It ensures that every hour spent prototyping is an hour spent learning, not just creating. It frees you from the tyranny of high-fidelity and makes you a strategic scientist of the user experience.

Build just enough to learn. Then decide what to build next.