# Understanding Users Through Three Types of Personas

Lene Nielsen, Marta Larusdottir, Lars Bo Larsen

► To cite this version:

Lene Nielsen, Marta Larusdottir, Lars Bo Larsen. Understanding Users Through Three Types of Personas. 18th IFIP Conference on Human-Computer Interaction (INTERACT), Aug 2021, Bari, Italy. pp.330-348, 10.1007/978-3-030-85616-8_20. hal-04196842

HAL Id: hal-04196842

https://inria.hal.science/hal-04196842v1

Submitted on 5 Sep 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Understanding Users Through Three Types of Personas

Lene Nielsen<fnref n="1" />, Marta Larusdottir<fnref n="2" />, Lars Bo Larsen<fnref n="3" />

**Abstract.** Personas is a suggested method to extend IT professionals' understanding of users and users' needs. A common advantage expressed is that personas extend the IT professionals' empathy for the users, but a disadvantage is that personas are typically defined at the start of a software project and gradually are forgotten, since there is little reference to the personas through the software development project. In this paper we report experiences of coaching IT professionals in defining agile user stories based on personas, called: Persona User Stories (PUS). The aim of these workshops, was to extend the usage of personas and thereby extend the IT professionals' understanding of their users. In a research project with three companies, we coached teams of IT professionals in three-hour workshops with 76 participants in total. The workshops were conducted at each company using personas already defined by the IT professionals. The persona descriptions were based on three types of information: a) assumptions, b) secondary research, and c) data specific to a project. Our findings show that personas based on assumptions result in the participants questioning the description of the personas and having difficulties in understanding the personas. For making the persona user stories (PUS), the participants used themselves more often as a reference when working with the assumption based personas, than the participants using the other two types of personas.

**Keywords:** Personas, user stories, Persona User Stories, case study, workshops, IT professionals.

## 1 Introduction

Personas is a method that has been applied in the software industry for several years. One of the first to define the persona method was Alan Cooper [7] stating that personas are: "hypothetical archetypes of actual users" used during the software development process to represent the users, their needs and anticipated reactions to software being developed. Personas capture data in a form that enables empathy with different user groups [12, 22] and align user understandings internally in the organization [21]. In this paper we study how personas can support IT professionals in defining user needs by using personas when describing agile user stories.

<footnote n="1">¹IT University, Copenhagen, Denmark</footnote>

<footnote n="2">²Reykjavik University, Reykjavik, Iceland</footnote>

<footnote n="3">³Aalborg University, Aalborg, Denmark</footnote>

<footnote>lene@itu.dk</footnote>
No standard definition exists of how to describe personas, but usually the personas are described by a fictive name and a description of goals, interests and preferences [23]. The description may also include a photograph, some text about a one-day experience and descriptions of life circumstances. A common advantage described of using personas in software development is that personas extend the IT professionals' empathy for the users, but a disadvantage is that personas are typically defined at the start of a software project and are gradually forgotten, since there is little reference to the personas through the software development project.

Interviewing is the most utilized method for the data gathering. It is labor-intensive to conduct the interviews and to analyze the data. Moreover, the interviews scale poorly and are thus costly [31]. Others have criticized that personas are not used that much during the software development and therefore there is even less reason to take on this time-consuming task. A study on the usage of UCD methods shows that personas are not frequently used by IT professionals even though the methods is quite highly ranked as being useful [16].

Especially in agile software development, IT professionals often describe user needs by defining user stories or epics, a quite common development process in the software industry. It is common to describe epics or user stories in one sentence, such as “*As a [user role], I want to [do some task] to [achieve a goal]*”, which is the most common format [6]. There is no difference between the format of an epic and a user story. The difference is that an epic is more comprehensive than a user story and it can be broken down into multiple user stories, while a user story is a small unit that cannot be broken down [4].

To investigate if IT professionals benefit from using personas while defining user needs, we conducted three workshops in three large companies in Denmark. The workshops used personas developed in advance by each company to define user needs by defining agile user stories based on the personas, called Persona User Stories (PUS).

In this paper we focus on the utilization of the personas based on three different types of personas: 1) personas based on hypothesis/assumptions of users; 2) personas based on secondary research with little domain-specific information, and finally 3) personas based on large amounts of data that is shown in the persona description. We wish to investigate how the usage of different types of personas affects IT professionals when writing Persona User Stories. For the sake of understanding the context within which the research takes place, we begin the paper by introducing background literature on personas and personas in agile development.

## 2 Related Work on Personas

In this section we will introduce related work on personas. We will introduce work on usage of personas in agile software development. We conclude this section by introducing related work on the relation to data from users in persona descriptions, personas based on assumptions and personas based on data from users, as this is important for the particular case.
## 2.3 Personas in Agile Development

