Taking the “You” Out of User: My Experience Using Personas

by:   |  Posted on

The best laid plans…
In 1999, I co-founded a small San Francisco-based start-up called Pyra. Our plan was to build a web-based project management tool and we chose to focus initially on web development teams for our target audience since, as web developers ourselves, we had intimate knowledge of the user group. At the time the team consisted of three people: my co-founder, our lone employee and myself. We considered ourselves to be good all-around developers: competent in both interface and back-end development. We also assumed we were developing our product (called “Pyra” for lack of a better name at the time) for people just like us, so we could make assumptions based on our wants and extrapolate those desires for all users.

At this time, Microsoft had just released Internet Explorer 5 (IE 5) for Windows and we were anxious to use its improved standards support and DHTML in our application to make the interface as whizbang as possible. By limiting our audience to IE 5, we decided we would be able to deliver the most robust application, one that was sure to impress potential users and customers. Later, we told ourselves, we’d go back and build out versions with support for Netscape and Macintosh. So we set to work building the coolest web application we could, taking full advantage of the latest wizardry in IE 5 for Windows. Development was chugging along when Alan Cooper’s “The Inmates Are Running the Asylum” was released and I picked it up. When I got to the chapter discussing the use of personas, I was intrigued. Though I was confident in our approach, creating personas sounded like a useful exercise and a way to confirm we were on track.

Discovering Personas

“Not only were the personas not all like us—our personas wouldn’t even be able to use the system we were building for them!”

Cooper’s personas are simply pretend users of the system you’re building. You describe them, in a surprising amount of detail, and then design your system for them. Each cast of personas has at least one primary persona, the person who must be satisfied with the system you deliver. Since you can’t build everything for every persona (and you wouldn’t want to), the establishment of the primary persona is critical in focusing the team’s efforts effectively. Through the use of personas, the design process moves away from discussions that are often personal in nature (“I’d want it to work this way.”) or vague (“The users like to see all the options on the home page.”) . It becomes a series of questions and answers based on a concrete example from which the team works (“Mary, the primary persona, works from home via dialup four days a week, therefore downloading an Access database isn’t an option.”). In our case, the development of personas helped us recognize that the target audience we’d chosen, web development teams, wasn’t as homogenous as we first assumed. Not everyone who’s involved in web development is gaga for DHTML or CSS—some people on the team might not even know what those acronyms stand for, a simple fact we’d failed to consider up until this point.

Our team stopped working to discuss personas and Cooper’s approach and we agreed it sounded important enough to devote some time to it. As we sketched out our various personas (a project manager for a large company whose corporate standard was Netscape 3, a web designer who worked on a Mac, an independent consultant who worked from home), it became apparent we had made some bad assumptions. Not only were the personas not all like us—our personas wouldn’t even be able to use the system we were building for them! We’d been so blinded by our own self-interest we failed to realize we were building a useless team product. Sure, it would have been great as an example of what we hoped to build, impressive to any engineer or web developer, but a manager might not be able to access it. We were cutting ourselves off from the people who would most likely make the decision to use the tool—and no project team would signup for Pyra because an entire project team couldn’t use it.

We were a month away from releasing the beta version of Pyra at this point, but we knew what needed to happen. We had to go back and redo our application to work for Netscape and IE, for Windows and Macintosh, and in doing so, we needed to reevaluate our tool using our personas (specifically our primary persona) rather than ourselves or the mythical “user” to guide our decisions. So that’s what we did, pulling out all our beloved DHTML and remote scripting so our 37-year-old project manager persona could access the application from her home office in Seattle on a Saturday afternoon. Though the rework delayed our beta release by two months, it resulted in a tool our potential customers could use immediately.

Learning hard lessons
Through the process of developing personas, the mistakes we’d made became clear to us:

