Keywords

1 Introduction

Personas are “hypothetical archetypes of actual users through which designers can develop a precise description of [the] user and what he wishes to accomplish” (Cooper 2004). Numerous designers build personas for projects on user interfaces because they think they will help them to focus on the users and make better design decisions, so they see personas as an effective tool to bring plus-value to their work. Yet, our own professional practice and observations in the field over the years reveal that there are problems and disappointments with personas, which reflect through the sub-use, the misuse, or sometimes the abandonment of personas, and the negative perception of personas. In our opinion the difficulties with personas on the ground deserve more attention if we want to improve their use and make it a more powerful tool for design. So, in this study, we collected data with several practitioners directly involved in the creation and use of personas in different domains, with the goal to understand their successes, failures, and challenges, and draw lessons for a better use. Before presenting our study, let’s examine some results from the literature on personas.

2 Related Work

In this section we address four main aspects of personas: the benefits, the creation process, the challenges, and the Reasons of failures.

Benefits. Personas facilitate the communication within the teams [15], by providing a common understanding of who the users are and what their goals are. They help to generate and select the best design ideas [2]. They also challenge incorrect organizational assumptions about the users, help to give stronger consumer focus and target the most important consumer segments [4, 5, 13, 15, 16, 19]. Some authors mention that personas can help to create empathy towards the users. For example, putting a human face on the generic user creates this empathy [2, 10]. Personas are also useful for surrogate user testing, evaluate new features, weigh business decisions, conduct task analysis, define use cases, write customer service scripts, facilitate analysis, design, implementation and diffusion, reduce the need to add real users during the design process, and allow the development team to work at a distance [1, 2, 13, 15, 18, 21]. Personas can also be helpful for the development of simulation and training systems, and for making data anonymous.

The Creation Process. Cooper’s early personas were rough sketches, but over time his method evolved to include interviews or ethnographic data collection methods to create more detailed characters [18]. In most cases, personas are synthesized from a series of ethnographic interviews with real people and then presented in one or two page descriptions that contain information such as behavior, goals, skills, environment, and some fictional details [6, 11]. For each product or set of tools, a small set of personas is created, in which one persona is the primary focus for the design.

There are several techniques for creating personas. Adlin & Pruitt [1] propose a six-step process organized in two phases: conception and gestation. They also propose a four-step process which only takes a couple of hours when designers are facing important time or budget constraints. Goodwin [12] proposes a nine-step process, which is based on real data. Interestingly enough, the author distinguishes different kinds of user goals (basic human goals, life goals, end goals, experience goals) and defines primary (the best design target) and secondary personas. Nielsen [17] proposes a ten-step approach, which contains four main parts: data collection and data analysis, persona description, scenarios for problem analysis and idea development, and acceptance of the organization and involvement of the design team. It is the first one to introduce the idea of updating the personas. These techniques provide good guidelines to designers. However, they propose a long process that not all companies could afford, or a short process that is not based on real data. The long process addresses the common questions about the creation of personas, but all along the process the designer needs competence and the ability to read the context correctly to make the best decisions (e.g., Develop the persona description, Decide about the final number of personas).

The Challenges of Using Personas. Pruitt & Grudin [19] faced many challenges to create and use personas. Their first project with personas was based on marketing data and did not have much support from the company. In the second project, they needed to involve many more people to have the personas done and they also needed to do a massive campaign to communicate the personas. Dotan et al. [8] had to make extra effort to convince the stakeholders about the use of the personas. Christopher & Blandford [7] encountered some challenges such as a lack of context, the difficulty to differentiate similar personas with different needs, and the difficulty to validate the personas. In the first project of Rönkkö [20], personas were not so important compared to other design aspects, in the second project, they were mainly used as a political tool, and in the third project, the relation between investing in personas efforts and their usefulness was questioned. Some designers resist personas because they are fictional, they can lead to a misunderstanding of who are the real users, and it is not easy to prove that personas are accurate [10, 14, 15]. Many authors also mention the risk of creating stereotypes when creating personas [7, 9, 10, 17–19, 22]. Persona use may raise socio-political issues because each of them has attributes such as age, race, revenue, preferences, etc. [19]. Different levels of trust can affect the use of personas because it is not always clear who organizes and reconciles persona with other data and who interprets them [1, 3]. Furthermore, designers prefer to work with real people rather than with personas [8, 15, 20]. Some authors believe that people need to buy-into the personas and get to know them if they are expected to achieve their goals [8]. Therefore, the designers have to commit themselves and trust in the personas, otherwise it is most likely they will not fully use them.