It is complicated to incorporate a user perspective in agile software development. Personas have been suggested as a way of getting an understanding of users into agile development. They have typically been used as an up-front design method before the coding in agile software projects, referred to as sprint 0 [3], the result is a high-level specification [4]. It has been suggested to incorporate personas into the later process of coding, e.g. Cleland-Huang et al. [5] propose to create personas where each persona description has user stories with architecturally significant concerns. Hussain et al. [15] describe how personas can help guide the customer representative in the agile method XP (Extreme Programming) to identify user stories. Gothelf and Seiden [11] propose, in the Lean UX process, to divide the persona development into three small steps starting with proto-personas based on assumptions and develop these further with research to validate the initial assumptions. To incorporate the personas in the existing agile framework, several authors have suggested using personas for writing user stories [3, 6, 11]. Winter et al. [34] suggest a three-step model from defining personas, defining the context of use, to writing persona-driven user stories accompanied by a visual sketch of the use context. Similarly, Hudson proposes [14] to write user stories that are inspired by UML. Finally, a combination of personas and context of use for acceptance criteria in agile requirements has been suggested by Sedano et al. [32]. Common for the studies of personas in use, and in the specific environment of agile development, is that the studies do not look at how different persona descriptions perform when in use. We thus want to look at if the type of personas have implications for the understanding and utilization of personas while defining user stories.

## 2.1 Data Gathering for Personas

Over the years different paradigms have evolved that all are related to how much and the type of data that personas should be created upon. The origin of the persona method emphasized that personas should be abstracted from data and have a clear relation to data, whether qualitative or quantitative or a mix hereof [7, 12, 22]. Most often, personas are created using mixed methods, starting with secondary research, where research data is reviewed and interpreted but not gathered, and later using both qualitative research (e.g. interviews) and quantitative research (e.g. surveys) to gather data directly from users [12, 29]. The data used in the persona descriptions can be either specific to the domain that is designed for or more general collected to have many purposes.

Technology has developed since the introduction of personas and today it is much easier to incorporate big data, such as social media data for the creation of personas [1]. The personas based on quantitative data provides new opportunities to generate personas from social media and algorithms and machine learning libraries have made it possible to generate and automate the development process. The advantages are that the data is statistically valid and can be frequently updated [29].

Lastly, new paradigms have emerged that do not emphasize a relation to data, such as co-created personas and personas based on assumptions. Co-created personas reflect the users’ daily lives as they are created by or together with the end users themselves [19]. In the next we will elaborate on personas based on assumptions.
## 2.2 Personas Based on Assumptions

The approach of using data was challenged with the arrival of methods such as assumption personas, ad hoc personas, and proto-personas [24, 26, 33]. Ad hoc personas [24], proto-personas [33], and provisional personas [10] are all hypothetical personas based on the design team's current assumptions about the user group. The assumptions are later to be tested through interactions with real users. The idea behind these sketches of personas is to make the assumptions explicit [11]. In the following, we coin assumption personas, ad hoc personas, provisional and proto-personas for 'assumption-based personas'. Assumption-based personas are, as the name suggests, based on the design team's assumptions and can be relatively easy to create. They are sketches of personas and give an overview of the team's suppositions and how these shape design decisions. They can be used to start the persona creation process [26]. Assumption-based personas are used when the time frame is tight [20, 27] or as a short-cut to being able to use methods such as scenarios [28]. They are often sketches, as illustrated by [11], and contain few selected information, such as a sketch of the persona, demographics, behavioral information, pain points and needs, and potential solutions [11]. Some development teams use them as an off-set for data-based personas [25, 32]. These personas can jump-start a persona process but have an inherent danger of not getting the real data. Companies might stick to their initial hypothesis, and they might build stereotypes that are never challenged with data [18].

In the following, we will distinguish between three types of personas. The first type is assumption-based (AB) personas, which are personas based on the design team's assumptions as mentioned above. The second type is personas based on secondary research, here called secondary research-based (SR) personas, and the third type is personas based on data explicitly gathered within a specific domain for a persona project, here called research-based (RB) personas. To our knowledge, no studies have reflected on what happens in the ideation phase when different types of data is reflected in the persona descriptions and if it affects the application of the persona method, in this case within user stories.

# 3 The Three Cases

In the study we performed three-hour long workshops in three large Danish companies (A, B and C) within shipping, insurance, and biotechnology. All the workshops were conducted by the same process. The aim of the workshops was to study if personas could be used to extend IT professionals' understanding of users by defining user stories. All the companies had predefined personas, which were of one of the following types in each company: A) Assumption-based (AB) personas, based on hypothesis/assumptions of users; B) Secondary-research (SR) personas based on secondary research with little domain-specific information, and C) Research-based (RB) personas, which were data-driven personas based on large amounts of data that is shown in the persona description. In the following we describe the participants, the personas used in each workshop, and the workshop structure.
## 3.1 The Participants

We performed three workshops, one in each company A, B and C, with a total of 76 participants. All companies used an agile development process and reported that they used Scrum with their own modifications. The contact persons at each company had responded to an open invitation sent to a large number of people working within business, development, UX, and management. The contact persons recruited participants at their company. Most participants knew of each other, but some had not worked together before. The participants were most familiar with those with the same role. The roles of each participant can be seen in Table 1.

