Master Class Webinar: Usability TestingToday 16:00 UTC

Master Class Webinar: Usability TestingToday 16:00 UTC

Pleaseupgrade your browseras its outdated. Youll reduce security risks and help make the internet better.

Your browser is outdatedupgrade it now.

Master Class Webinar: Usability TestingToday 16:00 UTC

Master Class Webinar: Usability TestingToday 16:00 UTC

The Encyclopedia of Human-Computer Interaction, 2nd Ed.

The persona method has developed from being a method for IT system development to being used in many other contexts, including development of products,marketing, planning of communication, andservice design. Despite the fact that the method has existed since the late 1990s, there is still no clear definition of what the method encompasses. Common understanding is that the persona is a description of a fictitious person, but whether this description is based on assumptions or data is not clear, and opinions also differ on what the persona description should cover. Furthermore, there is no agreement on the benefits of the method in the design process; the benefits are seen as ranging from increasing the focus on users and their needs, to being an effective communication tool, to having direct design influence, such as leading to better design decisions and defining the products feature set (Cooper, 1999; Cooper et al, 2007; Grudin & Pruitt, 2002; Long, 2009; Ma & LeRouge, 2007; Miaskiewicz & Kozar, 2011; Pruitt & Adlin, 2006).

A persona is not the same as an archetype or a person. The special aspect of a persona description is that you do not look at the entire person, but use the area of focus or domain you are working within as a lens to highlight the relevant attitudes and the specific context associated with the area of work.

Dorte is 53 years old and works as a secretary in her husbands plumbing business in the suburbs of Copenhagen. There are 5-6 assistants and apprentices in the company.

When Dorte was very young she trained as an office clerk in the accounts department in a department store in Copenhagen. She was married at the age of 21 to Jan who had just got his skilled workers certificate. They have two grown-up sons who no longer live at home in the combined house and workshop/office. Their sons visit frequently as they still enjoy mums cooking.

Dorte likes to keep up with fashion. She often goes to the hairdresser, loves vibrant colours and elegant shoes. When she reads womens magazines, she looks for small tips that she changes and makes her own. She is always smartly dressed and stays fit.

Dorte loves travelling to faraway countries; most recently, she and her family were on a trip to Vietnam this summer. Before they went, she spent time reading up on the country and also watched the film Indochine starring Catherine Deneuve. Dorte always discusses the vacations with Jan, who would prefer to go to Rhodes with old friends, but it is Dorte who has the final say about the destination.

In an average day, she tends to drink too many cups of coffee, and when the telephone rings all the time and she cant reach the assistants, she also tends to smoke a bit too much.

Dorte makes payments to the Danish early retirement benefit scheme and looks forward to the day where she no longer has to be the mum of others any more and can spend more time travelling.

Dorte does the accounts and the bookkeeping, VAT, taxes, vacation pay, the Danish Labour Market Supplementary Pension ATP, etc. She uses a mini financial management system that she has mastered after many years of use, but sometimes the system is not completely logical.

If she were to use other systems or use new, digital reporting, she would prefer it to be demonstrated to her by someone. She feels unable to learn something new when it is just explained to her, and she dislikes reading user guides. She says it takes her a long time to study anything new and familiarise herself with it, and she tends to see more limitations than possibilities in new IT. Dorte often underestimates her IT proficiency and overestimates the time that it will take to learn something new, so she stalls before she even gets started.

If she needs IT help, her oldest son and, less often, a woman friend provide the support. The friend works in a big company and is a super-user of the financial management software.

Dorte handles the tax cards for the business. She deals with and reports the wages, vacations, sickness benefits, and maternity leaves of the staff. She does the VAT returns and annual accounts of the company. In addition, she fills in the reports for Statistics Denmark and the Employers Reimbursement System AER.

Dorte does not understand the logic of the IT system and does not trust everything to happen as it should. If she sends in a return form or report digitally, she likes a confirmation saying that the recipient has received the form.

She is not involved in the plumbing business as a trade, but she knows all the technical terms.

She tidies things up. She does not want the others (her husband and the assistants) to make a mess in the basement where the office is as she is the one who has to look at it all day Tidy up! Your mum does not work here!

She digs in and sometimes has to keep far too many balls in the air at the same time.

She holds the fort, but does not get a lot of professional recognition in the company from the boss/her husband.