Mistake #1: We chose flashy technology over accessibility.
We allowed the geeky part of our personalities, with its lust for the newest and greatest ways of doing things, to overwhelm the decision-making process. Though there was a sense at the beginning that we needed to support other platforms, we let our desire to use the newest “toys” change the priority of doing so. This is a common mistake programmers and engineers make but one which can be avoided through the use of personas. Interestingly, when we redid Pyra based on our personas’ needs, we didn’t lose any of the previous functionality. We only changed how it was done, e.g., reverting to less elegant page reloads rather than DHTML client-side changes. The previous version had only been impressive to fellow geeks like ourselves, but we hadn’t realized that. More importantly, the essential quality of the tool was never lost, but by redoing it, it become available to many more people.

Mistake #2: We assumed users would be more impressed by a robust interface they couldn’t use than by a less elegant application that they could use.
Again, our technical hubris blinded us into thinking that potential customers would be impressed by how we built our functionality, not by what the underlying features were. We let our wants come between our product and our users.

Mistake #3: We thought we were the primary persona.
While we shared common goals with our some of our personas, and though one of the personas we developed was very similar to the members of our team, none of us were the primary persona. This crucial distinction between primary personas and secondary personas forced us to realize the interface we designed shouldn’t be driven by our wants or needs, even as members of a web development team. Defining a primary persona prevented us from releasing our original tool with its accessibility failures.

Less than a month after the beta release of Pyra, we released a second tool, Blogger. Though we didn’t create formal personas for Blogger users, the experience we gained by using personas infused our company’s approach to building web applications. Any time the word “user” was mentioned, questions flew: “What user? Who is she and what’s she trying to do?” Our work with personas increased our awareness of our audience and their varying skill levels and goals when using the application. The use of personas helped move all our discussions about the application, not only those related to the interface, away from the realm of vagaries and into tangible, actionable items. (“It should be easy to create a new blog.” “Easy? Easy for whom?” “It should take less than a minute to get started.” “It should take less than a minute for my grandmother to get started,” etc.) We developed a system of familiar, conversational personas on the fly, focusing on the primary persona without going through the formal process.

In retrospect, some of this sounds like common sense, and yet time and time again I find myself looking at an interface and making assumptions based on how I’d like it to work. Like a recovering substance abuser, it’s a constant challenge for me to refrain—I can always imagine that I’m the user. Even if your budget or timeline doesn’t allow for the development of formal personas, you can still benefit through the use of informal “conversational” personas, like we did while building Blogger. It takes discipline to break the old assumption habit but the more I use personas, the easier it becomes. I’ve carried the lessons I’ve learned through their development with me for the past three years to other projects and engagements; the use of personas resulted in a fundamental shift in the way I approach not only interface design but application architecture as a whole.

For more information:
Alan Cooper, The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. SAMS, 1999.

Bringing Your Personas to Life in Real Life

by:   |  Posted on

You read about personas in “The Inmates are Running the Asylum.” You know that using them improves your interactive designs and helps get your coworkers on the same boat. You did your ethnographic research, created a useful persona set and are ready to start designing for the needs of your personas. But first you have to document and share your personas with your colleagues.

When presenting, talking about your personas, or referring to them in writing, communicate as though they are real people, people that you know. Express it like you are talking about a friend.

The way you communicate the personas and present your deliverables is key to ensuring consistency of vision. Without that consistency, you’ll spend far too much time arguing with your colleagues about who your users are rather than how to meet their needs. Let’s start with a review of what we know about personas, and why they are useful.

Personas are user archetypes created primarily to be design targets
Personas are almost always based on patterns and findings you gather during interviewing. You use them to prevent problems such as the “elastic user”—the user that morphs from grandmother, to John Doe, to your CEO, depending on the day. Having a stationary target in a non-stationary world is a first step to creating a holistic, useful and usable product.

As a first step to documenting your personas, make sure you’ve done the preliminary work. You created multiple personas, fleshed out to the same level of detail. For most projects, each persona has at least a first and last name, age, goals, background story, a telling quote, email address, job title and a photograph. Some projects may require more characteristics to highlight specific areas of importance

Depending on the project, you identify various persona characteristics or facets relevant to the design (more on this later). Finally, give each persona a designated status: primary, secondary, supplemental, negative, etc.