<table><caption>Table 1: An Overview of the Participants' Roles</caption><thead><tr><th>Participant role</th><th>Company A<br>Shipping</th><th>Company B<br>Insurance</th><th>Company C<br>biotech</th></tr></thead><tbody><tr><td>Business</td><td>7</td><td>10</td><td>9</td></tr><tr><td>IT development</td><td>9</td><td>3</td><td>3</td></tr><tr><td>UX</td><td>5</td><td>4</td><td>5</td></tr><tr><td>Management</td><td>3</td><td>3</td><td>5</td></tr><tr><td>Unknown</td><td></td><td>10</td><td></td></tr><tr><td><em>Total</em></td><td>24</td><td>30</td><td>22</td></tr></tbody></table>

Table 1 provides an overview of the work areas of the participants in the three companies. The participants had different roles such as UX designer, developer, manager or business analyst (see Table 1). The participants were divided into groups of 4-6 members and each group was designed to have at least one participant from UX, business and agile development. The only deviation from this was company C where development is outsourced. Most of the participants were familiar with epics and user stories and could explain the concept to the other participants. As company C had outsourced development, the participants were less familiar with the concept of user stories and some groups struggled to understand what a user story is and the difference between an epic and a user story. The overview shows that the combination of participants' backgrounds are similar in the workshops in company B and C. However, in company A there were a higher number of people working within IT-development.

## 3.2 Persona Descriptions Used

All companies had newly developed personas that were presented to the participants at each workshop. All companies had developed the personas recently before the workshops. So most of the participants were new to the concept of defining personas and the persona descriptions used during the workshops. The companies had different numbers of personas. Company A had 2 assumption-based (AB) personas with a sketchy character; company B had 6 (SR) personas generated on secondary research with data not specific to the domain, while company C had 5 (RB) persona descriptions based on a large amount of qualitative and quantitative data that were visualized. An overview of the information in each type of the personas is given in Table 2.
<table><caption>Table 2: An overview of the Personas in Each Company</caption><thead><tr><th></th><th>Company A</th><th>Company B</th><th>Company C</th></tr></thead><tbody><tr><th>Number of personas</th><td>2</td><td>6</td><td>5</td></tr><tr><th>Domain</th><td>Shipping</td><td>Insurance</td><td>Biotech</td></tr><tr><th>Context</th><td>Based on hypothesis on customers</td><td>Based on internal secondary research of customers. No domain specific information</td><td>Based on the company's employees worldwide. Domain specific information</td></tr><tr><th>Content</th><td>Demographics Technology use Needs and motivation concerning the domain</td><td>Demographics Personality Lifestyle Technology use and specific digital experience Attitude towards data security</td><td>Demographics Workday and way of working Technology use Frustrations Goals Preferences</td></tr></tbody></table>

In the following we will explain the differences of the persona types used in the three companies.

### 3.2.1 Assumption-Based (AB) Personas - Company A

Company A had developed two assumption-based (AB) personas with a short text in bullet form. The assumptions were based on hypotheses on customers of company A. The content included demographics, general knowledge, technology use of the persona, the persona needs and his/her motivation. One persona description is given in Figure 1 (adjusted to keep anonymity).

<figure><img src="image_3.png" /><figcaption>Figure 1: One Persona Assumption Based Persona Description Used in Company A</figcaption></figure>
### 3.2.2 Secondary Research (SR) Based Personas - Company B