Failures with Personas. Even well developed personas can result in little or no focus on users in the development process. Moreover, poorly developed personas can keep the development team from investing in other UCD techniques or other efforts that improve product quality. Adlin & Pruitt [1] and Pruit & Grudin [19] mention five reasons that can make the use of personas a failure: (1) The effort was not accepted or supported by the leadership team; (2) The personas were not credible and not associated with methodological rigor and data; (3) The personas were poorly communicated; (4) The product design and development team employing personas did not understand how to use them; (5) The projects had little or no high-level support (not enough people to create and support them and no investment in personas’ communication).

3 Methodology

This section on the methodology of our study covers three topics: the participants, the interviews, and the data analysis process.

Participants. Sixteen practitioners in user interface design, aged from 20 to 65 years, female (N = 8) and male (N = 8), from Canada (N = 7) and the United States (N = 8), participated in the study. They were recruited via LinkedinFootnote 1 or personal contacts of the two authors of this paper, and thus formed a convenience sample. The main criteria to participate in the study were to be a user interface designer and have previous experience in creating and using personas in either a small, medium or large company. Participants were working for companies that developed software in different fields: database, engineering, workforce management, insurance, banking, marketing, healthcare and consultancy. Eleven had experienced working in small companies (1–200 employees), 5 in medium-size companies (201–500), and 15 in large companies (500 employees and more) (N.B.: since some participants have experience in companies of different sizes, the total is superior to 16). In terms of project, nine participants have been involved in more than five projects with personas, and seven have been involved in less than four projects with personas. The participants did not receive any financial compensation for their participation in the study.

Among the 16 participants, 10 were Interaction designers and 6 were Researchers. During the interview, the participants described their role and if their job tasks were more related to Interaction Design, it means being responsible to create the interface, or to Researcher, it means developing research to understand the users and their needs. Among the Interaction designers, three had leadership positions; three had more than 10 years of experience with personas. Among the Researchers, four had leadership positions; four had more than 10 years of experience with personas.

The participants’ educational backgrounds were very diversified including industrial design, computer science, information science, human-computer interaction, and industrial engineering. Eleven had a Master’s degree in Human Factors.

We classified the participants from their attitudes towards personas, as documented in [15]. We have Persona Champions (fully support the use of personas and are enthusiastic about it - 8 participants), Persona Moderates (focus on the user information and are more moderate about their overall impression about personas - 6 participants), and Persona Pessimist (they may use personas, but they don’t really recommend personas - 2 participants).

In terms of training, the participants formed two groups: those who received a long and specific training on personas (more than two days and dedicated to building personas): it includes three participants, all of them were champions; those who only received a short training on personas (a training limited to what they have learned during their Bachelor’s or Master’s Degree – generally a few hours). The knowledge about personas of this last group is also based on work experience with personas. This group includes 13 participants, five of them were champions, six were moderate and two are pessimists.

Interview. Each participant took part to a semi-structured individual interview during about an hour, through the software GoToMeetingFootnote 2. The first part of the interview was to collect data on the projects of interface design that used personas and wherein the participant was involved (duration: 5–10 min). The second part of the interview was to cover three aspects of personas: the construction, the use, and the effects on the design of interface design (duration: 30–45 min). Participants were asked to report their own activities with personas and also aspects they witnessed with colleagues about the creation and use of personas. The interviews were scheduled according to the best time for the interviewee, they were conducted from September to November 2015, and they were recorded via GoToMeeting. They were registered and transcribed (approximately three hours per interview).

