Usability: How To Create Effective Personas
If you want to design your web site with a user-centered approach, using personas, can greatly facilitate your task. Here in fact is a great simple guide to how to create your own personas.
Photo credit: Ron Chapple Studios
Personas, is a term utilized in design and usability analysis to identify specific customer profiles. Personas are all round descriptions of such possible customers and they serve the purpose of helping designers and information architects best identify the needs and expectations of each potential target customer group.
"Personas or personae are fictitious characters that are created to represent the different user types within a targeted demographic that might use a site or product.
Personas are given characteristics and are assumed to be in particular environments based on known users' requirements so that these elements can be taken into consideration when creating scenarios for conceptualizing a site."
In this pragmatical essay, Dr Lene Nielsen illustrates how important the research data, the personal engagement in defining personas and the buy-in from the organization commissioning the work are absolutely critical to the succesful outcome of useful personas.
Intro by Robin Good
Ten Steps To Personas
by 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, no matter whether this is a redesign or a full new 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.
Step 1: Finding the Users
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.
Step 2: Building a Hypothesis
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.
Step 3: Verification
In my experience the most difficult task in persona project are "how to cut the cake" - coming from data to a decision of how many 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.
Step 4: Finding Patterns
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.
Step 5: Constructing Personas
A crucial step is what to include in a persona 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 it 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.
This fifth step is also a step that can ensure and facilitate buy-in. In my experience there are few organizations who allow for team members to be part of the writing process. More often 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 will feel ownership for the personas they create.
Personas 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.
Step 6: Defining Situations
As mentioned earlier the real purpose of personas is to create scenarios from the descriptions. The scenarios serve to describe in which situations the persona will use and interact with the site or system in question as well as the set of needs that will drive this specific persona to use that site or system. Each need or situation is the beginning for a scenario.
Step 7: Validation and Buy-in
To ensure that all participants agree on the descriptions and the situations, two strategies can be followed:
a) ask everybody their opinion and
b) 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.
Step 8: Dissemination of Knowledge
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 individual descriptions of the personas are not disseminated to participants, they are worth nothing.
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.
Step 9: Creating Scenarios
As mentioned earlier, personas are nothing in themselves, it is when a persona enters a scenario that this method proves 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 block 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. The story around her is not a very realistic or convincing example that a 65-year old woman, who recently traveled to the UK, has diabetes, has hardly any understanding of the English language and has relatively poor literacy in her own language, overcomes her disease with an electronic device.
Step 10: Ongoing Development
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 anomalies in the descriptions. And as Adlin and Pruitt recommends in "The Personas Lifecycle" to let the personas die, when they have outlived their original purpose.
About the author
Lene Nielsen is a user-experience, interaction design and usability expert. Lene wrote her Ph.D. thesis "Engaging Personas and Narrative Scenarios" in 2004. Dr Nielsen has also written extensively on scenarios and she has published several papers on the subject. She is part-time assistant professor at Center of Applied ICT, at Copenhagen Business School
and part-time usability consultant at Snitker & Co. You can read more about what she does on her blog (mainly in Danish) www.personas.dk . Dr Nielsen can be reached at: ln.caict @ cbs.dk
If you'd like to learn more about personas, you may want to check out the following links:
- Personas, Participatory Design and Product Development:
An Infrastructure for Engagement - A paper by Jonathan Grudin and John Pruitt
- The Next Frontier for User-Centered Design: Making User Representations More Usable - A paper by John Pruitt and Tamara Adlin
- Personas at Usability.gov
Dr. Lene Nielsen -
Photo credit: Sanja Gjenero
Reference: HCI Vistas [ Read more ]
blog comments powered by Disqus