Company B had developed six customer personas based on secondary research (SR) of previously collected data for other purposes. Here after we refer to those personas as SR personas. One example of a persona in company B can be seen on Figure 2, (adjusted to keep the company's anonymity).

<figure><img src="image_4.png" /><figcaption>**Figure 2:** Persona Based on Secondary Research - Company B.</figcaption></figure>

The texts in the persona description were long and did not include attitude towards the specific domain of insurances. The content included demographics, personality, digital behavior, information channels and relation to the domain. Each persona was described on two pages.

### 3.2.3 Personas Based on Data Specific to the Domain - Company C

Company C had developed five employee personas based on large amounts of data specific to the task. Here after we refer to those personas as research based (RB) personas. One example can be seen in Figure 3, (adjusted to keep anonymity).

The information included visualizations of data. Beside the persona description, they had set up life-sized photostats of the personas in the office. The participants had seen the photo-stats, but not read the persona descriptions before the workshop. The content included demographics, workday, likely job roles, likely jobs, IT skills, frustrations, goals, and preferences. One of the personas can be seen on Figure 3 (amended to keep company anonymization).
<figure><img src="image_5.png" /><figcaption>**Figure 3:** Research Based Persona Used in Company C- Based on Domain Specifics</figcaption></figure>

### 3.3 The Conduction of the Workshops

The workshops lasted three hours and fell into two parts. In the first part, the participants were asked to write user stories based on two different personas, which in company B and C were chosen from the pool of personas. These personas were picked to be very different in needs and attitudes towards the current IT system. The reason for picking two different personas was to make participants aware that they had more than one segment of users. The user stories were based on epics specific to current IT systems and defined before the workshops by the experimenters and the contact person in each company.

The schedule for the workshops was: Firstly, the participants got introduced to what would happen during the day and to the concept of personas for half an hour, then they got introduced to the particular personas at the company for half an hour. After the introductions the participants were instructed to write user stories based on a predefined epic. The tasks were carried out group-wise, where the tables in the room was moved around to accommodate 4-5 persons groups. These were predefined by the contact persons to assure the different roles (see Table 1). An example is given in Figure 4.
<figure><img src="image_6.png" /><figcaption>**Figure 4:** The epic from the workshop with company A (shipping).</figcaption></figure>

The authors (who were also the facilitators of the workshops) gave a brief introduction to the concept of user stories. However, it was expected that the participants knew what a user story is or could be instructed by a developer, Scrum Master or Product Owner at the workshop. The participants had 15 minutes to write user stories for each of the two personas the team was handed. At the end of the workshop, a short plenary feedback session with discussions of the learnings was held. The participants provided user stories for both their appointed personas. In average, the group in company A and B wrote four stories per persona in the 15 minutes allotted. The groups in company C wrote, on average, three stories. This small variation might be explained in that the participants in company C had a harder time understanding the concept of epics and user stories and spent some time discussing what a user story is due to the lack of developers in the groups.

In the second part of the workshops, the participants were asked to write tasks to be used in a usability test with users. The tasks should be defined to evaluate the user stories created. The tasks were to be used during user testing of a prototype for achieving the user needs described in the user stories. This paper only reports from the first part of the workshops.

# 4 Method

In this section we will describe the data gathering and the data analysis. Data were gathered during the workshops. All group discussions during the group work and the plenary discussions during the workshops were audio-recorded and transcribed verbatim. Unfortunately, 2 group discussions were not recorded due to technical failures. The data collected are audio recordings of the group work sessions during the workshops, audio recorded comments from the plenary feedback sessions during the workshop and written documents that the participants delivered during the workshops. All in all, we have analyzed recordings from 13 group discussions (4 in company A and B, 5 in company C) lasting app. 30 minutes, and we report the findings in this paper. Similarly to Friess [9], we analyzed conversational turns, but we left out single words, such as OK and sounds that indicates agreement, disagreement or bewildering, such as Oh.

The 13 group discussion recordings lasted approximately seven hours and they were subsequently transcribed verbatim and have been analyzed in depth. The analysis started with open coding. To provide a stronger interpretive pattern, two researchers
coded the same group discussion and from that created the foundation for the thematic units [13]. We have eliminated jokes, discussions of work and colleagues not related to the subject and single words, such as confirmations. The themes identified are: understandings of contexts; understanding the task; reading the persona text aloud; design ideas; creating solutions; discussion of other services; discussions of user interactions; integration of facts into discussions; lacking data; references to own experiences; the persona in a scenario; comparing the two personas; interpretation of the persona. We have primarily focused on the themes "references to own experiences"; "lacking data" and "interpretation of the persona". The authors have translated all quotations from Danish.

# 5 Findings on Personas in Each Company

In the following we report the findings on the interpretations on each type of persona. In the quotes, the three types of personas are in the following named as: (AB) for assumption-based personas; (SR) for secondary research-based personas; and (RB) for research-based personas. The number, e.g. G1, identify the group, so conversations from group 1 on assumption-based personas are marked: (AB)-G1. If more than one participant is quoted, they are numbered as Participant 1 and Participant 2.

## 5.1 Company A - Assumption Based (AB) Personas

Analysis of discussions shows that the negotiations around (AB) personas take a point of departure in an older persona. In this specific case, the participants cannot get income and travel behavior to match and **create a meaning**. To comprehend the information they invent a specific lifestyle. The conversion was as follows:

Participant 1: "It doesn't really make sense that he travels more than twice a year and that he has a moderate income [since he is so old]?

Participant 2: "Then he prioritizes travelling a lot. Maybe he has a small apartment?" (AB)-G2.

Similarly, a participant from the same group, asks about the second persona:

"She travels by car to go on holidays, so she is probably driving to Germany and stuff like that, maybe Sweden?" (AB)-G2.

In the next quote, the participants try to narrow down the age of the persona's children as this is not mentioned in the description, where it is written she has two kids:

"Not that we can say how old the kids are. But I think also in, the kid... the kids are not 25, you mean." (AB)-G2.

These examples show that the participants do a lot of **interpretations** about the type of person that is described in the persona description.

One way of figuring out who the persona is, is to **refer to a type** of person rather than to the persona description, as seen in the next quotes from group 2:

Participant 1: "Yes, he is the type that wonders 'why doesn't it say that I have got a table at the window. [Table] number 63, why can't I just choose that?'" (AB)-G2.

And later in the conversation:
*Participant 1:* "But he is the type that doesn't have the latest browser version. He might not have the latest versions of different technologies."

*Participant 2:* "That's right. "

*Participant 3:* "He might still have Internet Explorer 8, because he is afraid of updating because it might cost money or something." (AB)-G2.

This conversion shows that both groups build up interpretations of who the user is, from guessing what type of person the persona is.

Participants had difficulties in understanding the context. One example is the following group discussion from group 3:

*Participant 1:* "But in the X restaurant you get free sodas, don't you?"

*Participant 2:* "No".

*Participant 3:* "It's 50kr. for the soda or something like that."

*Participant 1:* "I thought it was, what was it, a soft-drink machine?"

*Participant 2:* "But you can buy a buffet, including a drink." (AB)-G3.

In this case, the participants struggle to figure out the setting of which route the persona takes and with this, which ship she is on and the meals on a specific ship. They end up spending time discussing the exact flow of having sodas with meals.

For the assumption based persona, the participants draw on own experiences, in this case their parents, to guess if the solution fits the age group.

One example can be seen from this conversation in group 5:

*Participant 1:* "At this age, judging by my parents, they are all about: 'Oh, let's try this new steak, because the other one, we had 67 times'.(....)

*Participant 2:* "Maybe we shouldn't look too much on the age. Judging from my mom and dad - they're divorced and with their new partners. Dad likes to be very much in control, Mom likes to get out there and find something." (AB)-G5.

In summary the participants have to, in order to comprehend the information; invent information, interpretate the persona as a type, as they miss information, negotiate a context, and revert to draw on own experiences.

## 5.2 Company B - Secondary Research (SR) Personas

For the (SR) personas, the participants can relate to them, and one group feels that the female persona represents many customers to the company.

The group discuss a persona that has accepted not living together with her boyfriend, the information of how long the relationship has lasted and her attitude towards it, is not part of the persona description. To create a meaning, **they invent** a motivation. One participant states:

"She is just the type. They had a dream of living together, now 23 years have passed. 'We agree that this is fine as it is.' Why change something that isn't broke." (SR)-G4.

One way of figuring out who the persona is, is to **refer to a type** rather than to the persona description, as seen in the next quotes:

"Yes, she is the generation that is somewhat flighty" (SR)-G2.

In another group a participant remarks:

"I know she is a caricature. The quote is quite extreme: "I have never done anything wrong". No one would say that. But I think you can meet many, I am myself 42 years, many women here in [the company] that say this" (SR)-G5.
The participant also remarks:

"Overall, we have been pretty sensible in our lives, and we make good decisions. We are actually the same type" (SR)-G5.

Thus the participant is **validating information** with own experiences.

Participants showed signs of insecurity which was expressed by the participants as they **do not have data** on the personas:

"As it is now, we don't have, yes we know who Agnes is, but we don't have this kind of granulated data on her." (SR)-G4.

In summary, the participants invent information, refer to a type, validate information with own experiences, and show signs of lacking data. This occurred not as often as for the AB personas though.

## 5.3 Research Based (RB) Personas with Domain specific Data

The (RB) personas are created based on the company's own workforce, which might be easier to relate to. The participants in this workshop also try to figure out who the persona is by **referring to a type** of person rather than to the persona description. One participant remarks:

"Isn't she the type that would like to have a basic tool?" (RB)-G3.

A participant from group 2 says:

"I think that Roger has a goal that it should run smoothly. If anybody in his team needs to be up to speed, then I think he will help them." (RB)-G2.

In the case of the RB persona, there is no mentioning of job roles, and this leaves the participants frustrated, and they **negotiate a job role** for the persona, as it is seen in the three quotes from three different groups.

One participant in group 5 says:

"It doesn't say anything here? It says he is away from his desk, but what about his phone, does he use that? It doesn't say. And it doesn't say anything about security, you can't have your phone with you in production - isn't it right." (RB)-G5.

A participant in group 4 says:

"If you have to come up with examples. One that works in Quality, who spends part of the time in the office, but also part walking around the site to see if production runs correctly. And it could be lab work or production work." (RB)-G4.

Finally a conversion from group 3 shows that participants struggle with this:

*Participant 1:* "Yes, he is around."

*Participant 2:* "No, on the contrary, he works factory."

*Participant 3:* "Yes he is factory... maybe a lab..."

*Participant 1:* "Yes that way he is around, but he is not someone who travels."

*Participant 2:* "No, he does not sit in front of the computer all day. He might be at storage, then he is out and about." (RB)-G3.

One of the many reasons for introducing RB personas in the biotech company was to break with the company's previous understanding of end-users as defined by job roles. As the examples above show it is not an easy task.

To understand the persona in known terms, some participants negotiated a specific role for the persona. In the example below the participant insists on talking about a production worker, despite the persona description mentioning multiple possible job roles for the persona. The participant remarks:
"He is a production man. I find the photo to be misleading. He should have a white lab coat on. He should be another age. I have this image, when I read it, of boys in white lab coats. He doesn't look 36. He should have white clogs on." (RB)-G5.

To change the internal understanding of employees seems to demand more than an
introduction of personas.

The participants **draw on experiences** from their own family or colleague to guess if the solution fits the age group. In the first example, the persona is compared to the participant's nieces:

"Yes, I think it is one like Snap. What I really is puzzled about are my nieces, they take photos of their food all the time. What are they going to use that for? (...) My interpretation is, that he is in that category." (RB)-G5.

Another example of this is where some group members become aware of a shared implicit user that resembles one of the personas - and also many of their colleagues. One participant remarks:

"I think of Berit [a colleague] when I see her". (RB)-G5. The third example is from a comparison between the persona and many people from of the company: "What I want to say is, that I think that there are a lot of Susans [at our company] and I think that many of us have part of her in us. This, that we would like to see what happens and see the process, that's important. We don't like things where we can't see where we end." (RB)-G2.

Finally, the participants **compare own behavior** to the behavior of the personas,
thus validating the persona:

"I have some of that Irene. We have Teams in our department, and some of what Irene likes, is the deadlines." (RB)-G2.

To sum up, the participants refer to a type, negotiate a job role, draw on own experiences, and validate by comparing to own behavior.

**5.4 Summary of the Differences of the Personas in Each Company**

In summary we have seen that for the Assumption based (AB) personas, these do not resemble the participants and the participants revert to stereotypical descriptions and negotiations when writing the personas user stories (PUS). Additionally we saw that there was little design relevant information in the descriptions, so the participants needed to interpret the user needs for the persona.

Contrary to this, the secondary research based (SR) personas resemble the
participants, but they still have the tendency to revert to stereotypical descriptions and
negotiations. Additionally, there is little design relevant information in these persona
descriptions and we also saw that participants needed to interpret the user needs to
some extent.

For the research based (RB) personas the personas also resembled the participants
and there was more design relevant information in the descriptions, so the need for
interpreting and guessing was less at that company.
# 6 Comparing and Discussing the Findings

From the analysis, we report from the thematic units identified from the themes in this section. The thematic units that are reported here are: requests for more data, discussing of the context of use, the participants use of own experiences, and finally, how much the participants refer to the written descriptions.

## 6.1 Requesting More Data

The references to lacking data vary for the three personas and between the groups in the company. In general, the groups working with the assumption-based (AB) persona are much more insecure, and they more often express a request for specific data. In contrast, the groups working with the research-based (RB) persona do not request more data. Looking at the discussion where participants lack data, there are different reasons for missing data. The discussions happen either when the participants feel insecure about the type of data they have and/or when they find that relevant data is missing.

There is a clear difference between the personas research based personas (DR) and RB) and the personas based on assumptions (AB), as the participants, in the latter, more often express a lack of specific information. With this lack, they need to revert to other sources of information, such as their own experiences, as seen in the next thematic unit; *references to own experiences*.

