To best introduce you to the concept and practicality of how you can use prototypes at every stage and discipline of your project we’re going to take it in stages. I’ll start out with some core concepts to define prototypes and then I’m going reframe your thinking about when and why you should be using prototypes. After that I’ll get into some specific implementation considerations. And finally, I’ll sum it up with a couple of good tips for really making it happen.
But first I’d like to give a shout-out to Mariya Yao, Founder of Xanadu Mobile, who gave an excellent presentation titled Rapid Iteration on Mobile a few years back at SXSW 2015. Parts of this discussion are based on her talk, so be sure to look her up. The rest is based on Wikipedia, Google, and lots of experience with prototypes.
Why use a prototype?
Have you ever done a big maze? If you have then you’ll be familiar with the experience of getting pretty far into it, thinking your almost at the finish line, and hitting a dead-end. Right about then is when the realization hits you that you’re going to have to backtrack. This is where things get tricky, because there are lots of factors to backtracking.
First, and you probably didn’t expect this, I want to talk about Loss Aversion. In decision theory, loss aversion refers to people’s tendency to prefer to avoid a loss over acquiring an equivalent gain. For example, it’s better to not lose $5 than it is to find $5. Some studies even suggest that losses are twice as powerful, psychologically, as gains. As marketers we use loss aversion all the time in the form of 30 day trials and rebates.
The same is true for projects. Once you come up with a concept, write copy, design an interface, or build an application it’s really hard to let that work go. It’s yours, you made it, it’s special to you. So when we come to a dead-end on the project and the realization that we need to backtrack loss aversion tells us we may not make the right choice for the best outcome. Instead our brains work to avoid losing the work we’ve already done.
Next, you’ll have to understand what kind of a project you’re running. If you are running an agile project, good on you, things might not be so bad. If you’re a bit closer to a waterfall process, let’s hope you prototyped early on. The later you are in the stages of a project the more of an effect backtracking could have.
Lastly, I’d like to talk a bit about achieving your goals for the project. What are they, and how well are they defined? Have you tested your project against your goals? As I’ll discuss in a bit prototypes are about answering important questions. You are not always your audience and data doesn’t always tell a complete story. Prototypes get you out of your sample biased world and into the real world where you can test. Will people use your project in the way you intended? Or maybe a different way that’s better? Will they continue to use it? Will it change the behavior you are looking to change and have the impact you are looking to make?
Further down the line prototypes can help answer questions about process or production issues you may run into and material costs you’ll need to factor in to profitability models.
These are all important things that prototypes will help you overcome.
What is a prototype?
Wikipedia defines a prototype as an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from. A prototype is generally used to evaluate a new design to enhance precision by system analysts and users. Prototyping serves to provide specifications for a real, working system rather than a theoretical one.
When most people hear the word “prototype” they think of a thing resembling wireframes like something out of Axure RP. Or a limited functionality application that was hacked together quickly to represent the real thing without being the real thing. But that’s only part of it. There are lots of different kinds of prototypes, and they all answer different questions:
- A Proof-of-Principle Prototype serves to verify some key functional aspects of an intended design, but usually does not have all the functionality of the final product. This prototype serves to validate the idea. Will people use it? Will they continue to use it? And will it have the affect you want it to?
- A Paper Prototype is a printed or hand-drawn representation of the user interface of a product. Such prototypes are commonly used for early testing, and can be part of a walkthrough to confirm design decisions before costlier levels of effort are expended.
- A User Experience Prototype represents enough of the appearance and function of the product that it can be used for user research. This is a low-fidelity version of your work that can quickly be changed without much loss aversion.
- A Visual Prototype represents the size and appearance, but not the functionality, of and intended design. Apple manufactures many inexpensive versions of the iPhone out of plastics and cheaper materials. By having the right size and weight they can test to figure out which one will be the best for users.
- A Functional Prototype captures both function and appearance of the intended design, though it may be created with different techniques and even different scale from final design. I’ll cover a bit more on techniques to do this later.
- A Working Prototype represents all or nearly all of the functionality of the final product. If you are at this stage you’re right at the end of the project and probably have several of these out in the field for real world testing. For the purposes of this prototype conversation I’m not going to go deeper on working prototypes.
Resetting your prototype expectations
Okay, I’m about to blow your mind. Believe it or not prototypes can be used all over your project. And to convince you of this I’m going to introduce you to a new term: Functional Fixedness.
Functional fixedness is a cognitive bias that limits a person to using an object only in the way it is traditionally used. Karl Duncker, the psychologist who coined the term, defined functional fixedness as being a “mental block against using an object in a new way that is required to solve a problem.” This “block” limits the ability of an individual as they cannot move past the original purpose of those components. For example, if someone needs a paperweight, but they only have a hammer, they may not see how the hammer can be used as a paperweight. Functional fixedness is this inability to see a hammer’s use as anything other than for pounding nails; the person couldn’t think to use the hammer in a way other than in its conventional function.
When you read the previous list of the different types of prototypes you envisioned a webpage or a mobile application. That’s okay, you were supposed to. In fact, I set it up that way to make a point. The point is that we all have a preconception of how and when to use a prototype, and that preconception is wrong.
Prototypes can be used all over the place, not just in the software development lifecycle!
With that in mind, let’s take another review of that list of prototype types, but in a little more detail and with an open mind.
Deep diving on prototypes
Proof-of-Principle prototypes are quite literally meant to answer the question how do you know your idea is a good one? In apps this makes sense, but what about in writing? As digital health marketers our world is based in content, so how would prove out the principle content? Some authors like to start with an outline, which I’ll equate to a wireframe. Those are good, but let’s go back even further. Let’s start with post-its and whiteboards.
Post-its and whiteboards can help you accomplish a couple things. First, it keeps the work load low at the beginning while you’re structuring your document, understanding your flow, and documenting what assets and references you have and what you’ll need. Doing this will help you avoid putting time toward elements you may need to cut later. Don’t forget about loss aversion. Super-low-fidelity prototypes like post-its will help fight that off.
Paper Prototypes are defined as hand-drawn representations of the user interface. I understand that “user interface” will direct your mind to think about apps and websites, but again, I want to break that automatic assumption we all have. Understanding that user interfaces are typically digital, but for the sake of this I am going to redefine the term.
Interface is defined as the point where two systems, subjects, organizations, etc., meet and interact. So I’m going to redefine the user interface as an interface with the first of the two subjects given as your user or customer, and the second as your project… whatever it may be.
If you started out creating content with post-its, what would a paper prototype look like? Perhaps just bullets and layout? Those of you with a reporting background may be familiar with the concept of having inches to fill up, not words. That’s because newspapers a laid out. And if you think about it, it makes sense. You don’t get the Sunday paper one week and it’s 30 pages and the next week it’s 300. It’s consistent and you’ve come to expect it to be a certain size with a certain amount of content in specific sections.
Paper Prototypes can help you understand the flow of your project or content. I once worked on a project where we were generating informational leaflets for patients to take home with them. When it came time to flow in the copy we found that most of the topics were hitting 900 words (about 2 pages) or more. That’s a lot of copy for a leaflet.
As it turned out the copy team had data that said this was the kind of information that patients were looking for. At the same time the project team had data that suggested patients would prefer something smaller and less complicated. The snafu could have been avoided with a paper prototype that not only got the entire team together, but could be tested in the real world. In the end we had to ask the copywriter to pull his 900-word copy back to 150-200 words. Not only did he have to deal with loss aversion making it a difficult task to do, the project team had to absorb both the time it took to write the original copy and the time it took to fix it.
User Experience Prototype
Okay, so we’re now on the third prototype and we still haven’t written any copy. Crazy, isn’t it? As a reminder, User Experience Prototype represents enough of the appearance and function of the product that it can be used for user research. This is a low-fidelity version of your work that can quickly be changed without much loss aversion.
Though we’re still not at a draft, this is a good place to start pasting in groups of content. I specifically used that wording, “pasting” and “groups”, because I want to convey to you the importance of not turning the User Experience Prototype into a draft. A draft is defined as a preliminary version of a piece of writing. That’s not this.
There’s still too much work that goes into a draft to be comfortable cutting content if it doesn’t apply. At the same time, previous versions of your prototype do not have enough detail for someone unfamiliar with the project to make a real judgement on the final product. That’s where the user experience prototype comes in.
Put enough content, references, and topics in here that someone can get a good feel for what you’re going to cover. Once you do, you’ll find that some sections are too large and others too small. But you can deal with that. Perhaps you can abbreviate a section and reference an appendix. Maybe you’ll decide the content is too important and cut something else. Ultimately, this will give you a great feel for where you’re headed because it’s much more tangible than previous prototypes.
The rest of the prototype types
By now you should be getting some ideas about prototypes and how to use them outside of software development. There are still a few types of prototypes for me to cover, but I’ll leave that to you as an exercise in breaking your preconceptions about prototypes. Once you do, I’m sure you’ll be amazed about how much work and time they can save you while ultimately resulting in a better overall product.
A note on creativity in prototyping
Having worked on many projects with many prototypes, one of the major areas of pushback instituting prototypes where they were not previously used will have is on creativity. This may come as a shock, but the artists and writers are often not big fans of structure. But that’s okay, here’s how to position it so it makes a bit more sense.
First I want to talk about colonizing Mars. Without restriction, and without any rules or guidance, the most innovative thing we can do as an organization is to colonize another planet.
But how does that help your brand? The short answer is, it doesn’t. Ergo, we need some kind of guidance, goal, or KPI. That’s structure. And it’s no different than setting a goal for long form or short form content. From pre-setting style sheets, and content structure in a Proof-of-Principle or Paper prototype.
This is structure. Defining it can be a creative process, but once it’s defined you’ve got to use it if you want to be successful. That’s what a good prototype can do for you – give you feedback and direction. That’s where the creativity happens.
CCMS’s, intelligent content, and prototyping
Speaking of structured content, in previous articles I’ve discussed CCMS’s and structured content. After learning about prototypes we can see how important it is to really consider the structure of your content before and as you develop it. If you are setting up a CCMS you’ll need to make sure your components are structured to give you the output you need BEFORE you need it.
This goes for intelligent content, structured content, content reuse, personalized content, and much more. If you are going to develop content, you may be able to serve the project better by having a very good understanding of the final product before you start, work, hit a dead-end and have to go back.
Some tips on prototyping
The overall key to this success of prototyping is understanding what a prototype is and what it should do for you. This means you have to start by first asking the right question. Unfortunately, though, this doesn’t always happen. In fact, it rarely does.
A prototype should be architected to answer the following three questions. Will people use it? Will they come back to it? Will it have the behavior change affect you’re looking for?
These are experience questions, and the goal of the prototype is to cull down the experience to what called a core loop. Core loop is a term borrowed from game developers. At its simplest, a core loop is that main set of actions, typically three, that will make both you and your users successful.
Even for complex engagements the goal of experiential prototyping is to keep core loops simple. DropBox’s core loop would be get space, fill space, get more space. Amazon’s would be read reviews, buy products, leave reviews.
From here it is just a matter of evolving features that support the core loop. Drop box, for instance added automatic photo upload to their app — a convenient feature for users that still supports the business goals of DropBox. Amazon added features to make reviews easy and review ratings, not products, to help people quickly distill the value of the ratings themselves.
Core Loops are simple, but creating them can be very difficult. The trick is to get to the right core loop that people are willing to go through, and understand how often they are willing to go through it. This is your first proof-of-principle prototype.
Also, get creative. Creative prototyping comes into effect when the experience is rich or deep and hard to create quickly and cheaply. Elmo’s Monster Maker is a complex custom video app. To prototype a complex experience, the team had to get creative by cutting out a giant iPhone and filming a person standing behind the screen portion. With some large poster board, a few pens, and a camera they were able to test engagement and quickly refine the idea with a group of kids looking at a monitor and asking Elmo to do things.
Healthcare communications are a complex path of approvals and regulators. Each step is a gate that makes it hard to go backward so iteration can be difficult. But this also makes iteration more important. The earlier we can ask and answer the right questions, the better. Prototypes are key to doing this; culling down complex health experiences to simple ideas and building from there.
Rapid prototyping and iteration is not something we do often in healthcare. As an industry we can be perceived as slow and lumbering because of the complexity. But it doesn’t have to be this way. In fact, research and testing is at the core of what we do. Starting with the right questions, building prototypes that test those hypothesis, and iterating forward will not only help up produce better, more engaging products, but also drive more positive outcomes.
It’s okay if your prototype fails
It is important to realize that by their very definition, prototypes will represent some compromise from the final production design. Due to differences in materials, processes and design fidelity, it is possible that a prototype may fail to perform acceptably whereas the production design may have been sound.
Have you ever played the board game Clue? Clue is a murder mystery game where the object of the game is to determine who murdered the game’s victim, where the crime took place, and which weapon was used. Each player assumes the role of one of the six suspects, and attempts to deduce the correct answer by collecting clues about the circumstances of the murder from the other players. When a player is seeking more information, they can “suspect” or “suggest” who done it, where, and with what weapon in order to seek out more information. Once the player thinks they know the answer, they make a formal accusation.
Prototypes are a lot like Clue. As we go through a project we suspect a lot of things, but we rarely know for sure. Without a prototype a player would have to go right into an accusation, and the odds of getting it right are pretty low (324:1 to be exact). Prototypes are designed to fail, just like your suggestion in Clue. But in doing so they are also designed so that you learn something before you’re too far gone.
Rita McGrath is a professor at Columbia Business School. In a talk titled Use Failure to Grow Your Business, she talks about discovery driven growth. It’s minimizing risk and loss while maximizing education. As McGrath puts it, “plan to learn, not to plan to be right.” Here she defines “intelligent failures” as the opposite of loss aversion. Intelligent failures are, “carefully planned, contain the downside, and learn a lot from the expenditures … managing the cost of failure, not the rate of failure.”
Okay, so that’s prototypes in a nutshell. They’re actually pretty cool, and now you know they’re for everybody, not just software developers and UX professionals. Prototypes can save you time, which is the same as Monday, and give you a better product. So the next time someone tells you that you can have it done right, done fast, or done cheap but you have to pick two let them know prototypes can get you all three.