The Purpose-driven Prototype
Good prototypes have a clear reason for existing and should be designed specifically to address this reason. Too often, prototypes are conceived only as early representations of the imagined product. Instead, an effective prototype should be created to explore and test specific questions or guesses about the product’s imagined user, their needs, or the perceived solution approach. Following this logic, the prototype design should be determined only after identifying what critical questions need to be addressed. The prototype should then subsequently be crafted to best reveal answers and insights around what you care most about learning. In some cases, what results from this approach is a prototype that is not at all representative of the actual perceived product (commence debate around whether this is still called a prototype).
For example, our product discovery team designed a prototype that consisted of two carefully written one-page printed descriptions of three health care plans. Our test was to ask several subjects to simply select the plan that was most suited to their family’s needs and do that once for each printed page. We designed the prototype to test a key hypothesis around a new health care benefits enrollment portal we were hoping to build: if we significantly reduced the jargon associated with benefits plans today (e.g. out of pocket maximums, premiums, HSA accounts, etc.), then users would have less frustration and spend less time selecting a plan. We had learned during user research that people got stuck when they hit terms they didn’t understand and would pause the enrollment process to google a term or call a trusted authority for help. One of our printouts was the typical jargon-filled page. The other was rewritten to be completely jargon-free. Three noteworthy elements of this test:
- We created a head-to-head comparison. It’s difficult to see how well a solution is performing in a vacuum (3 users liked the solution, 2 were ambivalent and 1 hated it — has this validated our hypothesis or not?), but it’s easy to see how well a solution works compared to an alternative (6 out of 7 preferred approach #1).
- We knew the insurance carriers would not allow us to remove all of the jargon from the enrollment process (at least not at first), so the traditional prototype approach would have been to design a prototype that removed jargon only where we thought the carriers would let us. However, if we went over the top and removed all jargon in our prototype, we would more definitively learn whether this approach was a good idea, regardless of what the ultimate product really looked like (interestingly, this would also test how difficult it was for us to replace all the jargon). In other words, testing a truly representative prototype wouldn’t help us learn nearly as much about the issue we cared about than one specially designed for our purpose.
- We built nothing into the test around screens, flows, buttons, links, labels, fields, menus, platforms, etc. This saved us a ton of time. We knew usability would likely be important down the road, but we were in a place where there were much more important hypotheses to test around fundamental value to the user. Having said that, there are often cases where building a prototype that represents a software interface can be valuable for reasons beyond usability; for example, helping the user understand that the solution we’re testing is an app on their phone and getting their reaction to this.
Following this logic, prototypes can (and likely should) take a wide variety of forms and often represent some sort of low/no-tech test that explores if/where customers see value in a solution and evaluate their willingness to ‘hire’ the solution into their lives. In some cases, a core hypothesis to test is whether or not an envisioned solution is usable, in which case a usability test of a functional prototype is totally appropriate. Unfortunately, because usability tests are a preferred tool of the UX professional and often (always?) reveal that product designs are far less usable than we thought, they have become the de facto approach, even when product usability is not the core hypothesis to be tested. Unless you’re introducing a competitive product into a well defined solution space and all you need to differentiate around is usability (e.g. basic email marketing tool, online shopping cart, etc.), then traditional usability testing is almost never what you should be doing first.
This requires product creators to get much more crisp around understanding and prioritizing important uncertainties, assumptions, risks and hypotheses associated with their product visions. This can be very difficult for the wide-eyed entrepreneur to do because it requires getting skeptical about ones’ own ideas. Cue cognitive dissonance.
The creator must also be aggressive in imagining and resourceful in determining how they might go about testing an idea as quickly as possible and not simply default to mocking up a bunch of screens and asking users if they like or can use the representative product. In other words, it takes real effort and brainpower to just not do the obvious and fun thing of mocking up what this thing could look like. This is doubly difficult because in the case of digital products, it is often easy and quite helpful to mock-up screens — mockups help develop understanding with ourselves and others what we’re imagining and it seems a logical step to spec out a solution before asking developers to build it.
The failure pattern here is that mocking up your imagined product is often done without first trying to determine what the purpose of a prototype should be and then designing the prototype to address that purpose. Designing purpose-driven prototypes is harder and less intuitive but much more efficient, effective and ultimately valuable.