Prototyping is creating a visual or tangible working model of a concept.
Why it’s useful
Prototypes are useful for quickly testing a design, illustrating ideas or features, and gathering early feedback.
The basic principle of prototyping is ‘make to learn’. Prototyping helps you move beyond talking and thinking towards action. The prototype is not the solution itself. It represents ideas, before artefacts are created and implemented.
Prototypes enable you to build in a fast, cheap way and test with users — inviting real input from colleagues, users and your own reflection.
Prototyping is iterative — you won’t get it right first time because that isn’t the point. A good prototype invites improvement.
- Early on, it might be a simple sketch of concepts.
- As you learn from testing the prototype, concepts evolve.
- Later prototypes can be very close to the final product or solution. They can be used to validate and test the final details before production.
Prototypes come in different forms and different levels of detail:
- Rapid — a quick design that you can ‘throw away’ after you evaluate its merits and defects, using the knowledge to develop the next iteration. Examples: sketching, storyboarding.
- Sacrificial — deliberately creating something ‘wrong’ to explore what won’t work, in order to uncover what might.
- Exploratory or low-fidelity — creating something that doesn’t have to look like the actual solution, but works the same. Examples: sketching, storyboarding, role-playing.
- Wireframe — a mock-up of a touchpoint (such as a web page or brochure) that focuses on layout, not content or look-and-feel.
- Developmental or high-fidelity — a prototype as close to the final design as possible. Examples: programmed HTML pages of web screens, mocked-up booklets.
When to do it
Prototypes are learning tools, so can be used at any time in the service design process. They’re often particularly useful in the develop phase.
Prototype when you need to:
- communicate ideas in a tangible way
- explore how a concept might work
- test out a concept or define scope
- explore how a system works, and how changes might affect the user’s experience or the system itself
- act before you have answers
- test assumptions before change is implemented
- evaluate the final solution.
How to do it
- Identify what you’re trying to achieve.
- What tangible output do I need?
- What do I want to learn from creating a prototype?
- What do I already know? For example, research insights, context of problem, design parameters?
- Choose your prototype approach. Examples: sketching, whiteboard.
- Gather inputs. Examples: research insights, typologies, organisational context.
- Brainstorm. Explore what you want to learn.
- Use scenarios, personas and storytelling to progress and test prototypes.
- Evolve and validate the prototypes with real users to find out:
- What works about it?
- What doesn’t?
- How does it make them feel?
First round prototyping
Use these questions to help create an early prototype.
- How would it work?
- What has to happen to make it work?
- What does it look like?
- What are the complementary things that make it work?
- How do you use it?
- Who are the users?
Make a note of any assumptions you make.
Check the prototype is likely to solve the problem you’re trying to address before developing it further in the second round.
Second round protyping
Use these questions to help create a second round prototype that captures what’s needed to implement your concept.
- What are the next steps to make this concept a reality?
- How would it work?
- What are the development or implementation challenges?
- How will it be implemented?
- Production process — what needs to be done to successfully produce the solution? Examples: timelines, resources.
- What other information do we need to progress?
- What can you do in a quick, low-risk, simple way to test the prototype?
Elements of good prototyping
- Start rough and quick so ideas get generated and tested rapidly. Make > evolve > make > evolve > make better.
- Collaborate. Assemble a multi-disciplinary team — design, experience, service owner, such as policy, users.
- Look at exploring different aspects of the problem with a design colleague.
- Set a time-limit — remember rapid and rough is good; that way people don’t get attached. We’re not trying to analyse every aspect of the prototype; we want to actively solve problems.
- Go for quantity if prototyping in a working session — it’s a better use of time (and resource) to explore a lot quickly and learn.