Dealing with interviews when creating Personas: a practical approach

Dealing with interviews when creating Personas: a practical approach Pedro Jorge Adler Royal Institute of Technology (KTH) [email protected]

ABSTRACT

Personas, employed in User Centred Design to facilitate user modelling, is still recent in Interaction Design – appeared formally in 1999, and the literature available is quite scarce. When we tried to use personas in a project, we found it difficult to create them. The use of personas is becoming common in university projects, however the lack of examples in the literature might lead to the misuse of this tool. We observed that when we looked at how eight groups of students, in a university course, created their personas. Our aim in this paper is to present how we have treated the data from interviews to create personas. We believe this will help and motivate others to use this tool and, as a result, better methods to analyse the data and create personas can be developed. Author Keywords

Persona, Design Method. ACM Classification Keywords

H.5.2 Information Interfaces and Presentation: User Interfaces: theory and methods, user-centered design. INTRODUCTION

Cooper presented personas formally in his book [2] as a response to the need of modelling the user in a consultancy company. Before, the closer concept was user profile that tried to describe the user but in a very simple way and with a weak character. A persona aims to represent a user that is more believable and vivid. Looking for a better way to explain how to create personas we observed how eight groups of students, in a university course (Interaction Design course from a Master Program), created personas for their project. They had to design a prototype for a machine and personas were used to model their users. We noticed that the groups had difficulties to deal with the data or they did not know how to deal with it. We observed how they did Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Proceedings of Student Interaction Design Research Conference SIDER05, Jacob Buur and Ben Mathews (Editors). Sønderborg 27-28 January 2005, University of Southern Denmark, ISBN 87-909233-56-1

84

and we tried to come up with a better way to deal with the data in order to find the behavioural variables (aspects that represent different behaviours among the users). Later, we tried this approach with the data from one group to create a persona and it was much easier to create the personas and they looked more real. From our observations to the groups’ personas it seems that by not having an easy way to analyse information, they tended to use only quantitative data to create the personas without understanding the importance of qualitative data. For example, in most groups, the personas were created based on closed questions that had as answer “yes or no” or a “multiple choice” rather than on open questions, like “how” and “why”, to try to access more information about the users, their behaviours, likes and dislikes. And, when personas are not based on qualitative data (or based on no data at all) this tool might be difficult to use, disappointing and probably will not support the design process. Hence, instead of creating personas based also on qualitative data they are sometimes, wrongly created as stereotypes based only on quantitative data and at times representing “the designer biases and assumptions” [3, p.60]. Others, e.g. [6 and 11], used quantitative data to create hypothetic personas that were, later on, refined by qualitative data. When talking with colleagues we felt that there are still people thinking that personas are created from market analysis. This situation motivated us to put in writing our reflections and experiences, as an augmentation to what [2, 3 and 5] presented. A set of guidelines was developed and will be presented in this paper. Our concerns when creating personas will also be discussed. The focus of this paper is on how the data that was collected from the interviews (as the author was part of one group) was arranged, and present the several steps of creating a persona, based on [3], only detailing the parts that are not carefully explained by others [3, 5 and 6]. The personas in the project were created based on observations in loco and in thirty interviews, from which thirteen were done after we came up with the method presented in this paper. BACKGROUND A persona is a fiction person, or a user archetype, that can help to make decisions about the features a system should have in order to meet users’ needs, both on a functional and visual level [4]. It represents a group of users with similar usage patterns and goals [8]. Moreover it helps a

