Principles of Effective Prototyping
Although each project will have its own prototyping goal and a choice of fidelity that supports your strategy, the following seven principles of effective prototyping should always be kept in mind:
Be clear on why you are prototyping, and write it down.
Use paper for the first version. Yeah, paper. The stuff in the printer.
Show, don't tell.
Gather inspiration from many sources (patterns).
Prototype what can't be built.
Keep scope to what is required for your reason for prototyping.
Iterate!
In a previous chapter, we spoke about having a prototyping goal. If you have defined a prototyping goal in advance, your chances of success are much higher!
Paper prototyping is the best approach for your very first prototype. Not only it is quicker to create a paper prototype than any other type, but also there is something inherently creative about using a pen or pencil.
The very first prototype that you do is really for yourself. It is to get your own thoughts straight and to be able to create a few different versions of something to see what you like. It's important to be able to quickly visualize several possibilities and to see what works the best.
I have found in the past that certain issues (particularly those involving the flow of screens) are only discovered when you actually see them linked together and when you actually try to click through the flow of a certain sequence.
A prototype is a proxy experience for the final product. Although it may not be fully "real", it should be "real enough" for the purposes of the feedback you want to create.
When working with other team members, it may be that we want to achieve a shared understanding of what we are about to build. When showing a prototype to a potential customer, it may be that we want to see if they understand how to use the product in front of them and/or have observations about why it would be a success or failure.
In both cases, it is better for you to say nothing at first. Watch the person interact with the prototype. Is their reaction and understanding what you expected? If not, is it clear why not? If your prototype is as clear as you think, you should not have to describe anything! Watching the person use the prototype and checking if they follow the intended flows, experience anxiety over what their available options are, or display enthusiasm at an outcome being so easily achieved are what you are looking for.
When building a prototype, the chances are that at least some elements of that prototype have been done before in other products. Become a student of the products around you.
There are lots of great sites out there that show lists of existing design paradigms in the product landscape. For example, if you were thinking about building a calendar, you could check out the calendar pattern on pttrns.com. This will give you lots of ideas and get your juices flowing. Bear in mind this is just inspiration, and your context will be different to some of the sites or apps you see here.
I'll link to more pattern resources in the Additional Resources section at the bottom of this chapter.
It is recommended to prototype anything that cannot be built easily by your team. The reason for this is that if there is enough demand for it, a solution can be found. When we prototype, we want to escape the boundaries of what is sensible and possible. Rather we want to assume that (by magic if necessary), the ideal solutions to a problem are available to us.
If something is hard to build, then it is particularly important that we get feedback on what the reaction would be if this feature or product were built. If the reaction is hugely positive, then a great question is, "How can we make this possible, given that everyone wants it?" This is a better approach than "Let's build it and see if anyone wants it."
It is important to keep scope to what is required for your reason for prototyping.
As we have mentioned already:
Starting with a paper prototype is ideal. This can get you to the point where you are relatively happy with how many screens there are and what the major elements on each screen are.
Then often a black and white prototype is best for getting internal agreement with the team and stakeholders of what to build. Eliminating color and major design elements (e.g. just using a black rectangle instead of an image) will prevent conversations around design happening too soon (i.e before the main interactions are decided). Also, do not include too many screens. You are trying to build consensus within the team and if you include some non-related features, the conversation could end up being focused there!
Finally, a prototype with high-fidelity design is usually used when showing the prototype to customers (whether it is clickable or fully interactive). The same rule applies to not showing too many screens. If there are just enough screens to represent those customers outcomes and flows that you wish to learn more about as defined by your prototyping goal - then that's enough!
The main goal of prototyping is to create an early version of a product/feature that allows us to get feedback that informs later versions of the product.
Specifically, if we get valuable feedback and new insight, the quickest way to verify that we have correctly understood that feedback is another prototype. It is typical for prototypes to go through several rounds of iterations in this fashion.
The key question to ask yourself after showing a version of a prototype a few times is, "Have I learned anything new?" If you are not learning anything new, then you may not have any need for further prototype iterations.
Summary
The seven principles of effective prototyping are signposts that can help you in every prototyping project (no matter the prototyping goal or variety of prototype you choose). In the next chapter, we'll take a look in depth at paper prototyping, and we'll create our first prototype!
Additional Resources
Pttrns.com is an excellent resource for patterns.
UI Patterns is another excellent resource for patterns.
Mobile Patterns is a set of mobile-only patterns.
