Why should you create a prototype?

"You are iterating your solution as well as your understanding of the problem" - Aza Raskin

What do you think of when someone mentions building a prototype? We readily use this word in creating software these days, but the origin of this term in manufacturing is relatively recent. The concept of building an electronic version of a product first to validate that it can be built before starting the expensive process of manufacturing a product came into existence in my lifetime.

Just a short twenty years ago I worked on a product that helped optimize the design of aircraft engines before they were manufactured. This product saved our customers millions of dollars. Why? A Boeing 777 engine has 3 million parts provided by 500 suppliers. There are so many constraints involved that changing one simple parameter has ripple effects throughout the engine. What needs to be done to save money, reduce weight and increase efficiency? This is clearly an engineering manufacturing problem.

So we may not be able to achieve as great as results in designing and building software products, but the idea to quickly create something to be reviewed with consumers of the software has a direct benefit to us a well. It seems so obvious to me to build prototypes as that is what I love to do, but I need to step back a bit and explain why they are useful.

Let's start with low-fidelity prototypes first. Now many times have you heard about people starting a company by drawing their ideas on a paper napkin during a lunch meeting? In today's terms that can be translated into creating a Minimal Viable Product (MVP) as quick as possible. In the UX world this is manifesting itself in the popularity of sketching on paper or whiteboards. The idea is the same in both cases, as you want to fail early and inexpensively when it is easy to change directions. When showing end users a low-fidelity sketch, you want to get them to look past the visuals and concentrate on the tasks, scenarios and workflows to validate we have captured them correctly. In this day and age people expecting pretty visuals so this is not always easy to accomplish successfully.

Next up we skip to high-fidelity prototypes. These are visually appealing with nearly complete set of graphics and sometimes fully functional by using fake data that is relevant to the user context. The only indication that these are prototypes and not a real application may be that only certain paths are working. The textual content will be mostly complete so all parts of the app can be tested with real end users. These are really useful to demonstrate progress to upper management or to gather excitement with the sales staff on a new product. The hardest part of building these is to know when to stop and which level of detail is just right. It is too easy for people to keep asking for more functionality to be added to prototype.

Now we have arrived at the ideal, where we build medium-fidelity prototypes. It more than just a sketch but does not take as much as time as a fully functional great looking prototype. The key is to build just enough to communicate the intended design and to get everyone to participate. Whether user testing or giving demonstrations the idea is to catch mistakes early and to quickly correct them. This can be a great tool to gather detailed requirements on what the product should do and to gather feedback.

"The value on an idea is zero unless it can be communicated" - Aza Raskin