She answers the telephone, handles mail, deliveries of goods (including invoices and delivery letters), and email.

She handles the accounts, does some bookkeeping and writes invoices.

She has occasional contact with the accountant.

She handles customer contact (including damage control).

Dorte dreams about a future where she no longer has to work and where she can spend more time travelling. She is still debating with Jan whether they should travel or buy a summer cottage where they can live all year round when they retire.

Figure 30.1: Persona for is a portal for digital reporting. At, Danish companies can find all the forms needed for reporting to the authorities.

The persona approach stems from IT system development where in the late 1990s many researchers had begun reflecting on how you could communicate an understanding of the users. In literature, various concepts emerged, such as user archetypes, user models, lifestyle snapshots, and model users as I termed it when I first wrote about the method in 1997. In 1999, Alan Cooper published his tremendously successfulThe Inmates are Running the Asylum(Cooper, 1999) where the persona as a concept to describe fictitious users was introduced for the first time. Despite the fact that a vast number of articles about usingpersonashave been written, there is no unilateral understanding of the application of the method nor a definition of what a persona description is.

The literature today offers four different perspectives regarding personas: Alan Coopers goal-directed perspective; Jonathan Grudin, John Pruitt and Tamara Adlins role-based perspective; the engaging perspective that I myself use, which emphasizes how the story can engage the reader (Sønderstrup-Andersen, 2007); and the fiction-based perspective. The first three perspectives agree that the persona descriptions should be founded on data. However, the fourth perspective, the fiction-based perspective, does not include data as the basis for persona description, but creates personas from the designers intuition and assumptions; they have names such as ad hoc personas, assumption personas, and extreme characters.

Cooper characterizes his persona method as Goal-Directed Design and maintains that it makes the designer understand the user. Thus, Goal Directed Design is meant as an efficient psychological tool for looking at problems and a guide for the design process. The central core of the method is the hypothetical archetype that is not described as an average person, but rather as a unique character with specific details.

The method focuses on a move from initial personas to final personas. In the beginning of the process, a large number of personas are created based on in-depth ethnographic research. The initial personas grasp an intuitive understanding of user characteristics. Later on, these are condensed into final personas, one persona for each kind of user. Every project has its own set of personas (Floyd et al., 2008).

A persona is defined by its personal, practical, and company-oriented goals as well as by the relationship with the product to be designed, the emotions of the persona when using the product, and the goals of the persona in using the product (hence Goal-Directed).

In other words, it is the users (work) goals that are the focus of the persona descriptions, e.g. workflow, contexts, and attitudes. And, as implied, the advantage of the method is that it provides a focused design and a communication tool to finish discussions.

The role-based perspective shares goal direction with Cooper and also focuses on behaviour. The personas of the role-based perspective are massively data-driven and incorporate data from both qualitative andquantitativesources. Often, dozens of personas are shared among projects (Floyd et al, 2008).

The starting point of the role-based perspective was criticism of the traditional IT system development approaches and of Coopers approach to personas. The traditional use ofscenariosis criticized for lacking clarity and consistency in the user descriptions. Therefore, the critics introduced user archetypes, which can communicate the most important knowledge about the users and thereby support the design process. Jonathan Grudin and John Pruitt criticized Alan Cooper for underestimating the value of user involvement and for seeing the method as one single method that can handle anything (Mikkelson & Lee, 2000),(Grudin & Pruitt, 2002).

The role-based perspective used the criticism as a starting point to develop the method further. The most important additions are, firstly that both qualitative and quantitative materials must supplement the persona descriptions; and secondly that there should be a clear relationship between data and the persona description (Grudin & Pruitt, 2002). Personas can communicate more than design decisions to designers and clients; they can also communicate information frommarket researchusabilitytests, and prototypes to all participants in the project. Finally, the method is regarded as a usability method that cannot stand alone, but should be used in tandem with other methods. The persona description itself should contain information about several issues: how big a share of the market the individual persona takes up; how much market influence the persona has; the users computer proficiency, activities, and hopes and fears; and a description of a typical day or week in the life of the user. In addition to this are strategic and tactical considerations (Pruitt & Adlin, 2006).

The role-based perspective focuses on the users roles in the organization (Sønderstrup-Andersen, 2007). Personas are an efficient design tool because of our cognitive ability to use fragmented and incomplete knowledge to form a complete vision of the people who surround us. With personas, this ability comes into play in the design process, and the advantage is that a greater sense of involvement and a better understanding of reality will be created.