These designations help prioritize your design efforts. In later design stages, you will create scenarios for a design that satisfies mainly the needs of your primary. Status designation also helps to minimize feature creep; requests are easier to reject or incorporate when you’ve already decided who the product is and isn’t for (e.g., it shouldn’t be added if it is for your negative persona, if it is only for your secondary it can be hidden away from the primary areas).

Marlena, an interaction designer using personas
As an example, let’s watch Marlena go through the process of preparing and documenting personas at her company. Marlena is an interaction designer at DigitalMail, a provider of HTML email marketing software for managing customer relationships. Adam, also an interaction designer, is working closely with Marlena on designing the next version of DigitalMail’s flagship product, DigitalMail Reach.

Marlena and Adam have conducted interviews with marketing managers and assistants, webmasters, graphic designers, and sales professionals at companies that have already used or are likely to use Reach. After their research and a few intense whiteboard sessions, they identify patterns that help them flesh out their personas. Now Marlena and Adam have to check in with the heads of product management and engineering and with the CEO of DigitalMail before they can start designing for their personas.

Use structure to help others reach your conclusions
In order to get her co-workers on board, Marlena knows she needs to carefully manage their first impressions. Having had some experience sharing personas before, she knows she has to provide detailed written documentation for those who don’t attend the meeting and for later reference. All the design documents she will produce from this point forward will incorporate the personas to help focus the design

Audiences do not generally understand persona designations until the entire persona set is explained. Seeing them all on one page to compare goals and summary information is key, so the audience can be confident that all bases are covered.

Marlena starts by documenting their research. She then creates about a page for each persona, including all the information mentioned above (name, goals, age, background story, etc.) except the persona’s designation. Instead, she uses the designation to order the persona pages with the primary being appearing on the first page of personas section.

After her personas section, she adds the persona designations and the reasoning behind the status designations. Marlena also adds a section with summary information (picture, goals, name) about each persona, so readers can compare and contrast the personas. Finally, she adds a page containing a diagram that shows how each persona is involved in using the product.

Depending on your project and research, you’ll uncover characteristics of your personas that are relevant to the design of the product. Each persona may have a different information—sharing need or a particular role in relation to the product (e.g. consumer, creator or approver of content).

Marlena and Adam discover a common process among their interviewees—marketing usually initiates the email campaign; the graphic designer creates the design and integrates the marketing copy; and the webmaster checks the HTML. At various points in the process, multiple people will use Reach for particular tasks. This is central to the design, therefore, Marlena creates a diagram that communicates this key distinction. She also mentions it in the narrative about each persona.

Marlena then creates her PowerPoint by simply summarizing her document. She structures the information in her presentation in the same order as her documentation, so her audience can follow the same process she followed and reach the same conclusions.

She’s found that audiences do not generally understand persona designations until she explains the entire persona set. Seeing them all on one page to compare goals and summary information is key, so the audience can be confident that all bases are covered. Marlena wants her personas to be representative of the actual patterns in her user population, and conveyed succinctly so they are useful.

Thanks to Marlena’s meticulous work habits and Adam’s presentation skills, the meeting with their executives goes well. With minor adjustments, management agreed that they should design for the primary persona while keeping in mind the needs of the secondaries. Everyone who is working on the next version of Reach will read the deliverables, and Marlena and Adam will give another presentation to a wider audience of team members. They also suggested to the executives that they start using the names of the personas instead of the word “user” to avoid miscommunications.

Marlena and Adam are satisfied, but they know there will be more challenges to understanding the personas as they begin to do more detailed work with coworkers, so they do some more documentation work.

Know, sell, use and help others use your personas
Four weeks later, after Marlena and Adam have reached some high-level conclusions about how the product will function, they schedule a meeting with key engineers to verify the feasibility of their design. They want engineering to know the skill sets needed to implement the design so that they can plan for additional hiring, skills development and resource allocation.

