A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype. In most cases, personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to bring the persona to life. For each product, or sometimes for each set of tools within a product, there is a small set of personas, one of whom is the primary focus for the design.
It's easy to assemble a set of user characteristics and call it a persona, but it's not so easy to create personas that are truly effective design and communication tools. If you have begun to create your own personas, here are some tips to help you perfect them.
A good persona description is not a list of tasks or duties; it's a narrative that describes the flow of someone's day, as well as their skills, attitudes, environment, and goals. A persona answers critical questions that a job description or task list doesn't, such as: Which pieces of information are required at what points in the day? Do users focus on one thing at a time, carrying it through to completion, or are there a lot of interruptions? Why are they using this product in the first place?
There is seldom a one-to-one correlation between personas and job descriptions. In some cases there will be multiple personas with the same job description; in others, a single persona can represent people with a wide range of jobs. If you were creating software used by call center agents, for example, you might have an experienced agent persona who is very familiar with the product, as well as an inexperienced agent who needs more prompts and written information. If, on the other hand, you were designing an e-mail application, one persona could represent people with hundreds of very different job descriptions, as long as they all shared similar goals and behavior patterns related to communication.
If you've ever read a book or watched a movie with an enormous cast of characters, you may have found it hard to remember who was related to whom, who said what, and so on. You probably didn't feel like you knew any of the characters very well. If you were designing a product for such a large cast of characters, could you predict how so-and-so's cousin (whose name you forget) would behave in a certain situation? Probably not. That's why a large set of personas is problematic—the personas all blur together.
Ideally, you should have only the minimum number of personas required to illustrate key goals and behavior patterns. There's no magic number, but if you're designing a consumer product and you have a dozen personas, then you may be making distinctions that aren't very important. For example, if you were creating an electronic family calendar, your persona set might include a career mom, a stay-at-home mom, a career dad, and a teenager. If the career mom has the same needs as the career dad, and also does all the family management the stay-at-home mom does, you may be able to eliminate both the dad and stay-at-home mom personas.
Many product managers and executives are surprised when there isn't a direct correlation between market segments and personas. The people who bring in the most revenue may not be the best design target. If you were designing an in-flight entertainment system, a frequent business traveler—every airline's most valued customer—would be a tempting design target. A business traveler would actually make a poor design target, though, because he would be too familiar with flying and with using computers and other gadgets. If you design for the business traveler, the retired bricklayer going to see his grandchildren won't be able to use the system. If you design for the bricklayer, the business traveler will also be happy.
Sometimes it's easy to focus too much on a persona's biography. Personal details can be the fun part, but if there are too many of them they just get in the way. To avoid this problem, focus first on the workflow and behavior patterns, goals, environment, and attitudes of the persona—the information that's critical for design—without adding any personality.
Once you have the critical design information, add just one or two personal details, such as what your persona does after work (she goes home to watch old movies with Claude, her cat), or what personal touches there are in her workspace. You can also add life to the persona by using environmental details to reinforce important characteristics. For example, if someone tends to be incredibly busy at work, don't just say he's incredibly busy; instead, say there's a sandwich on his desk that he's been trying to find time to eat for three hours. Without a little bit of personality, personas can easily turn into generic users instead of precise design targets.
Each persona should have three or four important goals that help focus the design. Keep in mind that goals and tasks are different: tasks are not ends in themselves, but are merely things we do to accomplish goals. Not just any goals will do, though, so it's important to understand which types will help you make design decisions.
Life goals are only occasionally useful in design. For example, "Retire by age 45" would be of little use if you were designing a word processor, mobile phone, or PDA, but it may offer valuable insight when you're designing a financial planning tool.
Experience goals describe how the persona wants to feel when using a product; having fun and not feeling stupid are experience goals. Not every persona needs an experience goal; in most persona sets, there is one persona who represents people with a lot of anxiety about technology. One of this person's goals is to avoid feeling stupid. Other experience goals might center on the product domain. A persona using an online banking site, for example, might want to feel confident that his transactions are secure.
Most persona goals should be end goals that focus on what the persona could get out of using a well-designed product or service. End goals may involve the work product that results from using the tool. For example, a graphic designer using a layout tool might want to create an award-winning ad. End goals can also involve indirect benefits from using a product. If a manager wants to be more proactive, a better spreadsheet tool can help her achieve this goal if it makes her more efficient.
Organizations with more than one product often want to use the same personas over and over ("We have a salesperson persona already—why can't we use her for the spreadsheet as well as the contact management software?"). Unfortunately, this doesn't work because effective personas must be context-specific—they should be focused on the behaviors and goals related to the specific domain of a product. A persona's behaviors and goals related to contact management have very little to do with those related to manipulating financial data. You could keep the same name and personal details, but you'd have to throw away the rest of the persona and start over. It's better to start with a new set of personas for each product.
Ten steps to Personas
Design Research / Article 3.
First Published in July 2007, HCI Vistas Vol-III
Author: Dr. Lene Nielsen
Having worked with personas before the method ever came to be known as personas there are, from my research and practical experience, three important areas that have to be considered: the data material, engagement in the personas descriptions, and buy-in from the organization which is part of the development process whether it is redesign or a development from scratch. This is the rationale behind my development of 10 steps to personas, an attempt to cover the entire process from initial data gathering to ongoing development.
In the following I will briefly outline the 10 steps. Any project that uses personas does not necessarily need to follow all 10 steps as long as the responsible party knows the consequences of skipping a step.
The initial step is to get hold of as much knowledge of the users as possible. The data can originate from several sources: interviews, observations, second hand information, questionnaires, reports, cultural probes etc. In my experience large companies have often a lot of information about the users, reports from marketing, call centers etc. these can in some extend substitute real life meetings with users, but they also create problems as they do not focus on the subject that the project is about. This might become visible in the next step.
Working with personas is focusing on users in a certain context which originates from the project. Often companies have a certain way of talking about their users that does not take into consideration the different context the users might be in when using a website or a system. In a recent project for a national Danish authority concerning redesign of a web portal business reports to different governmental authorities, the national authority had a tradition for dividing Danish businesses into categories of size and trades. From interviews with staff in the call center and reading of several a hypothesis was formed.
The former division of businesses did not make sense in this project, as it does not matter which trade the one who has to do the reporting is in, what matters it seemed is how big the company is, and whether the persons who reports is employed within the company or a consultant of some sort. There had been a number of surveys performed, but none of these had this division in mind and had to be reread from the new perspective.
In my experience the most difficult task in persona project are €œhow to cut the cake€ - coming from data to a decision of how may personas descriptions to include. This takes several of the 10 steps and involves more than a group of consultants or project members to just hand over some descriptions.
In €œVerification€ the focus is on finding data that supports the initial patterns and at the same time supports the personas descriptions and the scenario writing. The persona method requires a certain kind of information that can help generate engagement in the descriptions and support scenario writing e.g. what does the users like ad dislike, what are their values, what are their attitudes towards the system/site, in what conditions will they use the system/site? When these data are collected do they then support or go against the initial data.
My inspiration in this and the previous step originates from making sense of data in qualitative inquiries. The way you know that you are on the right track is when others can follow your argumentation and others can come to the same result. Therefore it is of importance to show the categorization to other team members, project partners etc.
A crucial step is what to include in a personas description and how to avoid creating stereotypes. I have quite often seen personas descriptions that either depict super humans or stereotypes that is difficult to engage in. In this phase you must remember that the whole purpose of personas is not to describe users as such, but to create solutions that use the needs of the persona as a starting point.
Drawing on knowledge from fictional writing of characters 5 areas need to be present in the description, not mentioned specifically, but possible for the reader to deduct from the description.
- Body (a photo or a description of how the person looks creates a feeling of the person as a human being, posture and clothing tells a lot about the person)
- Psyche (we all have an overall attitude towards life and our surroundings which also influence the way we meet technology e.g. is the persona introvert or extrovert)
- Background (we all have a social background, education, upbringing which influence our abilities, attitudes and understanding of the world)
- Emotions and attitudes towards technology and the domain designed for
- Personal traits. This one is tricky, in fictional writing there is a distinction between flat characters and rounded characters. The flat character is characterized by having only one character trait which is reflected in all actions the character does and creates a highly predictable character close to the stereotype. The flat character is difficult to engage in. The rounded character has more than one character trait, is not predictable and easier to engage in. When writing personas is becomes essential to avoid the stereotype and create descriptions that the project team members can engage in. Therefore it is advisable to look for information that repeats the same trait. In a case I had, the persona to be described liked to feel in control, from this the team members writing the description made her work for the tax authorities, this came to reflect her attitude to life, she became overweight and with few friends. For them the information of being in control created a negative attitude towards the persona that was repeated in all information.
The fifth step is also a step that can ensure that can enhance buy-in. In my experience it is few organizations who allow for team members to be part of the writing process instead they use consultants or the usability department to write the descriptions. The personas method should rather be perceived as a process where everybody should understand how the descriptions came about and what they can be used for. If you allow different team members to be part of the writing process they feel ownership for the personas. They can be rewritten be a single person to ensure homogeneity in writing and presentation, but it pays off later to include more in the writing process or as we did in a project, to let the participant choose the pictures for the personas.
I am fully aware that not everybody can be part of the process, newcomers arrive, a row of companies might be involved, but if the personas are not disseminated to participants they are not worth anything. It is not only the personas that need to be distributed to everybody, but also the data behind (the foundation document as Grudin, Pruitt, Adlin calls it) and not least how and for what you are to use the personas. Many projects forget to inform and teach developers and designers how to use the personas, how to think in scenarios or how to use them in the use-cases.
As mentioned earlier the real purpose of the personas is to create scenarios from the descriptions. This step is a preparation for the scenarios where it is described in which situations the persona will use the system/site or which needs the persona has that will lead to a use situation. Each need or situation is the beginning for a scenario
To ensure that all participants agree on the descriptions and the situations two strategies can be followed: ask everybody their opinion and let them participate in the process. Often the persona method is viewed as mean for communication users to developers and others, but is as much a process that ensures a user-centered development. Having a process view helps create sessions where as many stakeholders as possible can be involved in the developing the personas and in using them for design.
I am fully aware that not everybody can be part of the process, newcomers arrive, a row of companies might be involved, but id the personas are not disseminated to participants they are not worth anything. It is not only the personas that needs to be distributes to everybody, but also the data behind (the foundation document as Grudin, Pruitt, Adlin calls it) and not least how and for what you are to use the personas. Many projects forget to inform and teach developers and designers how to use the personas, how to think in scenarios or how to use them in the use-cases.
As mentioned earlier, personas are nothing in themselves, it is when a persona enter a scenario they prove to be valuable. A scenario is like a story, it has a main character (the persona) a setting (somewhere the action takes place), it has a goal (what the persona wants to achieve), it has actions that lead to the goal (interactions with the system/site/device), and -not least- it has obstacles that blocks the way to the goal. I have seen quite a number of what I call happy scenarios, where a device solves all problems. Try to read this description of Mrs Tahira Khan and how she overcomes her diabetes and you will see what I mean. It is not a very realistic or convincing example that a 65-year old woman, who recently traveled to UK, who has undiscovered diabetes, hardly any understanding of the English language and relatively poor literacy in her own language overcome her diabetes with an electronic device.
Lastly I recommend updating information on the personas. This can be done if user tests suddenly show new results or if something changes in the personas environments. It is crucial that not everybody is able to change the information, but knows whom to contact. I often recommend having a personas ambassador, who looks into the descriptions now and then, and who project participants can contact if they find irregularities in the descriptions. And as Adlin and Pruitt recommend in ‘The Personas Lifecycle’ to let the personas die, when they have outlived their purpose.
Références:
: http://www.cooper.com/journal/2001/08/perfecting_your_personas.html
Ten steps to personas: http://hceye.org/UsabilityInsights/?p=73