Data Analysis. The transcriptions of the interviews were imported into the qualitative data analysis software Atlas.tiFootnote 3. Then, all the answers were tagged with codes. In total, 301 codes were created by the researchers. For example, in one paragraph, the researchers could identify that the participant gave answers on different topics (e.g., methods used to collect data on personas, validation, use of personas, problems encountered, etc.) which created many codes. Another participant would give the same answer, but in different parts of the interview. The codes helped to identify the common answers from different participants on the same topic. Once the codes were created, the networks between the codes and participants were created. The results focused on two main points: the participants’ perception of how they created and how they used personas.

4 Results

The results cover three topics: the creation of personas, the use of personas, and the evaluation of the impact and the satisfaction towards personas.

4.1 Creation of Personas

The Creation Process. Fourteen participants explained that the process of creating personas starts with the collection of data (mainly by interviewing the target users). Then they compile the data by identifying the common attributes. Once the personas are created, they validate them. Finally, they make a presentation to the team who will use the personas.

Personas Based on Real Data and Aligned with Business Strategy. Most of the participants asserted they start the process of creating personas by interviewing the target users, as personas should be based on real data. However, some participants mentioned that in situations where there is not enough budget or time (because interviews are very time consuming) or it is a new project, it is necessary to find a shortcut. Yet, 12 participants mentioned that they would not use personas if they knew they were not based on real data. Most likely, other stakeholders could be even more hesitant. Another reason why personas should be based on real data is that designers can defend them more easily and avoid stereotypes. For instance, in case a manager has a different opinion about the personas descriptions, the data supporting the persona can be used as a proof that the personas represent real users. The participants also mentioned the importance of having personas aligned with the business strategy. It increases the chance that the stakeholders will accept these personas.

Personas Created Through Brainstorming. Two participants, who are champions, mentioned that personas could be created through brainstorming and that these personas could be validated afterwards. When creating personas under severe budget or time constraints, three participants (P10 and P13 are champions, P15 is moderate) suggest to use assumption personas. P10 (champion, has more than 10 years of experience with personas, has a Master’s degree and specific training on Personas) mentioned that it is fine to create personas through brainstorming, but after it is necessary to validate them to reflect the reality. P12 (same profile as P10) explains that especially in consultancy, it is common to use brainstorming to create personas, and after validate them with the stakeholders to make sure they are representative of their customers.

How Long It Takes. Seven participants assert that the process of creating persona varies depending on the project. Important factors which impact on the time to create personas are the time to find people to participate in the interviews, to conduct the interviews, to compile the data and to write the report, the quantity of people involved and the time allocated for research. Four participants answered that it takes more than a month and five participants answered that it takes less than a month.

Who Is Involved in the Creation of Personas. To build personas, all the participants believe that it is important to involve the designers (N = 16) and the Product Managers/Owners (N = 8). Product Owners or Project Managers are people mainly responsible for the project/product and they take decisions about which direction the project/product should take in terms of budget, requirements, priorities, etc. Five participants believe that the whole team should be involved in the process because it facilitates the communication and reduces resistance.

How to Collect Data. To collect data for building personas, the participants mainly referred to interviews (N = 8), pools of users (N = 5), surveys (N = 4), the marketing department of the company (N = 3), and some other methods.

How Many People to Interview. According to the participants (N = 12), the average number of people to interview was 20 with a minimum of 8 and a maximum of 90. Some participants (N = 4) reuse the pool of users from other projects.

Marketing Data. Five participants use marketing data to build personas. These data usually include information about consumers such as demographics and behaviours. However, three participants do not recommend the use of such data because the person who uses the product is not necessarily the one who buys it.

Project-Based Personas. Two participants believe that personas should actually be developed by project, instead of a set of personas for multiple products. Also, if it happens that a persona is related to several projects, then it would be fine to reuse it.

Stretch Personas. Twelve participants experienced to be in a project where they stretched a persona, i.e. use a persona that was originally created for another project and apply it to another project. They believed it was a way to reduce the cost and time to create a new persona and these personas have some items in their description that could also be beneficial to the other project. Two participants would not stretch personas or they would do so depending on the situation.