## 6.2 Reference to Own Experiences

When making the user stories, the participants refer to themselves, to colleagues, to family, or to knowledge from other sources to understand the persona better. In order to understand the persona, the participants draw on their personal and general knowledge of people they find is like the persona and they use their cognitive ability to categorize people into fixed types based on previous meetings with people and their cultural background [17]. This is tied to a lack of information in the description. Again there is a noteworthy difference between (AB) personas and (SR) and (RB) personas. The groups with assumption-based (AB) personas more often revert to talking about their own experiences, family or friends.

Common for both (SR) and (RB) personas is a comparison to colleagues, as in the example below. This is to be expected for the (RB) personas as the use context is of internal software. The lack of information creates a need for drawing on other sources of information. This is unavoidable as not everything can be represented in the persona description. However, the less information the description carry, the more the participants have to rely on their own experiences with the risk of creating stereotypes, as it especially is seen in the case of discussing age-related issues.

## 6.3 Describing the Context

The persona description can describe the context of use that is *where* the system will be used, *what* the goals and the user needs are for the usage, and even *what* technology will be used. This description is seen in the secondary research based (SR) persona
where the context is in the home of the persona. It gets much more difficult to
understand the context in the persona description when the context is on a ship (AB
persona) or when the context is not clearly defined (RB persona).

