Back to table of contentsCredit: Anthony Lagoon
You think you understand your design problem. You have an idea of how to solve it. Now you just have to build it, and problem solved, right?
Wrong. (But you knew that). Here are several ideas why just building something is the wrong next step:
And so designers prototype. At the beginning of a project, there are many uncertainties about how something will work, what it will look like, and whether it addresses the problem. Designers use prototypes to resolve these uncertainties, iterate on their design, and converge toward a design that best addresses the problem.
This means that every prototype has a single reason for being: to help you make decisions. You don't make a prototype in the hopes that you'll turn it into the final implemented solution. You make it to acquire knowledge, and then discard it, using that knowledge to make another better prototype.
Because the purpose of a prototype is to acquire knowledge, before you make a prototype, you need to be crystal clear on what knowledge you want from the prototype and how you're going to get it. That way, you can focus your prototype on specifying only the details that help you get that knowledge, leaving all of the other details to be figured out later.
Let's walk through an example. Let's say you have an idea for a smart watch application that lets you order delivery pizza with a single tap. You have some design questions about it. Each of these design questions demands a different prototype:
As you can see, prototyping isn't strictly about learning to make things, but also learning how to decide what to make and what it would teach you. These are judgements that are highly contextual because they depend on the time and resources you have and the tolerance for risk you have in whatever organization you're in.
You don't always have to prototype. If the cost of just implementing the solution is less than prototyping, perhaps it's worth it to just create it. That cost depends on the skills you have, the tools you have access to, and what knowledge you need from the prototype.
Because the decision to prototype depends on your ability and your tools, good designers know many ways to prototype, reducing the cost of prototyping. A designers' prototyping toolbox is extremely diverse, because it basically contains anything you might use to simulate the existence of your design. Let's discuss a few genres of prototypes that are common in the software industry, ranging from low to high fidelity.
The fastest and easiest form of prototype is a sketch, which is a low-fidelity prototype that's created by hand. See the drawing at the top of this page? That's a sketch. Get good at using your hands to draw things that you want to create so that you can see them, communicate them, and evaluate them. With enough skill, people can sketch anything, and they almost always do it faster than in any other media. On the other hand, because they have the least detail of any prototype (making them low-fidelity), they're most useful at the beginning of a design process.
Another useful prototyping method is bodystorming:
In this method, rather than using our hands, we use our whole bodies to simulate the behavior and interactions we want to explore. Like sketching, it's incredibly fast, and doesn't really require any special tools.
Sketching and bodystorming are the lowest-fidelity methods of prototyping, requiring very little to prepare. If you're willing to get some paper, pens, and tape, you can also try creating paper prototypes:
Whereas a sketch is just an informal drawing used to facilitate communication, a paper prototype is something you can actually test. Creating one involves creating a precise wireframe for every screen a person might encounter while using a design, including all of the feedback the user interface might provide while someone is using it. This allows you have someone pretend to use a real interface, but clicking and tapping on paper instead of a screen. If you plan the layout of an interface in advance, then decide which parts of the interface you need to change in order to test the interface with someone, you can build one of these in less than an hour.
With even more time, you can use video and video editing to show interactions with an interface:
Another popular technique is called Wizard of Oz prototyping. This technique is useful when you're trying to prototype some complex, intelligent functionality that does not yet exist or would be time consuming to create, and use a human mind to replicate it. For example, imagine prototyping a driverless car without driverless car technology: you might have a user sit in the passenger seat with a couple of designers in the back seat, while one of the designers in the back seat secretly drives the car by wire. In this case, the designer is the "wizard", secretly operating the vehicle while creating the illusion of a self-driving car.
Wizard of Oz prototypes are not always the best fidelity, because it may be hard for a person to pretend to act like a computer might. For example, here's Kramer, from the sitcom Seinfeld, struggling to simulate a computer-based voice assistant for getting movie times:
A more recent example is late-night host James Corden prototyping gesture-based musical instruments for his Apple Watch (with the help of his band):
Beyond these low-fidelity methods are a wide range of higher fidelity prototyping tools, including Balsamiq, Axure, Adobe Experience Design, Visio, Sketch, and OmniGraffle. You can use tools like these to craft layouts, labels, and simple interactions more precisely than you can on paper, and also use them to collaborate on designs. The level of fidelity that these tools offer allow you to closely mimic a final product without having to build a final product, but they take much more time to use, because you have to make more decisions about more details.
Clearly, there are lot of different media you can use to answer a design question. Which one to use depends on the time/fidelity tradeoff that you're willing to make. If you need an answer fast, but can tolerate only a slight increase in certainty, low-fidelity will help you gain a little knowledge very fast. If you're willing to spend more time getting a more certain answer, you probably need something higher-fidelity. There is no right choice: it depends entirely on the context in which you're making the decision.
Busche, L. (2014). The Skeptic's Guide To Low-Fidelity Prototyping. Smashing Magazine.
Hoysniemi, J., Hamalainen, P., and Turkki, L. (2004). Wizard of Oz Prototyping of Computer Vision Based Action Games for Children. In Proceedings of the 2004 Conference on Interaction Design and Children: Building a Community (p. 27-34). New York, NY, USA: ACM. https://doi.org/10.1145/1017833.1017837
Hudson, S., Fogarty, J., Atkeson, C., Avrahami, D., Forlizzi, J., Kiesler, S., Lee, J. and Yang, J. (2003, April). Predicting human interruptibility with sensors: a Wizard of Oz feasibility study. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 257-264). ACM.
Kelley, T., and Kelley, D. (2013). Why Designers Should Never Go to a Meeting Without a Prototype. Slate.
Lehey, R. L. (2014). Letting Go of Sunk Costs. Psychology Today.
Sauer, J. and Sonderegger, A. (2009). The influence of prototype fidelity and aesthetics of design in usability tests: Effects on user behaviour, subjective evaluation and emotion. Applied ergonomics, 40(4), 670-677. Chicago
Snyder, C. (2003). Paper prototyping: The fast and easy way to design and refine user interfaces. Morgan Kaufmann.