The engaging perspective is rooted in the ability of stories to produce involvement and insight. Through an understanding of characters and stories, it is possible to create a vivid and realistic description of fictitious people. The purpose of the engaging perspective is to move from designers seeing the user as a stereotype with whom they are unable to identify and whose life they cannot envision, to designers actively involving themselves in the lives of the personas. The other persona perspectives are criticized for causing a risk of stereotypical descriptions by not looking at the whole person, but instead focusing only on behaviour (Nielsen, 2004;Nielsen, 2011; Nielsen 2012).

The starting point for the engaging perspective is the way we as humans interact with other people. We experience specific meetings in time and place. We mirror ourselves in the people we meet. And we experience others as both identical to and different from ourselves. Also, we experience relationships that are not specific and where the person we meet is anonymous and represents a type. Here, we use our experiences to understand the person and to predict what actions he or she will perform. If the designers see the users as stereotypical representations, they mould a mental image of the users together with a number of typical and automated acts. These representations prevent insight into the unique situation of the users and reduce the value of the scenario as a tool to investigate and describe future solutions.

An engaging description requires a broad knowledge of the users, and data should include information about the social backgrounds of the users, their psychological characteristics, and their emotional relationship with the focus area. The persona descriptions balance data and knowledge about real applications and fictitious information that is intended to evokeempathy. This way, the persona method is a defence against automated thinking.

The personas in the fiction-based perspective are often used to explore design and generate discussion and insights in the field (Floyd et al., 2008). Ad hoc personas are based on the designers intuition and experience and used to create an empathetic focus in the design process (Norman, 2004). Extreme characters help to generate design insights and explore the edges of the design space (Djajadiningrat et al, 2000). Assumption personas are based on the project teams assumed understanding of their users (Adlin & Pruitt, 2006). Proto-personas originate frombrainstormingworkshops, where company participants try to encapsulate the organizations beliefs (based on their domain expertise and gut feeling) about who is using their product or service and what is motivating them to do so. They give an organization a starting point from which to begin evaluating its products and to come up with some early design hypotheses (Gothelf, 2012). Pastiche scenarios create personas derived from fiction, like Bridget Jones or Ebenezer Scrooge, and help designers to be reflexive when creating scenarios (Blythe & Wright 2006). Examples of pastiche scenarios can be seen at Mark Blytheswebsite.

These personas have spurred discussions about validity and value (see e.g.When does a Persona stop being a PersonaandAssumption personas help overcome hurdles). In line with Adlin & Pruitt (2006), James Robertson (2008) in his articleBeyond Fake Personassuggests a continuum from Persona Sketch, over Persona Hypothesis and Provisional Personas, to Robust Personas ending in Complete Personas.

Floyd et. al. 2008 mention three additional types that they have come across: Quantitative data driven personas are extracted from natural groupings in quantitative data: User archetypes as personas are similar to personas, but more generic, usually defined by role or position: Finally Marketing personas are created for marketing reasons and not to support design.

Criticism of the persona method pertains to empiricism, especially the relationship between data and fiction. The implementation of the persona method in companies has also come under fire (Chapman et al, 2008; Chapman & Milham, 2006; Portigal, 2008; Rönkkö et al, 2004).

Because the persona descriptions have fictitious elements, some find it difficult to see the relationship with real users and the way that the data used is collected and analysed. Furthermore, the fictitious elements apparently prevent the method from being regarded as scientific, as one of the criteria for a scientific method is that the study must be reproducible. This critique is based on an objectivistic scientific paradigm where science consists of statements that can be verified. In contrast to this is the interpretative paradigm where science is understood as the object of continual clarification and discussion (Kvale, 1997). The persona method is as such qualitative; deep knowledge of user needs, attitudes, and behaviour is gathered using qualitative methods. Thus this criticism can be disproven as the critics having misunderstood the starting point of the method.

The method has additionally been criticized for not being able to describe actual people as it only depicts characteristics.

When it comes to implementation, the method is criticized for preventing designers meeting actual users, as actual stories and encounters with real users are assumed to give a better understanding of the users needs. Yet another objection is that the method does not take into consideration internal politics, and that this can lead to limited use. Lately, the latter has been refuted, as can be seen in the suggested 10 steps to personas that involve the organisation in as many steps as possible.