Data Collection and Personas’ Description. When collecting data to build personas, participants ask about the overall demographics (N = 4), followed by the experience level (N = 4), the tasks to execute (N = 3), and the educational level (N = 2). During the interviews 10 participants mentioned what should and should not be included in the personas descriptions. The main items to be included in the personas description were: Big pain points (N = 9), Information related to work (N = 7), Demographics (N = 6), Scenarios (N = 5), and Tasks (N = 5). Items that should not be included, unless they are clearly relevant for a specific project, are extra information such as hobbies, weekend activities, whether the persona has pet or not, and demographics. Adding too much information brings the risk of having personas considered irrelevant by stakeholders and designers. Eleven participants mentioned that they add extra information to personas even if it is not based on real data, and four don’t. Adding extra information such as emotions that the persona will feel when using the product, is controversial among the participants. The majority of them would add extra information as a way to give the persona some personification and make it more engaging. Other participants mentioned that they would not add extra information, or if they would do, it should be minimal as there is a risk of wrong interpretation, especially if not based on real data.

Persona Name. All the participants use name in the personas descriptions. However, one participant (P11 - pessimist, has less than 10 years of experience in the field and with personas and has Master’s degree) feels like adding a name to persona can be more distracting than useful.

Persona Photo. Fourteen participants also appreciated the use of photo in the personas descriptions and among them, two participants believe that it is very important on the condition that the photos are well selected because they help to personalize the personas. Two participants (P11 - pessimist, P14 - champion) believe that photos are distracting and lead to useless discussions because they could carry stereotypes.

Methods Combined with Personas. Once the data on personas are collected, some participants use affinity diagram (N = 6), task analysis (N = 4) and scenarios (N = 3) to create the personas. The affinity diagram is mainly to organize the data and group the users by user categories. The tasks analysis is useful to describe the tasks and subtasks the user will execute to achieve his/her goals by using the interface and the scenarios help to give better context of use and make richer descriptions.

How Many Personas Are Created per Project. Nine participants reported that they created less than five personas per project, five participants created more than five personas per project (between 5 and 12) and two participants did not answer. Three participants shared their concerns about the number of personas to create, and one participant commented that in a company he worked for, there were so many personas that they became distracting.

Validating Personas. Fifteen participants validated their personas. The way they do it can vary: with customers (N = 6), owners/stakeholders (N = 3), and colleagues/team (N = 3). To validate, most of the participants refer to interviews and user testing. Some of the participants recruit users for user testing based on the personas profile.

Presenting Personas. Once personas are validated and ready to be used, 15 participants made some sort of presentation to the team, especially involving product owners (N = 7), developers (N = 6), and executives (N = 5).

4.2 Use of Personas

Focus on the User. Twelve participants use personas because they think they help to focus on the user. Two participants believe that designers are already user centered, so personas are not necessary for that.

Other Reasons to Use Personas. Nine participants believe that the personas can change the way they work, especially if they are used at the beginning of the project because they serve as a guide, as a reference, they give inspiration to generate ideas. Participants also use personas to educate the stakeholders about the users. Eight participants mentioned that personas are important to help to scope the project by defining if a feature should be added or removed from the product. However, one participant disagrees with the fact that personas can contribute to design decisions because they are too generic and don’t provide enough details to help with this kind of decision. Eight participants think that personas are useful for all kinds of projects.

How the Creation Process can Affect the Use of Personas. All the participants said they would trust in the personas even though they would not be involved in their creation, on the condition that they knew the personas were based on real data and what process was used. Two participants also mentioned that the qualification of who did the personas would affect their level of trust. Moreover, some believe that interaction designers could benefit more of the personas if they could participate in their creation.

Update Personas. In case of re-using personas for the same project or a different one, 11 participants mentioned the importance of keeping the personas updated. One of the reasons why designers would not use personas is the fact that they are outdated; since situations change and the context changes, personas need to reflect the new reality.

Personas vs. Real Users. Most of the participants mentioned that they prefer to refer to real people than personas. Two participants (champions) mentioned that it depends on the situation, maybe at the beginning of the project they would refer to personas, but later, it is important to contact real users, do some user testing to validate the design.

