Bringing Your Personas to Life in Real Life

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)….

Posted in Deliverables, Deliverables and Documentation, Special topic: Personas, Usercentric | 5 Comments »

5 Comments

  • Elan

    March 17, 2002 at 10:44 am

    I want to add one more resource to the article. Elaine Brechin at Cooper Interaction Design wrote an article explaining the differences between market segments and Personas. Understanding the difference has proved useful when sharing Personas with marketing or product development, as they tend to be more familiar with making product definition decisions using quantitative research.

    If anyone has any other comments, questions or clarifications regarding the original article, I’m here to answer them.

  • Jess

    March 23, 2002 at 2:28 pm

    and here’s the URL for Elaine’s article in the Cooper Newsletter

    http://www.cooper.com/newsletters/2002_02/reconciling_market_segments_and_personas.htm

  • christina

    March 25, 2002 at 6:07 pm

    I like that you used personas to explain persons (so meta!)a

    You mention placemats; but I know there are other ways of keepign personas forefront. At Hot we had a big poster of our personas we carried into meetings, and at CIQ I’ve put photos of personas on the deliverables, to provide context for the design decisions.. and i remember you mentioning something about sock puppets….

    What I’d also like to ask is have you every gotten pushback on personas: you know, those aren’t real users. blah blah blah…

  • Dell

    March 25, 2002 at 8:22 pm

    In a Web site design meeting just last week, I found myself wishing I had made the time to develop detailed personas during a “religious discussion” which ate up the better part of an hour. Reading these articles makes me think the effort will be worth it, rather than having to endure more circular debate (with marketing types and others) about ‘the users goals’. You give great practical advice here on how to make personas work for the whole team, which is the real challenge. I think I can give it a good shot now.

    I have two questions for anyone who wants to answer: If your marketing dept. has already developed personas actually used in print materials (e.g., Mrs. Smith just luvs our product and here’s why she bought it), do you recommend bringing the same personas to life for user centered (Web) design purposes, or starting over with new personas, so as not to confuse the two? I’m torn.

    Secondly, how often do you “update” personas, for example, when a new product is developed or a new customer comes along with a different type of user base, such as an older population? Is it ok to constantly update or change your personas or should they be relatively permanent?

  • Beau

    November 17, 2002 at 11:42 pm

    Dell – I’d say if the Marketing dept (or whoever) already had personas developed, I would use them. By doing that, you will increase the buy-in for that department, because they created the original, and you have just defined a few extra features/characteristics of that persona (i.e. web-related information). You will also have a familiarity to work from, so that people will know who you are talking about.

    You will probably find that you will still need to “introduce them to someone new”, but I would think using what’s there is a great start.

Sorry, comments are closed.