I now provide a brief introduction to why the persona method is a useful design tool, what personas are used for, how they are constructed, how to use them, and what to consider in the communication of personas.

In the design process, we begin to imagine how the product is to work and look before any sketch is made or any features described. If the design team members have a number of persona descriptions in front of them while designing, the personas will help them maintain the perspective of the users. The moment the designers begin to imagine how a possible product is to be used by a persona, ideas will emerge. Thus, I maintain that the actual purpose of the method is not the persona descriptions, but the ability to imagine the product. In the following, I designate these product ideas asscenarios. It is in scenarios that you can imagine how the product is going to work and be used, in what context it will be used, and the specific construction of the product. And it is during the work with developing scenarios that the product ideas emerge and are described. The persona descriptions are thus a means to develop specific and precise descriptions of products.

A scenario for could be described like this:

Dorte sits at the computer ready to handle the reporting. She goes to and looks at the front page. Dorte tries to take it all in. It is new and thus a little daunting, but at least it looks nice with those colours, she thinks, while at the same time she says to herself: What do I do now I have installed my signature. I need to find the report form, but where? Well... look, in the middle of the page is a search box, maybe I can try searching for it. Dorte writes Apprentice refund in the search field and launches the search. A new screen appears with a short list of hits. At the top is a link to the form she wanted.

Figure 30.2: Excerpt of scenario for

In this case, the designers got the idea that there should be a search field in the middle of the homepage. This would support a shift from information push in the old version of the webpage to form retrieval in the new version.

Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section Exceptions in thecopyright termsbelow.

Figure 30.3: The front page has an additional search field for Dorte, and focuses on reporting (2008). The latest version of the portal has yet again an unclear focus on the front page as it includes both reporting and different guidelines, for example, for company start-ups

When personas are used for IT system development, it is mainly to explore interaction and navigation. On the other hand, they are not suited to describing what kind of information the system is to contain. For, four personas were created. One of these personas, Jesper, is an accountant. Jesper represents all the users reporting for other companies, not, however, including for example agricultural consultants. When Jesper is used in the scenario, he illustrates what demands those who report on behalf of companies have of the product, both how they think and how they would like to see the information presented. But Jesper does not represent what information and reporting forms should be available on the site. If he did, there would be no reporting forms for agricultural consultants.

In IT systems development, there are specific methods to describe the system navigation and interaction e.g. Unified Modelling Language or theuser storieswithinagile developmentmethods, where the scenarios are described in illustrated and narrative stories. It is quite easy to insert the personas into these methods.

As the persona method developed from a method for IT system development to also working within product development, a shift in the method occurred that has had an impact on how the method is used and what it can be used for. When personas are used for product development, the scenario takes a different path. Here, the users processes and interactions with the product can more easily be understood as role-playing and story-boarding, and the ways of capturing ideas are less formalized.

The persona is ideally shaped according to user studies, and used forideation. But the process varies; sometimes the idea comes first, and the persona is created later and used to verify or enrich the idea (Chang et al., 2008). Studies have shown that one of the main difficulties in the method is to get project participants to use it (Browne, 2011). In the following, I present a process model that sets out to cover this problem throughout the process. It contains four different main parts: data collection and analysis of data (steps 1, 2), persona descriptions (steps 4, 5), scenarios for problem analysis and idea development (steps 6, 9), and acceptance from the organization and involvement of the design team (steps 3, 7, 8, 10).

The 10 steps cover the entire process from the preliminary data collection, through active use, to continued development of personas. It is an ideal process, and sometimes it is not possible to include all steps in the project (Nielsen, 2011; Nielsen 2012).

1. Collection of data.In the first step, you collect as much knowledge about the users as possible. Data can come from many different sources, even from pre-existing knowledge in the organization.

2. You form a hypothesis.Based on the first data collection, you form a general idea of the various users within the focus area of the project, including in what ways the users differ from one another.

3. Everyone accepts the hypothesis.In this step, the goal is to support or reject the first hypothesis about the differences between the users. This happens by confronting project participants with the hypothesis and comparing it to existing knowledge.

4. A number is established.In this step, you decide the final number of personas.

