Rapid prototyping

Rapid prototyping is building the cheapest, fastest version of something that can answer one design question. The artefact is meant to be thrown away once it has answered, which is why nobody should polish it, defend it in a meeting or ship it.

The question comes first. A prototype that tests whether a flow makes sense looks nothing like one that tests whether a part fits — and building the wrong one wastes the week you were trying to save.

This is where a prototype parts company with a minimum viable product. A prototype asks whether a design can work and how it should behave; an MVP asks whether anyone outside the team actually wants the thing.

Key takeaways

• A prototype answers a design question, not a market question.
• Name the question before you build, or the result will not mean anything.
• Fidelity should be the lowest that still produces an honest reaction.
• Throwing the artefact away is part of the method, not a waste of the money.

How it works

Rapid prototyping runs as a loop: write the design question, choose the lowest fidelity that can answer it, build in hours or days, put it in front of somebody, then decide. The deciding is the step teams skip.

Design thinking supplies the habit of going to the user early, and a product designer usually owns the artefact and the session that follows it.

Fidelity is a choice, not a ladder you have to climb. A paper sketch beats a working build when the question is whether the steps are in the right order, and it beats it by about a week.

Write the question so it can come out wrong. “Can a new user finish setup without help?” is testable, while “is the design any good?” is not, and the second will hand you opinions instead of findings.

Cost is the quiet control here. A prototype costing two people a week gets killed on the evidence — one that cost a quarter gets defended whatever the test said, by the people who paid for it.

Small sessions beat big ones. A handful of people watched closely tells you more about a design question than a survey of hundreds, because you are after the reason rather than the proportion.

Hardware programmes grade prototypes formally. NASA’s 2023 explainer of its technology readiness levels places a fully functional prototype at level six of nine, well before anything is flight proven.

Concept testing sits beside the method and asks a different question again: whether the idea appeals at all, before there is anything to hold.

Agree the decision rule before the build. Without one, any reaction reads as encouragement and the exercise has cost you a week while buying no information at all.

Examples

Three fields show the method at three fidelities, and the logic is identical in each: engineers printing a part overnight, a support team testing a script on paper, and a software team faking the data behind a screen.

Engineering teams print parts overnight. The National Institute of Standards and Technology says additive manufacturing is causing fundamental changes in the way mechanical parts are produced, building shapes from thin layers of metal powder melted by a laser.

That is what made hardware prototyping fast. A part that once needed a tooled mould and a six week wait can now be held, dropped and deliberately broken by Friday, with a second version already printing.

Service teams prototype on paper. A support team in Cebu can test a new call script for a single shift using a printed card, long before anyone edits the customer system, and the awkward line shows itself inside ten calls.

Software teams fake what sits behind the screen. A clickable layout filled with invented data answers a layout question in a day — and nobody has to build the service behind it to learn the layout was wrong.

Regulated settings are the exception that proves the rule. You can still prototype the paperwork, the handover and the screen in a clinic or a bank — never the treatment or the transaction itself.

Throwing the artefact away is harder than building it. Teams that keep a prototype “just as a base” end up shipping the shortcuts they took to go fast, and a week saved turns into a year of maintenance.

None of this is a beta testing program. Beta hands a nearly finished product to real users at scale, while a prototype hands an obviously unfinished artefact to a few people, on purpose.

Related terms

• experimentation program: the standing practice of running tests and acting on the results.
• continuous discovery habits: the weekly rhythm of customer contact that supplies questions worth prototyping.
• minimum viable product: the smallest real thing shipped to test whether people want it.
• design thinking: the wider method that puts user contact at the front of design work.
• concept testing: checking the appeal of an idea before anything gets built.

FAQ

What is the difference between a prototype and a minimum viable product?

A prototype tests a design question, such as whether something can be built or how it should behave. An MVP is released to real users to test whether there is demand for it at all.

How fast is rapid?

Hours to days for most digital work, and overnight for many printed parts. If a prototype takes a month, it has become a build and the learning has been delayed.

Should a prototype use real data?

Only when the question depends on it. Invented data is faster and safer, but anything testing scale, edge cases or privacy behaviour needs the real thing.

Who should see a prototype?

People who match the users you are designing for, plus the team that will build it. Showing it to executives first turns a test into an approval meeting.

Can rapid prototyping be outsourced?

Yes, and design and engineering partners do it routinely. Keep the design question and the decision rule in house, because those are the parts that determine whether the prototype teaches you anything.

See how design and build teams are structured across markets at Outsource Accelerator.