Communication. All participants agree that personas are an important tool to communicate and give a common understanding of the persons they will design for. According to the results, the people who use personas are designers, product managers/owners, developers and marketers. However, some participants say that developers and product managers use personas whereas some say they don’t. In daily communication about personas, most of the participants mentioned to use posters (N = 11), webpages (N = 7), flyers (N = 3) and cut outs (N = 3) (The cut outs are like big posters in the format of a real person). Four participants have experienced to play the role of personas. Yet, some of the participants (N = 4) who have not experienced to play the role of a persona think that it could be an interesting approach to present personas to the team, as it can help to create empathy. An interesting aspect about the use of the cut outs is that three participants who talked about them said that they can be scary sometimes.

Personas Based on Fake Data. Four participants said they would believe in personas even though they were not based on any research. On the other hand, 12 participants said they would not use these personas. For two participants, personas can be distracting because some stakeholders would pay more attention to small details, such as name and photo’s choice than the actual design problem that needs to be solved.

Personas May be Too Generic. Five participants referred to the fact that personas can be too generic, with not enough information, consequently they would not help in the design process. One participant pointed out that some designers don’t necessarily know how to use personas. Sometimes it is only the name, but not the personas description. Ten participants agreed that personas are not the tool to validate the design because they do not provide the proper the level of detail to review the design.

Personas Can Lead to Wrong Design Decisions. Four participants said that when personas are not well based, do not include enough information, they could lead to wrong design solutions. Seven participants mentioned the risk of stereotype when using personas. There is risk of interpretation of the personas meaning, therefore some participants highlight the importance of basing the personas on research.

The Lack of Support. Seven participants mentioned that they were somehow discouraged to build personas, as other people in the company would not believe in personas and would not offer appropriate support.

4.3 Evaluation of the Impact and Satisfaction About Personas

Evaluate the Impact on Design. Eight participants found difficult to explain how it would be possible to evaluate the impact of using personas in their projects in terms of numbers, or they could not tell how would be a project with or without personas. Five participants mentioned that they could evaluate the impact of personas as they believe personas improve the design and if the rest of the team adopts them.

Satisfaction About Personas. Even though eight participants mentioned that it is difficult to measure the impact of personas on design, most of them said they were satisfied with the personas they created.

5 Conclusion

This interview-based study showed the points of view of 16 experienced practitioners in the field of user interface design on their practice about the creation and use of personas, and the challenges they faced with personas. Our observations are about four principal issues that need improvements for a better use of personas. First: The practitioners involved in our study received different trainings about personas, they have different levels of knowledge and experience with this technique, and they operate in different work contexts (e.g., small, medium-size and large companies) with different constraints of time and budget. So, despite several common opinions, it is not surprising to see different attitudes and standpoints about specific issues of personas. Some standardized training program (with content, duration, readings, exercises,…) would be welcome to guide the trainers and improve the general level of knowledge on personas. Second: there are several techniques to create personas and at first sight, they have enviable qualities: they are detailed, well explained, freely available, and trustable since they are proposed by well-established authors. Yet they are not fully put into practice, and their application requires much competence and judgment from the professionals who attempt to use them because they have to deal with open questions and the specific contexts of their projects and their organizations. The following activities are good examples of that: Collect (relevant and sufficient) data on the users, develop the persona description (how much extra information?), validate, decide about the final number of personas, align the personas with the business value. Third: the practitioners have difficulty to evaluate the impact of the use of personas on design projects in terms of numbers. So they may lack arguments to convince colleagues or the hierarchy to adopt personas and to provide adequate support to create and use personas. This is a promising avenue for the research community. Fourth: once the personas are created, they should be fully exploited during the different phases of the project and their use should be well coordinated with the use of real users. Our study revealed that most designers prefer to use real users. Actually there is room for both personas and real users in projects because they satisfy different needs. Research results show that personas help designers to select functionalities and qualities of their products, and it is clear that design validation should be done with real users through usability tests. The contribution and advantages of adopting real users and personas should be clarified for each phase of the project.