To provide quick reminders to colleagues who aren’t so versed in the personas, Marlena created a persona “placemat”—a laminated sheet that contains the same summary information and diagram found in the last two pages of her persona deliverable: the goals, names, and pictures. She easily created the placemat by tweaking what she already had in the persona document.

They start the meeting by reiterating the primary persona (Kathy, the marketing manager) as well as the secondaries (Charles, the graphic designer, and Patrick, the webmaster). Tom, an interface engineer, shows up 10 minutes late, just as Marlena is discussing the preview functionality she foresees needing.

Marlena: Kathy wants to preview the message in Outlook. If there are any potential compatibility problems she wants to know, but she really doesn’t care what they are. Patrick will want to do the same with Outlook and all the other major mail clients. He will also want to know specifically what the compatibility problems are and even tips on how to fix them if the product can’t just do it automatically.
Tom: Wait. Which one is Patrick again? And why won’t Kathy want to see what exactly is wrong and how to fix it?

Marlena knows she has about 15 seconds to explain who Patrick is and maybe 45 more seconds to explain why Kathy doesn’t want all that functionality before Tom and the other engineers get impatient. Marlena takes out a laminated persona placemat and hands one to Tom, then hands other copies to the rest of the attendees.

Marlena: Patrick is the 26-year old webmaster. He’s responsible for making sure the emails reach and are readable by all the recipients. On the placemat you’ll see two of his goals are “Be knowledgeable” and “Make sure code doesn’t break.”
Tom: (looking back and forth between the placemat and Marlena) Oh… right and why doesn’t Kathy care?
Marlena: Well, Kathy, our primary persona, is the marketing manager and she mainly cares about the message contents and design. She just wants to insure her marketing messages are conveyed. She is busy and depends on Patrick for technical concerns. If you turn over the placemat, you’ll see a process diagram showing that she barely previews. Patrick is mainly involved in the tail end of the process.
Tom: Oh, okay. Uhm, sorry for interrupting. Go on.

Marlena knew from experience that even though people may read (or skim) the documentation, they need quick reminders of the personas and the relevancy of their stories. After all, she and Adam spend their entire days thinking about what Kathy, Charles and Patrick want and how to give it to them. (In fact, Marlena hasn’t yet shared with Adam that she had a dream about Patrick the night before.)

Even though the placemats provide a good reminder, after this meeting, she and Adam realize they need to do more. They are going to create posters with pictures and summary information of the primary and secondaries and they will be hung around the office.

Marlena offered these other tips for documenting and sharing your personas:

  • Tie your personas to your research, showing your audience that you’ve personified the patterns you’ve found because that makes sense for design.
  • Less is more. Get to the heart of the persona.
  • When presenting, talking about your personas, or referring to them in writing, communicate as though they are real people, people that you know. Express it like you are talking about a friend. Remember, you want your audience to like (though not necessarily agree with) the personas. There is little motivation to try to understand or design for people you hate.
  • Reuse persona pictures often—people feel connected to them and remember faces easily.
  • In your persona description, focus on their regular daily activities.
  • Be creative in the ways you communicate them and use multiple methods—posters, t-shirts and sock puppets have been known to work—but don’t get too cute.
  • Use good communication guidelines, for example make the primary persona picture largest.

Documenting personas keeps your design on track
Now that you have a better idea of how to document your personas, remember that documentation isn’t the point of your work. It is simply an important step on the way to designing and building better products. Also, what is described above is a cookie-cutter approach towards documenting your personas. Each project will have different documentation requirements to make different points, but the underlying principles stay the same. As a designer, it is up to you to determine how much persona detail is sufficient and how to set up the personas and their presentation so that you pre-empt confusion and questions. You also need to provide a quick way to familiarize newcomers to the persona set, and find ways for your colleagues and clients to keep focused on the personas throughout the project.

For More Information:

The ideas above were impressed upon Elan when he used to work for Cooper Interaction Design. These days he consults independently (though with other former Cooperistas) for companies that don’t have the liberty to screw up their products. When he’s not designing, he can be found playing volleyball, improvising or improvising as a volleyball (you try that sometime)….