Design Thinking Rapid Prototyping, Step by Step

Turn ideas into rough, cheap artifacts users can see, handle, or act out, then learn from how they use them before investing more.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Rapid prototyping is the skill of turning an idea into something a person can see, handle, perform, or react to, quickly enough that you can learn from it before you have invested in it. The Stanford d.school lists Prototype as one of the five modes of design thinking; for background on the full method, see the Design Thinking method page. This page covers only the making: what form to build, which materials to reach for, and how to hand the result to a user without talking them into liking it.

The d.school's working definition is broad. In its Design Thinking Bootleg deck, a prototype is anything that takes physical form: a wall of Post-it notes, a role-playing activity, an object, a space, an interface, or a storyboard. That breadth matters because the right form depends on the question you need answered, not on what the finished product will eventually look like. A service idea can be prototyped with two people and a script. An app flow can be prototyped with paper screens. A room layout can be prototyped with tape on a floor.

The inputs are a candidate idea, usually from ideation, and one specific thing you want to learn about it. The output is two things together: a tangible representation, and the observations, feedback, and decisions about what to refine, reject, or test next, which is how the d.school deck frames the practical result. If you finish a round holding only an artifact and no decision, the round is not finished.

Speed and low cost are the point, not a compromise. The d.school advises keeping early prototypes inexpensive and low-resolution so a team can learn quickly and explore several possibilities rather than committing to one. Rough work also invites honest criticism: people will tell you a paper sketch is confusing far more readily than they will critique something that looks finished and expensive. The skill is knowing how little you can build and still get a clear answer.

How It Works

Rapid prototyping runs as a short loop rather than a single build. IxDF describes design thinking as a non-linear, iterative process in which teams create solutions to prototype and test, and it is most useful on ill-defined problems. Prototyping is where that iteration becomes physical. Each pass should be short enough that throwing the result away feels cheap, and every pass should end in a decision.

flowchart TD
  A[Pick learning question] --> B[Build rough prototype]
  B --> C[Place in user context]
  C --> D[User experiences it]
  D --> E[Observe and listen]
  E --> F{Decide}
  F -->|Refine| B
  F -->|Retest| C
  F -->|Reject| G[Drop the idea]

Start from the question, not the idea. A prototype answers one or two questions well and everything else badly. Before building, write down what you need to learn: will people understand this step, will they trust this handoff, will they choose this option over their current habit. The question decides the form and the fidelity.

Set fidelity to the question. The d.school advises making a prototype understandable enough for another person to use or react to, without spending effort on details irrelevant to the learning objective. If you are testing whether a sequence makes sense, colors and fonts are noise. If you are testing whether a label is clear, the label must be real words, but the rest of the screen can be boxes.

Put it where the user lives. The d.school recommends placing low-resolution prototypes in the appropriate context of the user's life. A checkout idea tested at a conference table misses the queue, the noise, and the phone in one hand. When real context is impossible, recreate its constraints: time pressure, interruptions, the actual device.

Let them experience it. The d.school's testing guidance is "Show don't tell": give only the basic context needed to know what to do, then put the prototype in the user's hands, or put the user in the prototype. Explaining the idea turns a test into a pitch, and you end up measuring politeness.

Observe, then decide. Watch what users do, listen to what they say, and use both to refine the prototype and your understanding of the user and the original point of view, as the d.school deck describes. The loop closes with one of three calls. Refine when the core works but specific parts failed. Retest when results were ambiguous or the context was wrong. Reject when users did not want or understand the core idea, and feed that learning back into how the problem is framed.

You can tell the loop is healthy when prototypes get cheaper to discard, not more precious, and when each round changes something you believed about the user.

Step-by-Step Guide

Step 1: Name the learning question

Write one sentence stating what this prototype must teach you, such as whether first-time users can find the booking step unaided. Add what result would count as a pass and what would count as a fail. Share it with everyone building and testing so no one quietly optimizes for something else. If the team cannot agree on a single question, you probably have two prototypes to build, not one.

Pro tip: Phrase the question around behavior you can watch, not opinions you will ask for, so the test has an observable answer.

Step 2: Choose the prototype form

Match the form to the question using the range the d.school deck lists: Post-it wall, role-play, object, space, interface, or storyboard. Sequence and story questions suit storyboards. Handling and size questions suit rough objects. Navigation and wording questions suit paper or clickable interfaces.

