Personas | Design 4

One of the most important things you can do to help make your site more usable is to get to know your users. This can be done in various ways. Conducting usability tests (gorilla or more in-depth tests), soliciting user feedback, interviewing and surveying are all good ways of doing this, and there are many more. Once you get started, you will have a pretty good basis of information on your users to help you design and advocate for them.

You can further increase the usefulness of this information, as well as add to it, by creating personas for your users.

A persona is a user profile that you can use to help make design decisions, as well as use to aid you in other ways. These profiles are created from your knowledge of your users, usually knowledge gained from user testing and research. Think of it as having a “ virtual” user to bounce ideas off and help you keep the goals of the user in mind on a day-to-day basis. They are another powerful and valuable tool you can add to your toolbox.

What I’ll do here is show you a quick and easy method to help you create your personas, as well as the basics of how they can be used. This is by no means going to be the only way this can be done, nor is it the only way personas can be used. There is much more to the world of personas than I’ll be discussing here.

The more you put into your personas (and any other usability strategy) the more you’ll get out of them – I just hope to get you started. To that end I’ll give you some links to resources that will explain in much more detail how you can use, create and learn from personas when we’re done.

Start with Research.

The first and most important thing you’ll need to do is gather information about your users. Depending on your resources and budget this can be done in various ways and to varying levels of detail. Let’s concentrate on a few simple ways that will specifically help you create personas.

One of the best ways you can get good information for your personas is by interviewing your users one on one. If you are planning on doing some usability testing, add ten minutes or so to users’ sessions and have someone sit down and ask them some questions. If you can’t get in direct contact with them, provide an survey (by email for example) for them to fill out and send to you.

It’s fairly important to get a decent sized sample of user data. What you’ll need to look for when building your personas is patterns or similarities between users. You’ll want to avoid keying in on one particular person for a persona.

Things you’ll want to find out about:

Personal information, such as age, gender and location.
Technical information like what kind of computer and browser they use, how and why they use the Web, and how often.
Their relationship is to your company, client or organization.
How they view your site, or potential site, as well as those of your competitors.
What they like in a Web site and what they don’t.

You don’t need to limit it to that, and this list should vary depending on the type of site you are building, your audiences and the business you are in. For example, I work for a children’s hospital, so when interviewing parents we asked some generic questions about their kids and their relationship with the hospital. All of that was very important when building our personas.

In addition to the interview data, you can gather some demographic type data from your server logs (technical), and by talking to stakeholders. A good group to speak with, as they will most likely have some of this, is your marketing department.

There are other ways to get information about your users that would be helpful in persona creation. Focus groups, emotional response testing, site feedback forms and surveys can all help you out.

Once you have gathered your data, and hopefully you will have enough to begin to see some patterns emerge, you’ll need to sort that data and summarize it for review. One thing you’ll want to keep in mind is to separate the patterns so that things that apply to the majority of users are not lumped in with patterns specific to single users or very few users. This way you’ll be able to identify a common or primary user base (and persona) as well as a secondary persona. More on that shortly.

It’s alive! Time to Create.

Now that you have gathered and grouped your data it’s time to create a few personas. There are many ways you can do this, all of them good. What I have personally found easiest is to create the personas myself, and not involve a group. This may not work well for you, however. Feel free to involve others if you need to.

I start with my raw data, and I take the groupings I’ve come up with and try to form that data into the traits of a person. I do this until my data is exhausted, or as close as I can get to that. This process will vary depending on the amount of data you have as well as the variety. Hopefully you will have a pretty decent understanding of your audiences and users through the process of gathering the data that will allow you to make some assumptions. Another way you can help yourself is try to find a few “real” people in your pool of data and model the personas after them. Do change the names to protect the innocent.

Once you have some personas mapped out with user data you can identify your primary and secondary user groups. Pretty much all that means is you’ll want to take the two personas that best describe who you think your largest user group and a secondary user group that is very different from the first but still very important.