designer to “determine what a product should do and how it should behave”, “build consensus (…) [and] a common language”, “measure the design’s effectiveness” [3, p.5657] and “provide a conduit for conveying a broad range of qualitative and quantitative data” [10, p.1]. Used in conjunction with scenarios (e.g. [9]) they can “assess fit between a design and its intended usage context” [1, p.153]. Persona has become increasingly popular among usability practitioners, although as a methodology it has not been thoroughly researched [8]. Markensten goes on saying that persona has been rejected by some, since it replaces some actual user participation. Another point for rejecting personas is that the design process needs reflection, not only guidance, and personas apart from users, who intervene with one design, do not give any suggestions. Others accepted it arguing that replacing some user participation is its strength since actual user involvement in the design work can be perceived as a hinder, rather than a help, for instance, when designing systems for a very broad audience, such as, on the Internet, where it is difficult to pick a typical user. In our study, persona proved to be very useful as a tool to bring forth different user groups into the design process. Personas are a very powerful tool to communicate user requirements to different stakeholders in a project, e.g. programmers, project managers and clients. In our study personas also helped to develop proper scenarios and explain design decisions. Using personas in User Centred Design will help to understand for whom we are designing, instead of designing biased by own goals. For example, [8] exemplifies how persona helps us to understand, focus on user requirements, and communicate these requirements among different stakeholders in a project. HOW TO CREATE PERSONAS – A GUIDELINE A good explanation about what personas are and how to create them can be read in [2 and 3]. By definition personas are goal-oriented design tools [3], hence it is fundamental to base their design in the different goals that people might have. Personas represent a group of users that would use a system in similar ways, users that share some common goals. That is, when we are segmenting the interviews in user groups the focus is on people’s needs and goals, rather than on demographic variables or purchasable resources as in market research. This is the reason why quantitative data is not enough to create personas. In market research, it might work, since the question is often “how many….”, but when creating personas the questions we want to find answers to are more “Why do they do X…?” and “How?”, which requires, by definition, qualitative data. Even in the case presented by [11, p.831], where quantitative data was helpful to “understand primary and secondary motivation of the persona” it was only “enough information to start with persona development, but [they] needed to do more user research to finish the process”.

Collecting data This is the “investigation phase” (see [2, p.142 and 5] for more details). Market analysis or quantitative questionnaires might help to get an idea of the population one will find but this information should not lead to define a final persona. Questionnaires can also help to segment the interviews by age, role or activity and briefly give some expectations that might help in the interviewing task (e.g., selecting people to be interviewed, types of questions). Questionnaires are only helpful to give a general idea of the people needed to be interviewed and perhaps to create hypothetical personas. Assumptions should be avoided and the interviews should be as open as possible. Without a lot of experience in interviewing several iterative interviews are advisable, so there will be some more time to get better prepared and become more acquainted with the users. When some knowledge about the setting is known or available it might be a good start to create hypothetical personas. Questions

The goal is to understand what users do, what frustrates them, and what gives them satisfaction rather than just asking what they want [3]. The following key points, derived from our study, were found very relevant: Finding what the users want to accomplish or what motivates them – their goals. We tried to understand how the users would use the machine, i.e., the prototype we had to do, and in what context – their behaviour when facing their activity. For example, to design a music selling system we should go to a music store in order to find out how people actually find what they want, what motivates them to go there instead of using other means. Clear understanding of the difference between goals and tasks. Reflecting on this helped us to prepare the interviews. Look at [2, chap.10] for some examples. Open vs. closed questions. Closed questions can be useful to segment the users but they do not tell much and tell almost nothing about the user’s goals, wishes, desires, needs and behaviours. Sometimes the questions will also result in wrong answers. For instance, when we asked to a person if she had problems with machines she quickly said “no” and added “nowadays, no one has problems with machines because we are used to them, maybe older people have...” Naturally, she did not want to feel she could not use a machine. Later, we asked her to tell us her experiences with three machines at home and she pointed out several problems in using two of them. Therefore instead of asking “do you ever face a problem with…?” we had to ask more generally, for example, “what is your experience with the machines you most use at home?” and then go to more details by asking “what makes your day enjoyable when using that machine? And not enjoyable?”.

85

During the interviews we also noticed that a few very good interviews are worth of many short and quick ones. “Why?” We found essential that for each question, we understood why that person did (or did not do) a certain thing and what were the reasons behind. We had a list of topics related to the design we intended to do and, during the interview we browsed through the list to see if we covered all the topics without letting them strictly lead the discussion. We felt that it was important to let the user speak freely.

Figure 1 shows how we organised the data from the interviews to keywords and then to behaviour variables, and also how we kept references from the goals to the data. A. Interviews Interviews

Keywords

Variables (BV) Keyword A

BV 1

(e.g. Price)

Extreme goals a and b.

2