The information about context, whether implicit or explicit, seems to play a role.
The context is needed for the specificity of the user story. To understand the persona,
the participants negotiate, with more or less success, where the use takes place. The
importance of context is especially required when the surroundings are out of the
ordinary (e.g. onboard a ship) or goes against an established way of looking at the
persona (e.g. differentiate between employees based on job roles).

Company C is a special case as the organizational change to understand employees not from job roles, but from user needs, is not easy and the participants tries to revert to their shared understandings, from before the change.

## 6.4 Further Discussions of the Findings

This study is the first to compare different types of personas based on their data. There might be differences between the organizations and the participants that muddle the results. Furthermore, as already stated, the participants from company C were not as familiar with user stories as company A and B. Thus, in the future more rigorous evaluation studies are needed that let the same set of participants work with the same task, but different sets of personas. Especially research on the difference between using assumptions-based personas and data-based personas is needed.

Few studies have looked into the layout of the personas [21, 30]. In this case, the layout of the personas varied and future studies could look into which role the layout plays in connection to the different forms of personas and their usefulness.

Creating a user story is creating a specific instance of the user needs for that particular persona. A scenario is defined as including the context where the use takes place [2, 25] The persona description can indicate the context where the interaction takes place. This indication is seen in the secondary research based (SR) persona where the context is in the home of the persona. It gets much more difficult when the context is on a ship (AB persona) or when the context is not clearly defined (RB persona). In these two cases, the participants struggle to create a context. From the assumption-based persona, most participants do not have enough knowledge of the setting of use as they have not visited a cruise ship and need to create a shared understanding of how a restaurant works on board.