At this point you should have a persona to represent the most common user group, a secondary persona to represent another vastly different group as well as a few other personas to fill in the rest of your user groups. You don’t want too many, so if you have quite a few, or any that overlap, either combine them or cut them.

If you like you can also get creative and create a back-story or add some personality to your personas. This can not only be fun, but also help you later on when working on real world problems.

Put Your Personas to Work

So now that you have personas, what do you do? Well, that is up to you and the needs of you and your team members. I use my personas for many things. Here’s a list to get you started thinking about how you (and others you work with) can use your personas:

For surrogate user testing.
To help advocate for your users.
To communicate user needs.
To evaluate new features.
To help make design decisions.
To help weigh business decisions.
For task analysis and use cases.
For customer service scripts.

There is a certain amount of role playing and make-believe involved when putting your personas into practice. However silly it may seem, just having the personas around will help you not only think more user- and customer- centric, but help communicate the wants and needs of your users to anyone who might not understand how those needs and wants can help everyone involved.

There is a whole lot more to personas than what I’ve talked about here. I’ve found them to be a very helpful and very interesting design tool, but that is only the beginning. If you want to learn more about personas here are some great resources. Some of these were instrumental in helping me get my first personas created.

– From Practical Persona Creation by D. Keith Robinson

More persona resources:The Inmates Are Running the Asylum. Alan Cooper. My first ever run-in with personas.

Information Architecture: Blueprints For The Web. Christina Wodtke. A great resource, with a lot of good information about personas, and many other things as well.

Cooper: Newsletters on Personas.

Bringing Your Personas to Life in Real Life. Elan Freydenson.

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

Personas: Matching a Design to the Users’ Goals Christine Perfetti.

Take a look at George Olson’s Persona Creation Tool Kit for some ideas to help you get started.

———————————————

Related Information

Why Personas? A visual explanation…

Moving from audience segmentation to personas helps us get specific about design requirements.

“through using personas, designs with superior usability characteristics were produced. They also indicate that using personas provides a significant advantage during the research and conceptualization stages of the design process.” – Frank Long, Research Paper – Real or Imaginary: The effectiveness of using personas in product design

“When Don Norman’s most recent book, Emotional Design, [1] hit the shelves in early 2004, it sent a ripple through the user experience world. Norman introduced the idea that product design should address three different levels of cognitive and emotional processing: visceral, behavioral, and reflective. This idea seemed like old news to some and a revelation to others in the UX community. In either case, Norman’s ideas, based on years of cognitive research, provide an articulated structure for modeling user responses to product and brand and a rational context for many intuitions long held by professional designers.

Norman’s three levels of cognitive processing are:

visceral—The most immediate level of processing, in which we react to visual and other sensory aspects of a product that we can perceive before significant interaction occurs. Visceral processing helps us make rapid decisions about what is good, bad, safe, or dangerous. It is this level of processing—or something quite similar to it—that author Malcolm Gladwell discusses in his latest book, Blink.
behavioral—T he middle level of processing that lets us manage simple, everyday behaviors, which according to Norman, constitute the majority of human activity. Norman states—probably rightly so—that, historically, interaction design and usability practices have primarily addressed this level of cognitive processing. Behavioral processing can enhance or inhibit both lower-level visceral reactions and higher-level reflective responses, and conversely, both visceral and reflective processing can enhance or inhibit behavioral processing.
reflective—T he least immediate level of processing, which involves conscious consideration and reflection on past experiences. Reflective processing can enhance or inhibit behavioral processing, but has no direct access to visceral reactions. This level of cognitive processing is accessible only via memory, not through direct interaction or perception. The most interesting aspect of reflective processing as it relates to design is that, through reflection, we are able to integrate our experiences with designed artifacts into our broader life experiences and, over time, associate meaning and value with the artifacts themselves.” – Robert Reimann, Personas, Goals, and Emotional Design

Additional reading

Examples of user persona and interaction design deliverables