Different view of the same aspect. We asked about the same topic in different ways to be able to discover new characteristics of the same aspect. The interviews were an open dialogue where we talked with a person about her experiences, preferences, ways of dealing with certain things and why they did something in that manner.

7

4.

5. 6.

…and so forth. These questions are presented as an example from our study and resulted from our reflections when preparing the second iteration of interviews. From data to behaviour variables

The data needs to be grouped in behaviour variables, i.e., aspects that characterise the different behaviour of people interviewed or observed. These variables can be represented as “ranges with two ends” (look at [5 and 3, chap.5]), for instance, in our case we had variables like “product price and quality of service”, “frequency of use”, “attitude towards change”, and so forth. We were very careful to not loose contact with the original data, whenever we had a question we looked for the answer in what we collected, interviews and observations.

86

(e.g., Price vs. Quality of service) BV 2

(e.g. Quality)

Extreme goals c and d.

3

1

12

10

Keyword C

11 4 …

BV 3 Extreme goals e and f.

9

Examples of some of the questions we put: What would lead you to do so? Or use X? Why? What do you usually do when…? Why...? How is your experience with a tool A (or product A)? What makes you happy about it? Which situations made your day joyful when you used it? And the opposite? If you do not know something where do you look for information about it? Who do you ask? How easy is it to deal with that information? Which persons would you ask for help to use Y? Are you happy to explain if someone would ask you? What makes a good, fun and boring day at work? (For example, when designing work oriented systems).

5

Keyword B

In our interviews we found several goals, such as: pricing, quality, safety, efficiency, speed, personal contact, etc. We also observed that each person interviewed had priorities for each goal and finding out what was this priority showed to be very relevant to prioritise our requirements for the machine we had to prototype. A detailed explanation about goals can be found in [2, p.150 and 4].

1. 2. 3.

Behaviour

…

13 6

8 …

The circles with numbers represent pieces of text and are just a way to keep a reference to the original text. The doted line separates different interviews. Figure 1 – Scheme representing how we grouped the data keeping a reference to the interviews

When we analysed the interviews we went through a process where we reflected on the data trying to find keywords representing patterns that later on helped us to find the important behaviour variables. During this process it was vital to keep references to the original data, as we needed to get back to it several times, whenever we had a question about a variable or about the position of a persona in the ‘behaviour mapping’ [3, p.69]. Also when we were comparing personas we had to look to the original data to verify if the goals were the same. In our study, we enumerated all the questions of the interviews and the answers of each person. Later, a reference to the original data was kept (e.g. in Figure 1, in keyword A we have two pieces of text from the first interview, identified with the number 2 and 5, and one from the second interview, identified with the number 7). It happened that some pieces of text were suitable for different keywords. The keywords were the pre-variables that we used as the behavioural patterns. Sorting out the data by the keywords helped us to verify the behavioural

variables and see which ones we could use later on to map the interviews to a position in the behaviour variables (Figure 2). For instance, imagine that you find a mapping between two keywords price and quality; this relation could be represented by the behaviour variable one (BV 1) as a mapping representing the relation price vs. quality, having as the extreme goals (a) people that value prices and (b) for people that do not think about price but prefer quality (of service, for example). This way of linking the variables with the data made it easier to look back to the original data. B. Clustering to create Personas First, we created a map with all our behaviour variables (BV). Below there is an example for three relations of our BV, which are not necessarily opposite values. BV1 – Price vs. Quality Price

Quality of service BV2 - Frequency of use

Everyday

Rarely

Against

Then, as shown below, the number of the interviews was put under the respective variable graph: BV 1 1, 2, 3

5, 8

4

6, 7, 8

4

1, 2, 3

3

6, 7, 8

BV 2 6, 7, 8

5, 8 BV 3

5, 8, 4

1, 2

We continually looked at the interviews to confirm the relative position of each person. This example shows three clusters ({1,2,3}, {5,8,4} and {6,7,8}) but only one was marked with a dashed line to illustrate the cluster for one persona.

Figure 2 – Using behaviour variables to create personas

C. Refinement and Description Persona 1 Picture

Name “Motto” List of goals “Short description”…

