The big idea: Build the roughest thing that answers your riskiest question, put it in front of real people, and let what they do decide whether you keep, change or kill it.
In 60 seconds
- Build the roughest version that answers your riskiest question.
- Set keep, change and kill signals before anyone tests, so the results decide for you.
- Test with the people you designed for, and trust what they do over what they say.
Do this: build, test and iterate at least two prototype versions and log what each test taught you.
How prototyping and testing work
Pick the question
Name the one thing you most need to learn about the idea.
You see: “Can a patient explain the plan back without help?”
Build rough
Paper, tape, a role play or a storyboard. Minutes or hours, not days.
You see: something a person can use, not just hear about.
Test with real people
Put it in the hands of the people you designed for. Watch more than you talk.
You see: what they do, where they stall, what they say.
Keep, change or kill
Compare what happened to the signals you set before the test.
You see: a decision with evidence behind it.
Iterate
Build the next version a little more real. Test again.
You see: a record of versions from rough to refined.
Rough on purpose
Tim Brown of IDEO writes that “the goal of prototyping isn’t to finish.” It is to learn what is strong and weak about an idea. The more finished a prototype looks, the less people want to criticize it, and the less its makers want to hear it.
Five-minute prototype
Brown describes surgeons explaining a new sinus tool. A designer taped a whiteboard marker, a film canister and a clothespin together and asked if that was what they meant. With something in hand, the surgeons could say exactly what they needed.
Pick the right kind of prototype
Storyboard
Choose it when the idea is a sequence of moments, like a patient’s trip from bed to front door.
Watch out: people react to the drawings. Ask what they would do at each frame.
Role play
Choose it when the idea is a service or a conversation, like a new check-in script.
Watch out: teammates over-act. Let a real user play themselves.
Paper mock-up
Choose it when the idea is a form, a sign, a screen or a handout.
Watch out: keep it ugly enough that people feel free to mark it up.
Physical model
Choose it when size, space or touch matters, like a kiosk or a waiting area.
Watch out: cardboard is enough. Do not spend a day on a model.
Fake it live
Choose it when you want to see real behavior: a teammate secretly does what the “system” would do.
Watch out: be honest with testers afterward about what was faked.
Small live pilot
Choose it when earlier rounds worked and you need to see it in a real setting for a day.
Watch out: too early, and you spend your time building instead of learning.
How to test with real people
Before and during
- Test with the people you designed for. Friends and teammates are kind, not useful.
- Include an extreme user. The most rushed, most new or most frustrated person shows you where it breaks.
- Do not sell it. Say “we are testing the idea, not you,” then hand it over.
- Ask them to use it. Give a task, not a tour. Ask them to think out loud.
- Stay quiet. When they stall, write it down instead of rescuing them.
After each tester
- Ask open questions. “What did you expect to happen there?” beats “Did you like it?”
- Use I like, I wish, what if. It gets honest feedback without anyone getting defensive.
- Log it at once. What they did, what they said, and one signal: keep, change or kill.
- Separate doing from saying. People are polite. Their actions are the stronger evidence.
Keep, change or kill: set the signals firstDecide what counts as success before anyone tests
Write your signals before the first test so you cannot talk yourself into a result afterward.
Keep
Most testers do the thing the prototype is meant to help them do, without coaching.
Next: raise the fidelity and test a harder question.
Change
The core works, but one part confuses people or gets skipped.
Next: fix that part only and retest it.
Kill
Testers ignore it, work around it, or it does not touch the need you found.
Next: go back to your concepts. Killing early is a win, not a failure.
Prototyping a service, not a productThe Kaiser shift-change example
Brown’s article describes IDEO and Kaiser Permanente nurses rethinking shift changes, when nurses had been spending a long stretch at the nurses’ station handing off patient information. A service cannot be a physical object, but Brown says the prototype still has to be tangible, so the teams acted out new handoffs and filmed them. The design that came out of it moved the handoff to the patient’s bedside, in front of the patient.
Use the same moves for a process in any field: act it out, film it, time it, and let the people who do the work critique it.
Capture feedback in four boxesA simple grid for every test session
Split a page into four boxes and fill it during or right after each test. Stanford’s d.school teaches a version of this grid.
Likes
What worked or got a positive reaction.
Wishes and criticisms
What confused, slowed or annoyed them.
Questions
What they asked. Questions point to gaps in the prototype.
New ideas
What they suggested or what the test sparked for you.
Try it: Prototype Test Planner
Tool · IB 407
Prototype Test Planner
Plan one round of testing, log what each tester does, and know when you have enough to decide.
- 1Plan
- 2Log
- 3Decide
Verdict
How finished it looks
Counted results
Plan checks
Question and signals
- Question this round answers
- Keep if
- Change if
- Kill if
Put it to work: your Prototype and Testing grades
Two London grades depend on this loop. The Prototype grade (40 points) looks for representations people can evaluate and a record of iterations from low to high resolution. The testing part of the Testing/Final Presentation/Storytelling grade (40 points) looks for real-world tests with a range of users and clear results: what worked and what didn’t.
Build it in five steps
Name the riskiest question
Look at your chosen concept from Ideate. What has to be true for it to work? Test that first.
Your deliverable: one testable question per round, written in your notebook.
Build round one in under an hour
Pick the roughest form that lets a person react: storyboard, role play, paper mock-up or cardboard model.
Your deliverable: a photo or short video of version one.
Set signals, then test
Write keep, change and kill signals first. Test with the people you designed for, including at least one extreme user and more than one kind of user.
Your deliverable: a test log: who tested, what they did, and the signal each one gave.
Decide and iterate
Keep, change or kill. Build the next version a little more real, and test the question that is now riskiest.
Your deliverable: versions one, two and three side by side with what each test taught you.
Bring the evidence to the stage
Your final presentation shows the prototype and the story of the tests, including what failed.
Your deliverable: the testing and iterations part of your final presentation, with one tester moment you can describe in detail.
What the rubrics rewardPrototype and Testing levels in plain words
| Points | Prototype | Testing |
|---|---|---|
| 10 | A physical or visual version someone else can understand. | Tries to show a prototype to see if it works. |
| 20 | Something others can evaluate and improve. Partial solution, little iteration. | Sets up a test, gathers feedback and organizes it into actions. |
| 30 | Tests specific features, with a record of iterations from low to high resolution. | A test scenario for users. Feedback on specific features captured for the next version. |
| 40 | Several representations that test features from several perspectives, tested thoroughly. | Real-world tests with several representative groups, with complex results that shape what comes next. |
Do this, not thatHabits that produce real evidence
Do this
- Build the roughest thing that answers the question.
- Set signals before testing.
- Test with the people you designed for, plus an extreme user.
- Write down what people did, not just what they said.
- Keep every version and photo.
- Report what failed.
Not that
- Spending a day on a polished mock-up first.
- Pitching the idea before handing it over.
- Counting your roommates as users.
- Asking “Do you like it?”
- Changing everything after one tester.
- Hiding results that did not go your way.
Before you submitCheck these before the Prototype and Testing grades
- [ ] Each round had one testable question, written before building.
- [ ] We have at least two versions, moving from rough to more refined.
- [ ] We set keep, change and kill signals before testing.
- [ ] We tested with real users from more than one group, including an extreme user.
- [ ] Our log records what testers did and what we changed because of it.
- [ ] We can say what worked and what didn’t.
- [ ] We have photos or video of the prototypes and tests, taken with permission.
Go deeper
Back to all IB 407 topics · Next: Storytelling and the Final Presentation
In-class team activity · 30 min
Ugly Prototype Swap
By the end: A rough version one of your concept, tested live on another team, with a logged result and a keep, change or kill decision for version two. Your instructor will give you the password in class.
Part of the Smith GLS human-centered leadership sequence: IB 407, BUAD 317 and BUAD 497, toward the Human Centered Consulting Certificate.
Frequently asked questions
What is a prototype in design thinking?
A prototype is a question you can hold: the roughest version of an idea that lets a real person react. It can be a storyboard, role play, paper mock-up, cardboard model or small live pilot. Tim Brown of IDEO writes that "the goal of prototyping isn't to finish." It is to learn what is strong and weak about an idea.
How do you test a prototype with users?
Test with the people you designed for, including at least one extreme user. Say you are testing the idea, not them, give a task instead of a tour, and ask them to think out loud. Stay quiet when they stall. Afterward, ask open questions, log what they did and said, and record a keep, change or kill signal.
Why should a prototype be rough instead of polished?
The more finished a prototype looks, the less people want to criticize it, and the less its makers want to hear criticism. Rough prototypes invite honest reactions. Tim Brown describes a designer taping a whiteboard marker, a film canister and a clothespin together so surgeons could say exactly what they needed in a new sinus tool.
What does keep, change or kill mean in prototype testing?
Keep, change and kill are signals a team sets before testing. Keep means most testers do the intended thing without coaching, so raise the fidelity. Change means the core works but one part confuses people, so fix that part and retest. Kill means testers ignore it or work around it, and killing early is a win, not a failure.
How do you prototype a service instead of a product?
Act it out, film it, time it and let the people who do the work critique it. Tim Brown describes IDEO and Kaiser Permanente nurses acting out and filming new shift handoffs. A service cannot be a physical object, but the prototype still has to be tangible. The resulting design moved the handoff to the patient's bedside.