Pick the form that exposes the riskiest part of the idea soonest.

Pro tip: If two forms seem equally good, choose the one you can build faster and keep the other in reserve for the next round.

Step 3: Build with what is at hand

Use materials that are immediately available, such as paper, pens, Post-it notes, slides, and simple objects, which is what the d.school recommends for early prototypes. Build only the parts the learning question touches and fake or skip the rest. Label anything a user needs to understand, and leave everything else deliberately rough. Stop when a stranger could use it without you explaining the concept.

Pro tip: Set a time box before you start, for example 45 minutes, and ship whatever exists when it runs out.

Step 4: Act out service interactions

When the idea depends on interactions between people, services, or environments, prototype it as a role-play, as the d.school deck suggests. Assign roles such as customer, staff member, and system, write a loose script of the key moments, and act out the experience while others observe. Let the person playing the user improvise, because their deviations reveal where the service breaks. Swap roles once so the team feels the experience from more than one side.

Pro tip: Have a teammate who did not design the service play the user, since designers unconsciously follow the happy path.

Step 5: Stage the context

Take the prototype to where the user would actually meet the idea, or recreate the conditions that matter. Bring the real device, simulate interruptions, and match the time pressure people face. Decide in advance the minimum setup sentence you will say, and nothing more. Context failures are a common reason a prototype passes in the office and fails in the field.

Step 6: Hand it over and stay quiet

Give the basic context, put the prototype in the user's hands, and stop talking. Resist answering questions about how it works; instead ask what they expect to happen. Note where they hesitate, backtrack, or improvise, because those moments carry more signal than their summary at the end. Only after they finish should you ask for their thoughts.

Pro tip: Assign one person to run the session and a separate person to take notes, so the facilitator is not tempted to rescue the user.

Step 7: Capture observations and decide

Right after each session, write down what the user did, what they said, and the moments that surprised you, keeping observations separate from your interpretations. Across sessions, look for repeated breakdowns rather than one-off comments. Then make the call against your learning question: refine, retest, or reject. Record the decision and the reason so the next round starts from evidence, not memory.

Best Practices

• Build more than one version when you can. Low-cost prototypes exist so teams can explore multiple possibilities, and users compare alternatives more honestly than they judge a single option.
• Keep fidelity uneven on purpose. Make the element under test realistic and leave everything else crude, which directs the user's attention and your observation to the part that matters.
• Treat each prototype as disposable from the start. Teams that expect to throw work away build faster and argue less about keeping weak ideas alive.
• Test in context whenever possible. The d.school recommends placing prototypes in the user's real setting, because the environment often causes the failures a meeting room hides.
• Weight behavior over stated opinion. What people do with the prototype shows whether it works; what they say afterward often reflects politeness toward the person who built it.
• Let results update the problem, not just the prototype. The d.school describes testing as refining both the solution and your understanding of the user, so revisit the point of view when users surprise you.

Common Mistakes

• Building too much too soon, spending days on a detailed version before any user has seen the idea.: High effort and high fidelity slow learning and make teams reluctant to discard weak ideas. Build the smallest thing that answers the learning question and add detail only in later rounds.
• Presenting the prototype instead of letting users interact with it.: A walkthrough collects opinions, not behavior. Follow the d.school's show don't tell guidance: give minimal context, hand it over, and watch.
• Confusing polish with usefulness, so the team argues about colors while the core flow goes untested.: Early prototypes should be rough, rapid, and inexpensive, with detail added only when it supports the question being tested. If a detail does not affect the answer, leave it out.
• Treating the prototype as the solution, then defending it against user feedback.: A prototype is a learning device inside a cycle of prototype, test, feedback, and refinement, as the d.school deck frames it. Judge each round by what it taught you, not by whether the idea survived.
• Finishing a test round without a decision, leaving notes that no one acts on.: End every round with an explicit refine, retest, or reject call tied to the original learning question. Write down the reason so the next prototype builds on the evidence.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Design Thinking

Related Skills

• Generating Divergent Ideas
• Balancing Desirability, Feasibility, and Viability
• Iterating from Evidence
• Synthesizing User Insights
• Framing Human-Centered Problems

Sources

• Design Thinking Bootleg | Stanford d.school
• What is Design Thinking? - updated 2026 | IxDF
• dschool.sfo3.digitaloceanspaces.com

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.