Empathy is defined as a complex imaginative process that includes a simulation of another person's situated psychological states [8] this requires access to information where it is possible to simulate. In the examples above, missing information or when the story is not comprehensive, the participants' makes information up with the purpose of creating a comprehensive story. Empathy benefits IT professionals when trying to understand the users' needs. In our study we can see that it is easier for IT professionals to gain empathy for users, when the personas are detailed and based on rich data, like the RB personas (e.g. in Figure 3).

In summary, two conditions seem to influence how much the participants need to discuss and negotiate the persona in order to create a shared understanding: 1) if the persona resembles the participants, it is easier to understand and empathize with the persona 2) if there is more relevant information in the descriptions, it is easier to
understand who the persona is. Thus the less the persona resembles the participants and
the less design specific information, the more the participants revert to negotiations and
stereotypical descriptions.

7 Conclusion

To our knowledge, no studies have compared the usage of different types of persona
descriptions in industrial settings. This research contributes to an understanding of the
perception of personas based on varying levels of data richness. The study shows that
the foundational data have implications on the understanding and utilization of
 personas. The higher the data richness, the lesser the participants have to revert to their
own experiences and guesses, and the more they can find the answers from reading the
persona descriptions. However, it also shows that there is not much difference between
secondary research-based and research-based personas. Secondary research can be
considered as an easier way to create personas than collecting a large data sample while
assumption-based personas seem to be more problematic when in use.

The discussions also show that the utilization of personas benefits from group work as the implicit assumptions become explicit, and the group members have to align their understandings. Many authors have promoted personas not built on data, such as proto-personas [11, 33] – sketches that later can be refined with more data. The industrial workshops with practitioners show that there is a correlation with the richness of data behind the persona descriptions, the relevance of the data, and how much designers and developers are forced to rely on their own experiences and how often they collectively have to create imaginative user stories. Furthermore, it also shows how insecure the project participants become on the solution when there are no facts to support it.

To summarize we have seen that the less data enriched assumption-based (AB) personas, make the participants guess and refer to own experiences more than in the data-enriched personas, even though the participants align their assumptions through group work.

8 Acknowledgement

This research is supported by Infinit – Network for digital innovation and new
technology and Jeppe Emil Kjøller.

9. References

[1] An, J. et al. 2018. Imaginary people representing real numbers: Generating personas from online social media data. *ACM Transactions on the Web*. 12, 4 (2018). DOI:https://doi.org/10.1145/3265986.

[2] Aoyama, M. 2005. Persona-and-Scenario Based Requirements Engineering for Software Embedded in Digital Consumer Products. *13th IEEE International Conference on Requirements Engineering RE05* (2005).

[3] Brown, D. 2012. *Agile User Experience Design: A Practitioner's Guide to*
Making It Work.

[4] Chamberlain, S., Sharp, H., & Maiden, N. 2006. Towards a framework for integrating agile development and user-centred design. In *International Conference on Extreme Programming and Agile Processes in Software Engineering* (pp. 143-153). Springer, Berlin, Heidelberg.

[5] Cleland-Huang, J., Czauderna, A., & Keenan, E. 2013. A persona-based approach for exploring architecturally significant requirements in agile projects. In *International Working Conference on Requirements Engineering: Foundation for Software Quality* (pp. 18-33). Springer, Berlin, Heidelberg.

[6] Cohn, M. 2004. *User Stories Applied*. Pearson Education Incorporated.

[7] Cooper, A. 1999. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. (Vol. 2). Indianapolis: Sams. DOI:https://doi.org/10.1007/978-3-322-99786-9_1.

[8] Coplan, A. 2011. Understanding empathy: its features and effects.. *Empathy – philosophical and Psychological perspective*. A. Coplan and P. Goldie, eds. Oxford University Press.

[9] Friess, E. 2012. Personas and decision making in the design process: an ethnographic case study. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*, pp. 1209-1218.
DOI:https://doi.org/10.1145/2207676.2208572.

