The big idea: A prototype only tells you the truth when real people use it in the real place, so run it live, count what happens and let each round decide your next change.
In 60 seconds
- A prototype only tells the truth when real people use it in the real place.
- Track one key behavior, count what people do, then collect quotes that explain it.
- Change one thing per round, and let the numbers say iterate, pivot or pilot.
Do this: run live testing rounds and log the evidence for your Final Prototype Presentation and HCD Technical Report.
How live prototyping works
A prototype that works in class can still fail at the counter, on the floor or in the hallway where the problem lives. Live prototyping puts your idea into the real setting, with real people, for a short time, so you learn what actually happens. Then you keep iterating and keep getting feedback until the evidence says pilot, or pivot.
Pick the riskiest assumption
Ask: what must be true for this idea to work, and what are we least sure of? Test that first.
Example: patients will read a discharge card before they leave.
Run it in the real context
Real place, real users, real time pressure. Keep it short: a morning, a shift, a week.
You need: client permission and a simple version people can use.
Watch and count
Track one key behavior: what people DO, not only what they say. Note quotes and workarounds.
You log: “7 of 10 did it” plus the top complaint.
Decide and repeat
Iterate if the number is rising. Pivot if it is stuck. Pilot when you hit your target.
Then: change one thing on purpose and run the next round.
Live means three things are real
The place (where the problem happens), the people (the users you studied, not teammates) and the stakes (they are trying to get something done). If one of the three is fake, you are still rehearsing. That is useful, but it is not live.
Three ways to get feedback in context
Describe the marketplace
Before you go live, map where your idea will sit: who already serves this need, what people use today and what your idea replaces.
Watch out: if people already have a workaround they like, your idea must beat it, not just exist.
Solution interviews
Let people use the prototype, then ask short follow-ups: what did you expect, where did you hesitate, what would make you use it again?
Watch out: people are polite. Ask about what they did, not whether they like it.
Structured usability testing
Give each person the same task, watch without helping, and count who finishes, how long it takes and where they get stuck.
Watch out: if you explain the prototype first, you are testing your explanation.
Iterate signals
The key behavior is rising round over round. Complaints get smaller and more specific (“the font is small” instead of “I do not get it”). People start using it without your help.
Pivot signals
Two or three rounds with no movement. The same deep complaint keeps coming back. People use a workaround instead. Your insight may be right while the concept is wrong.
How real does the prototype need to be?Fidelity options from cheapest to most real
Paper or role play
A printed card, a script or a staged walkthrough.
Use it when: you are testing whether the idea makes sense at all.
Behind the curtain
It looks automated, but your team does the work by hand (for example, texting people when an order is ready).
Use it when: the tech is expensive and you need to know if people want it first.
Pop-up or limited run
A temporary setup in the real place: one counter, one shift, one dining hall.
Use it when: you need to see real behavior under real time pressure.
Working version
The real thing for a small group, close to how it would run every day.
Use it when: earlier rounds are strong and you are getting ready to pilot.
Match fidelity to the question. A rough version gets more honest feedback, because people do not worry about hurting a finished product.
Keep iterating, keep getting feedbackMake feedback a habit, not an event
- Change one thing on purpose each round. If you change five things at once, you cannot tell which one moved the number.
- Write the change down before you test. “Round 3: added a call-if box.” This becomes your iteration story.
- Close the loop. Tell the people who gave feedback what you changed. They give better feedback next time.
- Keep a standing feedback channel. A comment card, a two-question survey or a monthly check-in with frontline staff keeps learning going after your class ends.
- Report the misses. Ideas you dropped, and why, are evidence of rigor in your report.
Live testing and ethicsPermission, honesty and privacy in the real setting
- Get your client’s permission before you test on site, and follow their rules for staff, customers or patients.
- Tell people they are trying a test version and that it is optional.
- Do not promise a service you cannot deliver after the test ends.
- Collect only what you need. Do not record names or private details you do not need, and never put confidential client data into a public AI tool.
Review consent and ethics in Stakeholder Interviews and Ethics.
Live prototypes across disciplinesWhat this looks like outside a classroom
Hospital discharge
A one-page going-home card tested on one unit for a week.
Key behavior: patient can say back their medicines and follow-up date.
Supply chain receiving dock
A color-coded tag for urgent inbound parts, run on one shift.
Key behavior: urgent parts reach the line within 2 hours.
Finance team month-end close
A shared checklist with owners and due times for one closing cycle.
Key behavior: every step signed off by its due time.
City permit counter
A printed “what to bring” checklist handed out at the door.
Key behavior: applicant arrives with every document.
Try it: Live Prototype Log
Tool · BUAD 497
Live Prototype Log
Log each round of live testing and see whether to iterate, pivot or move to a pilot.
- 1Log
- 2Read
- 3Share
Why this signal
Round notes
Put it to work: testing evidence for your presentation and report
Live testing is the evidence behind your Final Prototype Presentation (what testing showed and your next steps) and the Prototyping, Testing and Iteration section of your HCD Technical Report and EUReCA poster. Log it as you go so you are not rebuilding it from memory in March.
Name the key behavior and target
Write one behavior you can watch, and the percent that would count as working.
Your deliverable: one line in your testing plan, such as “8 of 10 applicants arrive with every document.”
Run round 1 in the real setting
Get client permission, pick a short window and test with real users.
Your deliverable: round 1 in your Live Prototype Log, with counts and the top quote.
Change one thing and run again
Fix the biggest problem from the last round. Write the change before you test.
Your deliverable: a “what changed and why” line for each round in your Weekly Consulting Brief.
Read the signal
Iterate, pivot or move to a pilot. Share the call with your client contact.
Your deliverable: the testing slide in your Final Prototype Presentation: rounds, results, decision.
Write the iteration story
What you tested, who gave feedback, how you gathered it and what changed, including ideas you dropped.
Your deliverable: the Prototyping, Testing and Iteration section of your HCD Technical Report and EUReCA poster.
Do this, not thatHabits that produce real evidence
Do this
- Test where the problem actually happens.
- Count a behavior, then collect quotes that explain it.
- Change one thing per round and write it down.
- Test with at least 5 people per round, more when you can.
- Report what failed and what you dropped.
Not that
- Testing only with classmates or friends and calling it live.
- Asking “Do you like it?” and counting yeses.
- Explaining the prototype before people try it.
- Changing everything at once, then guessing what worked.
- Showing only the final version in your presentation.
Before you submitCheck your testing evidence
- [ ] At least one round ran in the real setting with real users.
- [ ] Each round lists the version, the setting, the number of people and the result.
- [ ] Each round names what you changed next and why.
- [ ] You can say whether the data says iterate, pivot or pilot, and why.
- [ ] You have client permission for any on-site testing.
- [ ] No names or private details of the people you tested with appear in your slides or report.
Go deeper
Back to all BUAD 497 topics · Next: Implementation: Roadmap, Resources and Partners
In-class team activity · 30 min
Hallway Test Sprint
By the end: A live test plan for your client project with one key behavior, a target, a real setting, and a first mini round run on real people in the building tonight. 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 live prototyping?
Live prototyping puts your idea into the real setting, with real people, for a short time, so you learn what actually happens. A prototype is live only when the place, the people and the stakes are all real. If one of the three is fake, you are still rehearsing, which is useful but does not show how the idea works where the problem lives.
How do you run a live prototype test?
Start by picking the riskiest assumption, the thing that must be true for the idea to work. Run it in the real context for a short window, such as a morning, a shift or a week, with client permission. Watch and count one key behavior, like "7 of 10 did it," plus the top complaint. Then change one thing on purpose and run the next round.
When should you pivot instead of iterate on a prototype?
Iterate when the key behavior is rising round over round, complaints get smaller and more specific, and people use it without your help. Pivot when two or three rounds show no movement, the same deep complaint keeps returning, or people use a workaround instead. Your insight may be right while the concept is wrong. Move to a pilot when you hit your target.
How realistic does a prototype need to be?
Match fidelity to the question you are testing. Paper or role play tests whether the idea makes sense at all. A behind-the-curtain version, where the team does the work by hand, tests whether people want it before you build expensive tech. A pop-up shows real behavior under time pressure, and a working version prepares for a pilot. Rough versions get more honest feedback.
What are common mistakes in prototype testing?
Common mistakes include testing only with classmates or friends and calling it live, asking "Do you like it?" and counting yeses, explaining the prototype before people try it, and changing everything at once. Instead, test where the problem happens, count a behavior and collect quotes that explain it, change one thing per round, test with at least 5 people per round, and report what failed.