5. You describe the personas.The purpose of working with personas is to be able to develop solutions based on the needs of the users, which you do through preparing persona descriptions that express enough understanding and empathy for the readers to understand the users.

6. You prepare situations.As already mentioned, the method is directed at creating scenarios that describe solutions. To that purpose, a number of specific situations that could trigger use of the product are described. In other words, situations are the basis, or the precursors, of a scenario.

7. Acceptance is obtained from the organization.It is a common thread throughout all 10 steps that the goal of the method is to involve the project participants. This means that as many as possible should participate in the development of the personas and that it is important to obtain the acceptance of the participants of the various steps. That is why all should contribute to and accept the situations. In order to achieve this, you can choose between two strategies: You can ask the participants for their opinion, or you can let them participate actively in the process.

8. You disseminate knowledge.In order for the method to be used by the project team, the persona descriptions should be disseminated to all. It is, therefore, important early on to decide how this knowledge is to be disseminated to those who have not participated directly in the process, to future new employees, and to possible external partners. The dissemination of knowledge also includes how the project participants will be given access to the underlying data.

9. Everyone prepares scenarios.As previously mentioned, personas have no value in themselves. Not until the moment where the persona is part of a scenario - the story about how the persona uses a future product - does it have real value.

10. On-going adjustments are made.The last step is the future life of the persona descriptions. The descriptions should be revised regularly, approximately once a year. There can be new information, or the world could change and new aspects may affect the descriptions. Decisions have to be made whether to rewrite the descriptions, or add new personas, or whether some of them possibly should be eliminated.

Author/Copyright holder: Lene Nielsen. Copyright terms and licence: All Rights Reserved. Reproduced with permission. See section Exceptions in thecopyright termsbelow.

Figure 30.4: The poster covers 10 Steps to Personas

One of the perceived benefits of personas is that they give the design team a mental model of a particular kind of user, which allows the team to predict user behaviour. The personas evoke empathy with users and prevent designers from projecting their own needs and desires onto the project (Floyd et al., 2008). For the persona to evoke empathy, the description needs to be crafted in such a way that the reader can imagine a real person, understand this persons needs and desires, and predict the persons future actions. In the following, I go into more details about how personas and scenarios are tightly interlinked withstorytellingto evoke empathy and identification. Here, I am thinking both of the relationship between the fictitious characters and the story and the general narrative structures.

Using narratives is nothing new within IT system development (Madsen & Nielsen, 2006), where stories have been suggested as a starting point to collect data and as a method to theorize over various project types and project phases. At the same time, focus on stories can play a part in providing insight into what goes on outside and below the official course of events. Thereby, the many, often contradictory and competing, stories and interpretations that circulate in an organization can be revealed. Stories can also be used when you want to theorize about organizations, IT systems, and IT system development. An organization can be seen as a collective narrative system where members construct and play out sequences of events on an on-going basis, both individually and together, to be able to remember and to create meaning in past, present, and future events (Boje, 1991; Boje, 1995). These sequences can be used in the process of structuring both the IT system development process and the IT system itself. Here, the narrative contributes to establishing a partnership and a common understanding of the players involved and their goals. This applies in relation to both the development and the presentation of the system to the user (Gazan, 2005). Stories work on several levels, and also provide templates for gathering and analysing empirical data. This happens in interview situations when you need to determine system requirements. The developers can focus on the users stories about existing and future practice, analyse them, and thus become more aware of requirements (Alvarez & Urla, 2002). These requirements can later on be described in narrative scenarios that are easy to relate to and easy to remember. The scenarios draw on our ability to create meaning individually and together, and to arrange and concentrate information in a narrative form (Carroll, 2000). Subsequently, the stories can be used to analyse the process, the mistakes that occurred, and the political implications of the development and implementation process (Brown, 1998; Brown & Jones, 1998).

To describe users as personas helps designers to engage in the users during the entire design process. It enables the design team to engageinthe user and to focus the designonthe user. But the descriptions can conflict with the preconceived perceptions the designers have their stereotypical images.

When we encounter a stranger, we have a tendency to see the person as a stereotype. We do not see the person as possessing a unique constellation of characteristics, but add him to a previously formed category (Macrae & Bodenhausen, 2001). The stereotype is built on knowledge of previous meetings with others and ordered into categories that form the basis for the stereotype. One definition of stereotypes is that they are socially constructed representations of categories of people (Hinton, 2000). The st