Some examples of persona designs. Use your imagination to create a clean and clear design system to tell us who your persona is, and what their motivations, needs and goals are.

Below is an example of a Persona document that I developed with a design team several years ago at R/GA. It provides a level of detail that allowed my team to propose and design solutions for a large company in Portland.

The Origin of Personas 1

When we say “persona”, designers generally mean some methodological descendant of the work of Alan Cooper. I remember when I first encountered the idea on web-design mailing lists in 1999. People were arguing over what personas were about, and what was the right or wrong way to do them. All most people had to go on was a slim chapter in Cooper’s “The Inmates are Running the Asylum” and some rudimentary experience with the method. You could see the messy work of a community hammering out their consensus. It was as frustrating as it was interesting.

Eventually, practitioners started writing articles about the method. So, whenever I was asked to create personas for a project, I’d go back and read some of the excellent guides on the Cooper website and elsewhere that described examples and approaches. As a busy designer, I was essentially looking for a template, a how-to guide with an example that I could just fill in with my own content. And that’s natural, after all, since I was “creating a persona” to fulfill the request for a kind of deliverable.

It wasn’t until later that Alan Cooper himself finally posted a short essay on “The Origin of Personas.” For me it was a revelation. A few paragraphs of it are so important that I think they require quoting in full:

I was writing a critical-path project management program that I called “PlanIt.” Early in the project, I interviewed about seven or eight colleagues and acquaintances who were likely candidates to use a project management program. In particular, I spoke at length with a woman named Kathy who worked at Carlick Advertising. Kathy’s job was called “traffic,” and it was her responsibility to assure that projects were staffed and staffers fully utilized. It seemed a classic project management task. Kathy was the basis for my first, primitive, persona. In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of PlanIt to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course. From my home near the ninth hole, I could traverse almost the entire course without attracting much attention from the clubhouse. During those walks I designed my program. As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently.

If we slow down enough to really listen to what Cooper is saying here, and unpack some of the implications, we’re left with a number of insights that help us reconsider how personas work in design.

1. Cooper based his persona on a real person he’d actually met, talked with, and observed. This was essential. He didn’t read about “Kathy” from a market survey, or from a persona document that a previous designer (or a separate “researcher” on a team) had written. He worked from primary experience, rather than re-using a some kind of user description from a different project.

2. Cooper didn’t start with a “method”—or especially not a “methodology”! His approach was an intuitive act of design. It wasn’t a scientific gathering of requirements and coolly transposing them into a grid of capabilities. It came from the passionate need of a designer to really understand the user—putting on the skin of another person.

3. The persona wasn’t a document. Rather, it was the activity of empathetic role-play. Cooper was telling himself a story, and embodying that story as he told it. The persona was in the designer, not on paper. If Cooper created a document, it would’ve been a description of the persona, not the persona itself. Most of us, however, tend to think of the document—the paper or slide with the smiling picture and smattering of personal detail—as the persona, as if creating the document is the whole point.

4. Cooper was doing this in his “spare time,” away from the system, away from the cubicle. His slow computer was serendipitous—it unwittingly gave him the excuse to wander, breathe and ruminate. Hardly the model of corporate efficiency. Getting away from the office and the computer screen were essential to arriving at his design insights. Yet, how often do you see design methods that tell you to get away from the office, walk around outside and talk to yourself?

5. His persona gained clarity by focusing on a particular person—”Kathy”. I wonder how much more effective our personas would be if we started with a single, actual person as the model, and were rigorous about adding other characteristics—sticking only to things we’d really observed from our users. Starting with a composite, it’s too easy to cherry-pick bits and pieces from them to make a Frankenstein Persona that better fits our preconceptions.

Personas are actually the designer’s focused act of empathetic imagination, grounded in first-hand user knowledge.

1. Personas and the Role of Design Documentation, How it’s less about deliverables, and more about design. Boxes and Arrows, Andrew Hinton

—