[10] Goodman, E. et al. 2013. Observing the User Experience: A Practitioner's Guide to User Research (Second Edition). *IEEE Transactions on Professional Communication*, 6(3), 260-261.

[11] Gothelf, J. and Seiden, J. 2013. *Lean UX: Applying lean principles to improve user experience*. O'Reilly Media, Inc.

[12] Grudin, J. and Pruitt, J. 2002. Personas, Participatory Design and Product Development: An Infrastructure for Engagement. Proceeding of the *PDC conference*, vol. 2, pp. 144-152.

[13] Guba, E.G. and Lincoln, Y.S. 1994. Competing paradigms in qualitative research. *Handbook of qualitative research*, 2(163-194), 105.

[14] Hudson, W. 2013. User stories don't help users. *Interactions*. 20, 6 November 2013 (2013), 50-53.

[15] Hussain, Z. et al. 2008. Agile user-centered design applied to a mobile multimedia streaming application. In *Symposium of the Austrian HCI and Usability Engineering Group* (pp. 313-330). Springer, Berlin, Heidelberg.

[16] Jia, Y., Larusdottir, M. K., & Cajander, Å. 2012. The usage of usability techniques in scrum projects. In *International Conference on Human-Centred Software Engineering* (pp. 331-341). Springer, Berlin, Heidelberg.

[17] Jung, H.Y. 1974. The Structures of the Life-World. By Alfred Schutz and Thomas Luckmann. Translated from the German by Richard M. Zaner and H. Tristram Engelhardt Jr., (Evanston, Illinois: Northwestern University Press, 1973. Pp. xxxvi, 335. $10.50.). *American Political Science Review*. (1974). DOI:https://doi.org/10.2307/1959185.

[18] Liikkanen, L.A. et al. 2014. Lean UX - The next generation of user-centered Agile development? *Proceedings of the NordiCHI 2014: The 8th Nordic Conference on Human-Computer Interaction: Fun, Fast, Foundational* (2014).

[19] Neate, T. et al. 2019. Co-Created Personas: Engaging and Empowering Users
with Diverse Needs Within the Design Process. *Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems - CHI '19* (New York, New York, USA, 2019), 1-12.

[20] Newton, K. and Riggs, M.J. 2016. Everybody's talking but who's listening? Hearing the user's voice above the noise, with content strategy and design thinking. *VALA2016: libraries, technology and the future*. (2016).

[21] Nielsen, L. et al. 2015. A template for design personas: Analysis of 47 persona descriptions from Danish industries and organizations. *International Journal of Sociotechnology and Knowledge Development*. 7, 1 (Jan. 2015), 45-61. DOI:https://doi.org/10.4018/ijskd.2015010104.

[22] Nielsen, L. 2004. *Engaging Personas and Narrative Scenarios*. PhD series, 17, Copenhagen Business School.

[23] Nielsen, L. 2019. Personas - User Focused Design. (2019). DOI:https://doi.org/10.1007/978-1-4471-7427-1.

[24] Norman, D. 2004. Ad-Hoc Personas & Empathetic Focus. *Jnd.Org*. (2004).

[25] Oderkirk, E. and Jung, K. 2015. From connect-exchange to ConnectX. (2015).

[26] Pruitt, J. and Adlin, T. 2006. *The Persona Lifecycle: Keeping People in Mind Throughout Product Design*. Morgan Kaufmann.

[27] Bhattarai, R., Joyce, G., & Dutta, S. 2016. Information security application design: understanding your users. In *International Conference on Human Aspects of Information Security, Privacy, and Trust* (pp. 103-113). Springer, Cham.

[28] Rooksby, J. and Dimitrov, K. 2017. Trustless Education? A Blockchain System for University Grades. *New Value Transactions Understanding and Designing for Distributed Autonomous Organisations Workshop at DIS 2017*. (2017).

[29] Salminen, J. et al. 2020. A Literature Review of Quantitative Persona Creation. *Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems* (New York, NY, USA, Apr. 2020), 1-14.

[30] Salminen, J. et al. 2020. A Template for Data-Driven Personas: Analyzing 31 Quantitatively Oriented Persona Profiles. *Human Interface and the Management of Information. Designing Information* (Cham, 2020), 125-144.

[31] Salminen, J., Jansen, B. J., An, J., Kwak, H., & Jung, S. G. 2019. Automatic persona generation for online content creators: Conceptual rationale and a research agenda. In *Personas-User focused design* (pp. 135-160). Springer, London.

[32] Sedano, T. et al. 2019. The product backlog. *Proceedings of the 41st International Conference on Software Engineering; ICSE'19* (2019).

[33] Using Proto-Personas for Executive Alignment: 2012. https://uxmag.com/articles/using-proto-personas-for-executive-alignment.

[34] Winter, D. et al. 2012. Persona driven agile development Build up a vision with personas, sketches and persona driven user stories. *Iberian Conference on Information Systems and Technologies (CISTI)*. (2012).