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.