Making effective use of personas in design

 I've created and worked with a number of different personas during my time in the Visual Studio User Experience team at Microsoft. I've learned a lot about how to use them effectively, and, contrary to what others have recently written about the use of personas, I believe they are still indispensable in product design, when used effectively.

Before I get on to how to use personas effectively, let me describe why I think they are indispensable.

A persona is a character in a story. The story involves the character using a product in a particular context, to achieve some goal. A believable and well designed persona is like a well developed character in a novel. They have beliefs, motivations, work styles and characteristics that explain their behaviour in a specific scenario. Given a scenario, the behaviour of a well developed character in that scenario can be explained by describing the way that their motivations, traits and workstyles influence the choice of actions that the character takes. 

As designers, we are writing a story in which our personas are the main protagonists, a story which does not yet exist. We want the outcome of the story to be one in which the protagonist has a great experience achieving some goal or task. We have the power to shape the story through the design choices we make. Our intent is to maximise the potential for the protagonist to be successful and for the experience to be a great one. The way we achieve that is to imagine the different situations that our protagonist finds themselves in, in which they grapple with whatever we have designed in pursuit of their goal. We use our understanding of their motivations, desires etc to determine how they behave in those situations, using whatever we have designed for them.

It's this ability to place the persona in a scenario that had never before been imagined and determine how that persona will likely behave that makes them indispensable. But wait a minute, isn't that what usability studies are for? And those don't require use of your own imagination - they involve real people. Why can't we just ask a real person instead of a substitute for a real person? Well, as UX Myth #21 points out, what people say they will do isn't always what they really will do. You can't rely on being able to ask someone how they will behave in an imaginary situation. They have to be placed in that situation to really see how they will behave.

The crucial point is that we're doing this very early in the design process, before anything has been built. So we can't run a usability study since we don't have a prototype, storyboard or mockup, let alone a working product to study. It's the part of the design process in which we are figuring out what we should be doing.

Think about that moment just before you put pen to paper when sketching a design. How do you know what to sketch? If you rely on your customers telling you what to build, you run the risk of building something they don't really want. A well designed persona informs design, helping you determine what you should be designing, as opposed to how to design it.

A great example of this is one of the personas I worked on with the VS Test team a few years ago. We developed a persona named Ellen, the vigilant tester, to better understand the workstyles and motivations of testers. As David describes, the persona helped us understand that we needed to design a completely new product for manual testers.

It's very unlikely that we could have run a usability study or a focus group for example, to reach the same conclusion so confidently. We needed a rich and deep understanding of what makes testers tick to be able to determine what we needed to design. The persona represented that rich and deep understanding. It allowed us to imagine how testers would react if we gave them a product that was radically different to Visual Studio.

Of course, we needed to fully understand that persona, embrace it and know how to place that persona in a particular context and accurately determine how the persona behaves. This is critical to being able to use personas effectively. It's not enough just to know the persona's name. You have to know them and understand them so well that you could place yourselves in their shoes and behave as if you were them.

Now, how do we use personas effectively?

It really comes down to how well the persona is described and understood. The focus of the description should be on the motivations, traits, workstyles and characteristics of the persona. Not on things such as how many pets the persona has and what their favourite colour is. I've seen some persona descriptions that contain too much trivia. They don't present convincing characters at all and simply can't be used to imagine how that person will behave in a specific scenario. For example, Josh Ledgard presents a caricature of one of the developer personas:

Meet Mort. He’s 50 years old and he is a rocket scientist. He’s been married twice with 4 children. One of the things he does as part of his job is develop applications that connect to embedded devices used to test missile guidance system. He doesn’t have the time to learn the ins and outs of programming languages so he relies heavily on visual tools and code completion services in the editor to help him write.

Such descriptions are easy to write since they are pretty much void of meaningful content. Getting to the point where you can create a rich and meaningful description of a persona isn't easy. It needs a lot of work, observing people and learning about their needs, desires, motivations. As we've discussed before, it's not that easy just to talk to people to learn these things. You need to observe them in the types of scenarios you are designing for.

In the case of the Ellen persona I mentioned before, we spent a lot of time observing testers doing their jobs. We noted all the things they did, when they did them, the way they did them. We used those observations to describe their motivations. For example, it was clear to us from our observations that testers absolutely thrive on finding bugs, not on running test cases. If they don't find any bugs they feel like they aren't doing their job properly. They know bugs exist, the motivation is to find them. They are driven this way since their ultimate goal is to ship a product that delivers a flawless experience to it's end users.

Nobody ever said to us that they enjoy the thrill of chasing down bugs in a product. But you could see from the way that they behaved that this was the case. From other observations we built up a profile of the persona consisting of the motivations, traits, workstyles and characteristics of the testers we had observed.

Having created the description, we soaked it all in. We played thought experiments - 'How would Ellen react to...?' in order to determine if we really understood the persona. We looked for other sources of data that confirmed or refuted the claims we had made in the persona and adjusted the descriptions accordingly. We presented the persona to multiple groups throughout the Developer Division. The more we presented the persona, the better we understood it since people at every presentation brought up new questions about the persona. We created posters, a web page and other presentation materials to communicate the persona. Any time we interacted with a customer we would reflect afterwards on the things that they had done and the things that they had said that were typical of Ellen. We pointed these out to other team members and built up a repertoire of stories to tell that described particular aspects of Ellen. Any time somebody made what we believed to be an incorrect assumption about Ellen or about the design, we would step up and debate the assumption with them. As a result, either the description of Ellen was enriched with some additional insight or the person we debated with ended up with a richer understanding of the persona. In short, once the persona was created, that was only the beginning. We continued to develop the persona and the way that we described and presented the persona.

Such descriptions on their own though aren't sufficient for making good design decisions. You need something that will help you drive the design in the right direction. The next step is to take these motivations and create a set of design principles (Sam Moreau has a great PDC presentation on how design principles shaped the design of Windows 7: https://channel9.msdn.com/pdc2008/PC22/).

The design principles shape the direction of the design. They help you determine what you need to design and if what you are designing is the right thing to design.

One of the principles that came out of the tester persona was to optimise the design for finding bugs. Experiences, features and designs that resulted in the maximum amount of time being spent finding bugs would likely make testers happy since we knew this would resonate with their underlying motivations. This, and other design principles were used constantly throughout the lifecycle of the product to determine what we should be designing and building.

Neither the personas or design principles told us that we needed to design a page based UI containing various activity centres for the different tasks that the tester finds themselves doing. The decision to create these specific designs though was driven by the principle of maximising Ellen's time on fixing bugs. Each time we made a decision we would always ask ourselves if it felt like the right thing to do for Ellen.

Of course, as design progresses you'll use other techniques to iterate over your design and get it right. You'll follow the appropriate design guidelines to make sure that whatever you are designing, you design it right. You'll run usability studies to get more detailed answers to specific design questions you have, once you have a design direction. You'll use beta releases to get feedback from a large portion of your customers etc. Personas are but one of the many tools you use in a development project.

But even though you may use other tools and techniques as you progress through the project lifecycle, the persona should be influencing everything you do in some way throughout the project. The persona is the thing that helps everyone on the team empathise with their customer and is what drives change. By embracing and understanding the persona, you are driven to make things better for that persona.

To summarize:

• Personas are indispensable during design because we can't rely on being able to ask people what they would do in a particular scenario.
• Great personas are personas that describe workstyles, characteristics, traits and desires. Bad personas are personas that focus on trivia such as favourite colour.
• Use personas to provoke design discussions, not as a checklist of features to create.
• Create design principles from the description of the persona and use these to drive the design.