D. Personality and Scenarios Besides considering all the items above: name, picture, motto, characteristics; a persona needs to seem a real person, someone you could meet one day. [9] looked at how characters for the movie scripts were written, since they look realistic and he suggests that we should look for three aspects when constructing our personas: 1) multiple traits, 2) psychology, physiology and sociology and 3) inner needs and goals, interpersonal desires and professional ambitions. E. Add Scenarios

BV 3 – Attitude towards change For

The persona has to look real and be a believable representation of the actual users. The name also needs to be well chosen and a believable name for the personas age and class. In our study we found it useful not to choose a name of someone we knew quite well as we could start to think about that person’s characteristics and not those of the persona that we created. We did not have enough data and time but at this point we could have enhanced our persona by going to the grouped parts by keywords (Figure 1) and re-arrange them to create a “Foundation Document” [6, p.148]. This document is used to present several aspects of a persona.

It is very important to find a picture (photo or illustration), a name and a motto that identify each persona. This helped us to believe that they were real persons. After, the goals of the persona were listed (clear and short, e.g. using bullets to make it easier to go through them) and a description of the persona was also written. Everything should seem realistic and believable.

For a description of how to shape a persona look at [3, 4 and 6]. When writing the persona description and character use the data from the interviews as much as possible without trying to combine what everyone said.

A persona does not exist without scenarios that describe the persona activities and tools used (the type of scenario depends on what we are designing or prototyping [7]). We used persona and scenarios together to explain the prototype we designed. When we started to feel that both personas and scenarios could be real, the entire group members immediately got engaged with them, and the design decisions and ideas were much easier to make. [2, chap.11] explains how to create scenarios for personas, but [9] goes further discussing what personas should look like to be able to create good scenarios. CONCLUSIONS

This paper explains how the data collected from interviews was treated, and suggests a method to keep a reference to the original data. By applying this method, the interviews were easier to prepare and the data was straight forth to treat and analyse, leading to better personas than the ones created by other groups. The outcomes of the presented method can also be used to create a Persona “Foundation Document” like in [6, p.148]. The practical details presented in the paper, about creating personas, are missing in the literature, being of particular interest to students when using Personas as a tool to model the users. ACKNOWLEDGEMENTS

We would like to thank Erik Markensten and Henrik Artman who even with their busy schedule found time to answer our questions and for fruitful discussions about using personas while writing this article. Thanks also to Pedro Custódio who helped to proofread this document.

87

REFERENCES 1. Cockton, G. (2004): Value-centred HCI, Proc. 3rd NORDICHI 2004, ACM Press, p. 149-160. 2. Cooper, A. (1999): The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore The Sanity, Sams. 3. Cooper, A., Reimann, R. (2003): About Face 2.0: The Essentials of Interaction Design. Wiley, Chichester, NY, USA, 2003, chap. 5. 4. Goodwin, K. (2001): Perfecting Your Personas, www.cooper.com/newsletters/2001_07/perfecting_yo ur_personas.htm (last visited in November 2004). 5. Goodwin, K. (2002): Getting from Research to Personas: Harnessing the Power of Data, http://www.cooper.com/content/insights/newsletters/2 002_11/getting_from_research_to_personas.asp (last visited in November 2004). 6. Grudin, J., Pruitt, J. (2002): Personas, Participatory Design and Product Development: An Infrastructure for Engagement, Proc. PDC 2002. CPSR, 144-151. 7. Houde, S., Hill C. (1998): What do Prototypes Prototype?. In Handbook of Human Computer Interaction (2nd Ed.), M. Helander, T. Landauer, and P. Prabhu (eds.): Elsevier Science B. V.: Amsterdam, 1997. 8. Markensten, E., Artman, H. (2002): Procuring a Usable System Using Unemployed Personas. Proc. 3rd NORDICHI 2004, ACM Press, 2002, p.13-22. 9. Nielsen, L. (2002): From user to character – an investigation into user-descriptions in scenarios, Proc. DIS 2002, ACM Press, p.99-104. 10.Pruitt, J., Grudin, J. (2003): Personas: Practice and Theory, Proc. of the conference on Designing for user experiences, ACM Press, 2003, p.1-15. 11.Sinha, R. (2003): Persona Development for Information-rich Domains, Proc. CHI 2003, ACM Press, 2003, p.830-831.

88