Show, don’t tell: How to make better products by prototyping early and prototyping often

Until recently, most information systems were conveyed through printed means; be it books, manuals, newspapers, posters, signage or a myriad of other standards of visual communication. User input into these systems was quite minimal; outside of flipping through pages or following specific pathfinding directions. A designer’s job was to succeed in communicating the information and tone of the content in a pleasing and clear way. The audience’s role was simply to observe.

With the advent of digital products, there was a fundamental paradigm shift in the relationship between people and their information systems. Now that the canvas and content could shift, collapse, and expand in response to user inputs, the role of the user changed from an observer of the system to a fundamental orchestrator of it. This is a pivotal thing to keep in mind when creating an interactive system: a product team not only has to consider how the content of their product is represented, but also how users navigate through and interact with the different aspects.

For a few years, people were walking around in the dark, trying to shine some light on how to best create interactive products. With revelations like the advent of the GUI and the desktop metaphor, to the transition from skeuomorphism to flat design, to the adoption of the user centered design and agile methodologies, product teams around the world are getting better and better at tackling the nebulous task of creating an interactive experience. However, one truth has survived through hundreds of years of industrial design to remain a pivotal part digital production cycle: if you want to create a product, you first have to build a prototype.

Why does prototyping matter?

Since we are building complex systems, it is important that we try to get out of the mentality of designing for screens, and into designing systems. It is imperative that the user understands the purpose of the entire experience that you are crafting, and the different ways to navigate and manipulate content within it. Users do not see interactive products as separate viewports that are joined by links; they live in a reality where the entire product is a system that will allow them to reach a certain goal. The single best way we can convey that to them and test our assumptions of how the product interacts is to build a prototype of it. This has been a paradigm of User Experience design and the Agile methodology for some time; if you can quickly get a prototype of your idea spun up and into the hands of users, then you can test whether your assumptions about the needs of the user and product holds true. While prototyping is intrinsically important for testing with users and validating your design team’s decisions, it tends to only be considered at the point where consensus on a feature or design decision needs to be reached. However, if you are not using prototypes to analyze your product at every stage, you are doing your product a disservice.

What can your prototype do for you?

Prototypes do not need to be limited to testing, and they do not need to be crafted only for users. In fact, they can be embedded into the process from start to finish. There are three different kinds of prototypes that should be used in a development cycle, and each of them brings their own benefit.

Build to Think

When an idea is first propagating, it can be hard to get everyone in your internal team on the same page. People have a number of different ideas for how a product should look or work, and sometimes team members who may think they are in agreement actually have very different ideas. Something as simple as taking 15 minutes to divide into teams and create a few paper prototypes allows you to get multiple ideas out quickly. Doing so takes your concepts off a static whiteboard and forces you to focus on your product being interactive from the start. For this prototype, the lower fidelity, the better. It is all about getting the ideas out (think paper, markers, and post-it notes).

Build to Learn

As we make our way through a product delivery cycle, it becomes common to get stuck in flatland; creating static compositions of our ideal UI that can be used as a deliverable for each required screen. While this helps to quickly get consensus on content hierarchy and visual executions, it is equally important to get consensus on the interaction design and information architecture; a thing that siloed screens make it hard to simulate. That is why it is important to take the extra step to mocking up a prototype, not just in the hi-fi state, but at every level of fidelity as you iterate on your product. Whether with your internal team, client or project stakeholders, being able to sit down with a test case of your product and walk through your previously established user scenarios gives better insight into the way that the final product will actually work. This can reveal a number of problems with the larger picture of a system, such as poor navigation structure or redundant content, and helps to get you away from focusing on deliverables and towards focusing on experiences.

Build to Test

Throughout the years, many products have been thought up, brainstormed, sketched out, designed, developed, marketed and evangelized before the stakeholders find out that they invested all that capital in a bad idea. Now, many companies are adopting methods of validating their ideas early on by bringing users into the delivery cycle. Prototypes are a pivotal component of this step, as it allows you to get a strong feedback on where you are going off the rails. Are you making sure that your clicks are meaningful to the user’s goal? Do any of your pages suffer from high cognitive load? These are a few of many powerful insights you can get from testing a prototype with your users early on. For this kind of prototype, you will want high enough fidelity for the user to be able to navigate the product and make their own inferences without your guidance, allowing you to simulate the reality in which you are not there to hand hold the user through your designs.

Build Products. Dynamically.

You may notice that these three methods of prototyping are not mutually exclusive. In fact, they tend to be quite complementary. Rather than simply limiting prototyping to a step in the process, making it an integral part of each step of the process helps to make sure that your product is ironclad and well vetted by the time it reaches developer hands.

Thanks to Catalyz and the Seattle Innovation and Design Thinking Meetup for helping to bring together a number of these thoughts. In my next article, I will talk a bit about the different audiences that can get great benefit from a well developed prototype.