New white paper on international user studies

Articleed January 30th, 2015 | Lene Nielsen | Personas (DK)Personas (UK).International user studies: How companies collect and present data about users on international markets

Download the report here (mangler Report_International-user-studies-20141.pdf)

Abstract:

In this report, we present the results of a research project about international user studies.The project has been carried out by researchers from the Center for Persona Research and –Application, The IT University in Copenhagen and the Department of Learning and Philosophy, Aalborg University.Based on a qualitative interview study with 15 user researchers from 11 different companies, we have investigated how companies collect and present data about users on international marketsCompanies do not collect data about end users in all the countries/regions they operate in.Instead, they focus on a few strategic markets. Key findings are:

  • Companies do not collect data about end users in all the countries/regions they operate in. Instead, they focus on a few strategic markets.
  • International user studies tend to be large-scale studies that involve the effort of many both internal and external/local human resources. The studies typically cover 2-4 countries/regions and many end users in each country/region.
  • The preferred data collection method is . If possible, user researchers choose to go to the field themselves and gain rich insights and to control the data collection process.
  • The preferred data collection method is
  • The main insights companies gain from international user studies are (1) that there are many similarities among end users across nationalities and (2) that it often is more important to focus on and take differences in market conditions into account than national culture per se.
  • Companies are in the process of finding out how to best present the insights about their international end users to their employees. However, so far, no best practice for incorporating both national cultural differences and cross-cultural similarities into personadescriptions, segmentations, etc. has been found.

Chapter about Personas on InteractionDesign.org

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

Read more at: http://interaction-design.org/encyclopedia/personas.html

The use of personas in Danish companies part 3

Changes and similarities in the application of the method

Even though this survey was done as independent research with interviews in 12 core companies, it is interesting to compare with the previous study done in 2009 to see if there are changes in the application of the method

Before doing so it is important to stress that the surveys are different in focus, they have different questionnaires, and the previous survey did not include questions on personas in an international perspective.

More companies use personas

Comparing the surveys it is evident that more companies have used the method for a longer period of time. Still most common is to have used the method between one to four years, but at present more companies have used the method as long as up till ten years.

In the 2013 survey all interviewed companies have participated in developing personas this is different from the previous survey as here more companies had personas entirely developed by consultancies. In the 2013 survey some companies had consultancies or business partners help them in the personas development process, but they had all partaken in the process or done the entire work in-house.

It spreads in ever-widening circles

A new trend in using personas is a chance in the companies systems developing method and more mention that they started using personas when they began to develop using agile methods. Common in the surveys are that most interviewed mentions positive experiences from their own network as the reason why they started using the method.

Level of satisfaction

There is no difference in how satisfied the companies are in using the method and the benefits the method provides in the different surveys. The mentioned benefits are that it provides a common language to describe the users and their needs. Only one disadvantage is mentioned and that is that the method is expensive and time consuming.

Challenges 

The challenges differ amongst the two studies: in 2009 the main challenge was to make the method visible in the organisation. This seems no longer to be a problem some companies even report that they have difficulties in keeping up with the organisation’s demand for personas. Even though it was difficult to make the method visible in 2009 personas were mainly positively received. In 2013 it is no longer a problem to create awareness and focus on the method, but it happens that it is met with resistance from either management or colleagues.

The Use of Personas in Danish Companies – 2012/13 (Part 1)

HOW DANISH COMPANIES APPLY PERSONAS

part 1

March 2013

Introduction

This report is based on a project initiated and financed by Infinit – the IT Innovation Network.

The report is based on 18 interviews with 28 participants from 13 companies, obtained from December 2012 until January 2013.

The aim of the project is to investigate how personas are established, communicated, used, and maintained in Danish companies, and, from the survey, to extract recommendations on how to develop, design, and use personas.

The company experiences will be addressed from two perspectives: with a focus on how personas are developed and maintained, and on how and to which purpose they are used.

Personas are descriptions on fictitious users that are used for design. The descriptions are based on data on end users of a given product. A set of personas normally consists of 2 to 6 descriptions. Within a design process personas are used to get ideas of use and use situation and to describe the possible use of a new product. These descriptions may vary from elaborate narratives to use cases or early descriptions of prototypes. In this report narratives, use cases, and prototypes will be referred to as scenarios.

Lene Nielsen, Associate Professor at the IT University, Copenhagen (ITU) and Research Assistant Kira Storgaard Nielsen, ITU.

Recommendations

The following recommendations are based on the interviews and the participants’ experiences of when the personas method is a success.

Thorough data gives credibility
There is a tendency towards that a thorough qualitative data material is convincing. At the same time the probability that the method will resonate with a larger part of a company’s employees is greater if there is reference to thorough quantitative data.

Have support in the organization from both employees and management
To succeed with personas, it is necessary to have support from both project participants and management. Furthermore, to not prevent resistance against the method, it is necessary to consider how the persona method is to be disseminated – it should from the beginning of a project be considered how project participants should use the personas and how a positive attitude towards the method can be created.

Consider which tasks the personas have to solve
It is a recurring theme in the interviews that personas help project teams to create a shared understanding of the end users and to create a shared language for describing the end users. However, in order for the persona method to be successful it is important that the project team accomplish more than the understanding of end-users. It is therefore advisable already from the outset of a project to consider to which purpose and for which specific tasks the personas are created.

The method is described as a success when:

  • The personas become a design tool
  • The persona descriptions can be used to create scenarios
  • Personas are used directly in the developing processes e.g. for design or sales.

Separate persona and scenarios
Even though personas are first fully successful when they can be used as design tools and to create scenarios, the method seems to function best when there is a strict distinction between personas and scenarios. If the persona description and the scenarios are too intertwined the description is locked to the specific situation described. This makes it complicated to adapt the persona description to new scenarios.

The descriptions should enable empathy
Personas are successful when they can be perceived with empathy, e.g. when the employees refer to the persona descriptions almost as people they know. This is not the same as saying that it is necessary for the personas description to gain sympathy. But rather that it is necessary for the employees to feel a wish to develop for the personas. Even joking about personas creates a focus and makes it clear to the developers that their users are different from themselves e.g. the personas’ level of IT proficiency.

Make the persona descriptions visibly different
This can be done by means of color-coding, pictures, tag lines etc.

Example of tag line from Aarhus Library: ”Expectant user/quality-conscious”. See all descriptions at

http://www.aakb.dk/files/att/slipbrugerneloes_personas.pdf

The persona method should be incorporated as part of the toolbox
In the interviews it is described how personas are ‘in the back of the head’, instead personas should be an internalized part of the company’s method toolbox.

Share knowledge about personas in the organization
Organize way to share knowledge in order for the persona method to be visible in the projects – and not just located in the individual project participant’s memory.

The study shows that the personas are often linked to, used, and understood by individual employees rather than shared among the whole company. This might result in lesser value and that knowledge disappears if an employee leaves.

Keep the method alive
Consider how to maintain the personas and make them live. This can be done by e.g. hanging persona posters at visible places.

Summary

Personas are used for a multiple of purposes and to solve many different types of problems. They are used for product design, IT-development, communication, and marketing. The method is also used in projects with a variation in length, both weeklong projects and projects that span over several years.

The interviewed perceive the persona method as well established in their companies and the persona descriptions as something that sits in the back of the head is articulated in several interviews.

There is a span between how this foundation of the method is carried out e.g. in how often the method is used and how standardised the method is. The method is mainly perceived as one tool among many and most companies have an ad hoc approach to the development and use of personas.

Some companies experience resistance towards the method. From the employees perspective this often stems from unclear strategic decisions. From management the resistance stems from insecurity in the validity concerning qualitative methods. From this last issue it can be concluded that quantitative data has higher impact than qualitative data and is considered of more value.

There is no connection between the amount and depth of the data upon which the personas are grounded and how satisfied the companies are when using the persona descriptions. There is a tendency towards that the companies with little data are less satisfied with the method than those who have an extensive data material and – more surprisingly – less satisfied than those who have created the persona descriptions without data. This might be explained as a consequence of that those with a narrow data set are confronted with what they don’t know and that they do not find answers to their questions in the material.

Companies that operate on a global market use personas too. They report the same benefits by using the method as those operating solely in a national context, and they perceive the advantage of getting a common language across departments in many different countries with the personas as even greater.

In connection to the use of personas in a global perspective two models can be observed:

  • To let the different personas represent various nationalities thus cover as many geographical areas as possible.
  • To have persona descriptions that are general and versatile thus cover as many geographical areas as possible. This is mainly done by providing the descriptions with English names

These strategies work within a Western context, but several describe that it is difficult to develop persona descriptions to an Asian market as they lack knowledge on culture and procedures.

Acting as Someone Like Me – personas in participatory innovation

Articleed March 21st, 2012 by Lene Nielsen & filed under Personas (UK)Scenarios (UK).

Article written for the  PIN-C 2012 conference, Melbourne, Australia.

Lene Nielsen

IT University, Copenhagen

lene@itu.dk

Abstract

Including users in large participatory innovation projects together with professional innovators such as designers, marketing professionals, engineers etc. puts a strain on the user that might not like to be the focus of attention.

With point of departure in two cases, one from business and a student project, the paper illustrates and discusses the use of personas as a mean to get users involved in innovation, address their needs, and be a platform that gives all participants equal involvement.

INTRODUCTION

The persona method is viewed as a way for designers to step into the users’ shoes and understand their everyday- and work life, a creative way of injecting accurate information about real users into product development (Pruitt and Adlin 2006). In this paper I present a novel way of involving real users in the innovation process using personas, role-playing, and immersion. Two workshops are described and analysed in an attempt to explain one of the ways in which innovation and user participation can be addressed and oriented towards acting out the future.

The state of personas

Most literature on the persona method originates from IT-systems development (Nielsen 2004, Mulder and Yar 2006, Pruitt and Adlin 2006, Cooper et.al. 2007). Here the persona description is used as the foundation for outlining a scenario that investigates the use of an IT-system from the particular persona’s point of view.

The persona descriptions are a tool to get designers to understand users and a mental aid for them to look at problems. In addition the method gives direction to the design process (Cooper et al 2007). Central to the method is the persona description that depicts a unique character with specific details. There is not an unequivocal definition of the persona description and what it is used for; it can be defined by the persona’s goals and the relationship to the product to be designed (Cooper et al. 2007), it can be defined by work-goals and here the description has an exact relation to the data (Grudin and Pruitt 2006), or with data as foundation the method uses the relationship between character and story to create a vivid description of fictitious characters. The vivid description prevents the designer in perceiving the user as a stereotype and at the same time enables identification with the personas through the active engagement in the description (Nielsen 2011).

The purposes of using personas are manifold; the method enables a focused design and is a communication tool that ends discussions. Personas can communicate information from market analysis, user tests and prototypes to all participants in a project (Grudin and Pruitt 2006). The persona description balances between data, knowledge of use and use situations, and fictitious information added to further engagement thus becoming a remedy against automated thinking in the design process (Nielsen 2011).

The scenario

The scenario plays a central part in the persona method, it is in the scenario that design ideas are evoked and tested. Even though scenarios have been around for some time there is no single definition in common use. At the broad level, there seems to be agreement that scenarios are stories.

In the persona method, the persona is the focal point of the scenario and not the IT-system. Here the authors suggest different types of scenarios. Cooper et al. (2007) propose a progression from initial, high-level scenarios to more and more detailed ones with increasing emphasis on the user-product interaction. As a part of this progression, they distinguish between problem scenarios, which are stories about a problem domain, as it exists prior to, and design scenarios that convey a new vision of the situation after technology introduction. Pruitt and Adlin (2006) refer to Quesenbury’s (2006) definition of different types of personas and to scenarios with different levels of detail placed in a continuum between evocative and prescriptive scenarios as well as along the development process. Mulder and Yar (2006) propose only one type of scenario that is an idealistic vision, that describes each persona’s different journeys through a website, the interactions and possibilities the persona is met with, and the choices the persona makes.

Common for the authors the scenarios are evoked by designers stepping into the users’ shoes, an engagement that originates from the persona descriptions.

Two cases of personas for co-design

The workshops described in this paper are based on 10 Steps to Personas (Nielsen 2007). Key to the 10 steps are scenarios, that are stories describing the persona’s interaction with an interface or product. As a story the scenario has a main character, a setting, a goal, it has actions that lead to the goal, and it has obstacles that hinder the way to the goal (Madsen and Nielsen 2009).

The two cases show different instances of users acting as personas. In the first case the use of personas and the involvement of users were created ad hoc to support the wish of the client to include both personas and users in the innovation process. The second case shows an experimental use where a group of students wanted to try the method in a facilitated workshop. The students wanted to capture different attitudes and interactions among various persona descriptions.

The two workshops thus show variations in the use of having users act as personas and have different learning.

ARLA AND NEW PRODUCTS

Arla Foods a.m.b.a. wanted to innovate within the unknown area of company cafeterias. With the purpose of initiating a user-driven innovation process for product development, the following stages were implemented:

  • scientific data gathering,
  • understanding users and gathering data,
  • data analysis,
  • and an innovation workshop lasting two days.

From the initial data gathering it was found that overall there are only a few different types of company cafeterias: a type where the company pays a subsidy towards the food, they often employ former chefs and the company takes great interest in the employees health and has a health policy. The employees are deducted a monthly fee from their salary to cover their lunches. In other types of company cafeterias, the employees pay for what they eat directly. The company has no health policy and do not subsidy the food. This type of cafeteria often serves industry workers. A third type of cafeteria is a mix of the two.

This segmentation of company cafeterias gave direction to which cafeteria managers we should invite to participate in a dynamic focus group (Halkier 2010). We initiated four focus groups at different types of cafeterias that each had 3 to 4 participants.

From the focus group 8 different themes were extracted and two different types of cafeteria managers were identified. The themes were presented in a 30-minutes documentary film and the manager types in two persona descriptions.

Both the documentary and the persona descriptions were used in a two-day innovation workshop. The workshop participants were canteen managers, concept developers, marketing professionals, and engineers.

The workshop had the following course of events:

  1. Introduction to data.
  2. Viewing of the documentary. To get an understanding of the domain, the participants were asked to look for pain-points and note them on small cards.
  3. A game. This was inspired by design games (Brandt 2006) and used the cards with pain points. The game enabled the participant to discuss and align their understanding of the different workflows in the cafeterias and variances in attitudes towards food among the cafeteria managers.
  4. Presentation of findings from the game.
  5. Introduction to the two personas
  6. Introduction to future situation. The situation is phrased as an event that can begin a scenario.
  7. Participatory innovation from personas and with scenarios.
  8. Presentation of ideas
  9. Ranking of ideas and common decisions on which concepts to develop further.

All groups were mixed to cover a broad specter of knowledge and expertise. Even though the canteen managers came on the second day of the workshop, they entered the groups without hesitation and got engaged in the creative process. It was easy for them to relate to the persona descriptions and they felt on equal foot with the designers.

The scenario

The scenarios forced the whole team to imagine a future world and to create future solutions for the persona.  The persona description aligned the discussions and both designers and cafeteria managers had to understand the particular situations and needs for the persona. The designers often asked the cafeteria managers about their daily work processes, about their customers, and their attitude towards food. The managers willingly provided the information and they all concentrated on the persona again.

Often the team spontaneously acted out little scenes in order to try out design ideas from the personas point of view.

DESIGNING A COMMUNICATION TOOL

Figure 1: The participant explains to the moderator how the persona will act in the given scenario.

The aim of this project was to develop a tool that could support communication between soccer trainers, kids, and parents. Data was gathered from observations and focus groups. From this two personas that had different behaviour and media use were created as well as a number of scenarios that varied in situation and context.

In a workshop setting a mother to a child who engage in sports were asked to go through a set of scenarios for each persona and create novel solutions to the problems presented.

The workshop had the following procedure:

  1. The participant was asked to read the persona description of the first persona Michael – a soccer dad. She commented on the description “I know him, is it a real man?”. Thus implying that the description was credible.
  2. She was then presented with cards that represented different media e.g. Facebook, a low-tech mobile, written lists, a smartphone.
  3. She was asked to read a situation and go through it from the point of view of the persona.
  4. Step 3 was repeated several times.
  5. The participant was handed the second persona description of Mette – a soccer mum – and asked to read through it.
  6. She was again presented with a set of situations and asked to go through them from the persona’s point of view.

The scenarios

The facilitator (F) explains that the participant (P) has to do a kind of role-play.

On the table in front of her are some cards

—————————-

F: This is a little inspiration of the kind of communication tools available.

The facilitators reads the situation aloud to the participant: It is soccer day and Michael is at home ill with the flu, his wife has to work late and there is no one to take his son Mads to soccer training. Michael knows that Mads is eager to go and will be very unhappy if they cancel. What does he do?

P: I can’t remember what kind of phone he has

F: He has a smart phone

P: He would get hold of his parents (….)

F: What if they were on holiday

P: He would try some of the other children’s parents.

F: How would he do that?

P: He is a net-worker. I think he has their email, I don’t know if Facebook is smart enough for him. But I think he would get their emails from Facebook via his smartphone. Yes that would be it.

F: So he is a friend with some of the other parents?

P: Yes because they have, at least some of them, not those who are followed to soccer by their mum, but those who are followed by their fathers. I think there is a kind of community among them. Even if I don’t know anything about football, I could imagine that. We don’t do football in our family.

—————————-

As it can be seen above the participant has no problem in coming up with a scenario of how this persona might solve the problem. She uses her knowledge of how gender plays a role among the parents and also who talks and relates to whom.

When the participant had gone through the different situations, she had to go through the same situations for the second persona.

Example 2: transcript of the innovation process for the soccer mum persona. (Author’s translation)

The facilitator acts as a game master who stops the play and gives it new directions. This does not hinder the participant in creating a story-line, she hesitates, but quickly comes up with a new plot.

The participant had no problem in switching between the two personas even though only one resembled her-self. As it can be seen in example 2 she was able to draw on her own behaviour and compared the persona’s behaviour to her own. When she acted as the persona that resembled her-self, she often commented on the likeness, how she herself would react, and her own needs. At other times she used her knowledge of other parents and their preferences and behaviour.

DISCUSSION

In most literature on co-design users represent and act as them-selves and/or designers act like users. Users are viewed as domain experts and designers as innovation experts. Using personas in co-design sessions seems to have a positive influence on the relationship between users and designers as it aligns their roles to incorporate but user and innovator.  Doing so takes the focus away from the user similar to the use of puppets and masks (Ylirisku and Buur 2007). With personas the user does not need to put her-self on the line.

The moderator

Acting as a persona in a scenario has similarities with role-playing as the character is created before the play is performed and the scenario offers a pre-built world. In the second case the moderator acts as a game master who asks questions to the user. The questions of “what if”, suddenly gives new directions to the scenario. As with role-playing it is easy for the user to step into character and the constraints helps guide the play (Medler 2010).

The situation facilitates the scenario

The two cases have very different procedures; the first case was a group ideation process where most of the time was spent stepping into the user’s shoes and having discussions that lead to solutions. The procedure also included spontaneous acting. The second case had a process that were highly facilitated, a user in focus, and it included a number of role-playing sessions, that focused on reaching a goal that arose from the problems raised in the various situations. Using the presented media, the user created a linear plot – a scenario – that led to the solution.

In both cases the situation helped to get the innovation process started and gave direction to the solutions.

The two cases show how users 1) are able to act as personas and produce innovative and creative solutions both together with professional designers and alone. 2) The descriptions enable designers and users to be aligned, and at the same time support the users to incorporate their experiences and knowledge of the domain into the ideation process. 3) The participants use their understanding of the domain to create stories/scenarios both from the perspective of personas that are similar to them, but also from personas that are unlike themselves, as they are familiar with different behaviours within the given design area.

ACKNOWLEDGMENTS

Thanks to Karsten Laybourn, Kasper J. Sørensen, Katrine L. N. Kristensen, Laust E. W. Axelsen, Line Mulvad for giving me access to their material.

References

Brandt, E., 2006. Designing Exploratory Design Games: A Framework for Participation in Participatory Design? PDC 2006: Expanding Boundaries in Design. (1) pp.1-10, New York.

Browne, J., Temkin, B. D. and Geller, S., 2008. Design Persona Best Practices From Japan. Examining How Four Organizations Successfully Use Design Personas. Forrester Report, September 16

Cooper, A., Reimann, R. and Cronin, D., 2007. About Face 3: The Essentials of Interaction Design. Indianapolis: Wiley

Grudin, J. and Pruitt, J., 2002. Personas, Participatory Design and Product Development: An infrastructure for Engagement. PDC 2002. Malmoe.

Halkier, B., 2010. Focus groups as social enactments: integrating interaction and content in the analysis of focus group data. Qualitative ResearchFebruary 2010 (10/1) pp.71-89

Madsen S. & Nielsen L., 2009. Using Storytelling to Improve Scenarios. Proceedings of the IADIS International Conference Information Systems, Barcelona, Spain, pp. 25-27

Medler, B. & Magerko, B., 2010. The Implications of Improvisational Acting and Role-Playing on Design Methodologies. CHI 2010: Dance, Dust, and Drama: Designing Design, Atlanta, GA, USA pp. 483-492

Mulder, S. and Yaar Z., 2006 The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web. New Riders Press.

Nielsen, L., 2004. Engaging Personas and Narrative Scenarios. Copenhagen: Samfundslitteratur

Nielsen, L., 2007. Ten Steps to Personas. HCeye. http://www.hceye.org/UsabilityInsights/?p=73  [accessed 20 September 2011]

Nielsen, L., 2011. Persona – brugerfokuseret design. Aarhus: Aarhus Universitetsforlag.

Pruitt, J. and Adlin T., 2006. The Persona Lifecycle: Keeping People in Mind Throughout Product Design. San Fransisco: Morgan Kaufmann.

Quesenbury, W., 2006. Storytelling and Narrative. In Pruitt, J. and Adlin T., The Personas Lifecycle, pp. 520-555, San Fransisco: Elsevier

Ylirisku S.P. and Buur J., 2007. Designing with Video: Focusing the User-Centred Design Process. London: Springer

Co-design with personas

The persona method is aimed at talking about the users and representing users in the design process. I (and some of my students9 have experimented with having users present in the initial design process and let users act as personas for innovation. I gave a talk about this in Chicago, Sept 2011. These are my slides from the talk at UX Masterclass in Chicago lene nielsen – codesign with personas

 Why co-design with personas

Including users in large participatory innovation projects together with professional innovators such as designers, people from marketing, engineers etc puts a strain on the user that might not like to be the focus of attention. With point of departure in two cases, one from business and a student project, I will illustrate and discuss the use of personas as a mean to get users involved in innovation, address their needs, and at the same time be a platform that gives all participants equal involvement.
I aim to present a novel way of using role-playing, immersion, and personas. Two workshops are described and analysed in an attempt to explain one of the ways in which innovation and user participation are addressed and oriented towards acting out the future.

Background
A persona is a fictitious user described with basis in data. The personas method is recognised in IT development within the private sector, but has spread to other areas such as marketing and product development. An example of how the method is used in marketing is the Japanese beer company Asahi Breweries that used personas to strategise the future of its Super Dry beer brand (Browne, Temkin & Geller, 2008). The most common use of personas is for a design team to use the user description to understand and engage in the user’s world in order to create new interaction forms or products that correlate with the users’ needs and contexts. In this use of personas actual users are present in the data, but not in the design process.
The workshops described here are based on 10 Steps to Personas (Nielsen, 2007). Key to the 10 steps are scenarios, that are stories describing the persona’s interaction with an interface or product. As a story, the scenario has a main character, a setting, a goal, it has actions that lead to the goal, and it has obstacles that hinder the way to the goal (Madsen & Nielsen, 2009).
The two cases show how users 1) are able to act as personas and be as creative as professional designers 2) use their understanding of the area in focus to create scenarios both from the perspective of personas that are similar to them, but also from personas that are different from them, because they are familiar with different behaviours within the given design area.

A professional case
Arla Foods amba wanted to innovate within the, until then unknown area of canteens. For the purpose of creating new products from user knowledge an innovation process was created that consisted of: Scientific data gathering. User data gathering – 4 dynamic focus groups, each video filmed. Data analysis. From the analysis a documentary film lasting 30 minutes and two personas were produced. An innovation workshop lasting two days.
The workshop had the following course of events: Introduction to data. A design game using the documentary and focusing on pain points. Presentation of findings in the game. Participatory innovation from personas and scenarios. Presentation and ranking of best ideas.
The participants that innovated were canteen managers, concept developers, persons from marketing, and engineers. All groups had at least one person from each category. Even though the canteen managers came on the second day of the workshop, they entered the groups without hesitation and got engaged in the creative process. It was easy for them to relate to the persona descriptions and they felt on equal foot with the designers.

A student case
The aim of the innovation session was to develop a tool that could support communication between soccer trainers, kids, and parents. Prior to the session, data was gathered from observations and focus groups. From this two personas that had different behaviour and media use were created as well as a number of scenarios that varied in situation and context. The participant was asked to go through all the scenarios from the point of view of both personas, with the intention of creating novel solutions.
The participant, a mother to a child who played soccer, had no problem in switching between the two personas even though only one resembled herself. She was able to drawn on her knowledge of other parents and their preferences and behaviour, but when she acted as the persona that resembled her-self, she often commented on the likeness, how she herself would react, and her own needs.

References
Browne, J., Temkin, B. D., Geller, S. 2008. Design Persona Best Practices From Japan. Examining How Four Organizations Successfully Use Design Personas. In Forrester Report, September 16, 2008

Madsen S. & Nielsen L. 2009. Using Storytelling to Improve Scenarios. In Proceedings of the IADIS International Conference Information Systems, Barcelona, Spain, February (pp. 25-27).

Medler, B. & Magerko, B. The Implications of Improvisational Acting and Role-Playing on Design Methodologies. CHI 2010: Dance, Dust, and Drama: Designing Design April 10–15, 2010, Atlanta, GA, USA (pp. 483-492)

Nielsen, L. 2007. Ten Steps to Personas, http://www.hceye.org/UsabilityInsights/?p=73

The Pragmatic Persona

Personas can be used in more than one way. Sometimes the writing of a persona description helps frame the discussion about who the users actually are. In this instance, there might not be a lot of data behind the persona description, but the discussions about the descriptions can initiate that further data needs to be recorded. Sometimes there is no need to gather further data.

I will in the following report from a case where the goal was to do rapid prototypes and test these with users. We did not have any data except an initial description of the users described by the customers. In these descriptions, the focus was on age and use of technology.

As the prototypes were centred around going out and exploring the town, we took a Danish segment description Conzoom and looked at all the segments which enjoyed an evening out and were below the age of 49. This created a picture that we were actually dealing with two different categories: the young ones between 19 and 29 (students or with low incomes, who lived in rented flats in the city center or close by) and a group between the age of 30 and 49 (singles or couples who had had children late in life, with a very high income, who lived in owned estates close to the city center). This made us create Katja and Jan. We used the situations for Katja and Jan when we created scenarios for the prototype, their situations when we created tasks for the tests, and the descriptions in the process of recruiting users.

When doing the tests our assumptions about the users were confirmed, their attitude towards the service and their demands were distinctively different and fitted our descriptions. The users were so Katja and Jan, and for a couple of days, we became Katja and Jan spotters. During lunch or going out we constantly looked for Katjas’ and Jans’.

After the tests, we were able to refine the design and within a very short time span we had created a prototype that envisions the idea behind the service, is based on solid data, and has a lot more value during arguments with developers and managers than it would have had without the Katjas and Jans.

From the vague ideas about the users and a technical approach, we managed to create an initial user-centred design process that jumped several steps in the personas process (it included step 1, 2, 5, 6, 9). The process was pragmatic, but still added a lot of value. We now have an idea about what we do not know and in a further process, it becomes easier to refine the descriptions with more data.

Katja, age 25

katja2.JPG

 Katja, left, and her girlfriends having a party

Katja studies philosophy. She has a job in a small clothes shop with special design approximately 10 hours a week. She shares a flat in a cheap area near the city centre of Stuttgart with a friend. Katja loves going out, she meets friends at cafés and bars and loves to go to concerts, often small and cheap places.

Katja used to have a quite old mobile, but one night at a bar, it fell into the toilet and didn’t survive. She got her new GPS enabled phone from her parents at Christmas.

Jan, age 35

 Marion took this photo with her mobile phone, at one of their nights out.

Jan is a sales manager. He met Marion five years ago and they have got two children age 2 and 4. Marion is slightly older than Jan and knows what she wants. They bought a house in a nice area outside Frankfurt three years ago when Jan was promoted. Jan has a very busy day and many meetings in town.

Marion and Jan enjoy a night out once in a while. They know it is important to prioritize the relationship and once a month or every other month they have a carefully planned night out. Jan has a new mobile phone. He appreciates the values it signals over functionality.

Personas – as part of a user-centered innovation process

This article was first published at HCI Vistas

I recently hosted a personas workshop aimed at innovation within dairy products. It was with some nervousness I went into a process that is quite far from IT, web design, mobile software, and the familiar boundaries of technology. Interestingly the personas method seems to function in other settings as well and – more interestingly with methods from a more traditional field of innovation.

The aim of the workshop was to innovate on products or invent completely new products. The participants were a mixed crowd: engineers, anthropologists, a product designer, a chef, concept developers, and project managers.

Collecting data

Before the workshop an anthropology study was carried out and data from a number of interviews and visits with Danish families were analyzed. Notes from these visits formed the basis for the personas categories and descriptions.

Concurrently a series of focus groups conducted with the method “Desired Outcomes” were hosted by Axel Rosenø. The desired outcome method focuses on problems to overcome in future design. These are prioritized and used in innovation workshops. In this case a list of outcomes for different handlings of dairy products were extracted and together with a list of ideas extracted from the visits and interviews formed the basis for scenarios.

Making personas

In this case the anthropology study were analyzed separately and presented to the participants. Interestingly enough it seems that the level of analysis in the two studies – anthropology and personas – is quite different. The analysis of the first study focuses on communalities and is reported on a concrete level, while analysis of the same material, when used for a personas process, focuses on differences and extraction into categories and is reported on an abstract level. In this case the anthropology study reported similarities within e.g. attitudes to health, some view a healthy body as a slim body others view the body as a functional body that can be optimized by eating healthy food.

In order to create personas an organization of the data into high order categories were necessary. A high order category was e.g. move-ability whether the persona took in new inspirations or acted mainly on habits. Another category was whether the persona had an ideal she strived to live after or if she lived after an everyday practice. The categories served to put each person into a grid that became the foundation for the personas – persons that were close together, but far away from others, formed a cloud of people with similarities. The cloud became the foundation for a persona description.

The move from facts to categories is in my experience one of the most difficult part of the personas process. Pruitt and Adlin (2006) describe it as going from factoids to clusters, where factoids are groups of facts that in a later process are transformed into high order clusters. In the 10 Steps to Personas method I describe it as going from a hypothesis, over verification, to the final patterns.

Getting to understand the personas

The persona and scenario workshop started by introducing the personas to the group. Each group were handed a personas description and asked to find a photo that illustrated their persona. To flick through photo databases and discuss how the written description can be expressed visually, forces the participants to delve into the text and to begin to imagine their understanding of the persona. In my experience most groups begin with a discussion of the hairstyle and how the hair expresses the inner values of the persona. This leads to discussions of other values and how they can be expressed visually.

Future scenarios

Inspired by design games a group of innovators were given:

· A persona description,

· A handful of ideas each written on a card (idea cards)

· A set of cards each with a problem described on it (problem cards).

The participants were asked to group the cards and ascribe headlines to the groups. The aim of this was to get the participants to understand the problem and ideas that were discovered during the field work.

Then each group were handed a situation for their persona and asked to create a scenario for their persona taking into account the ideas and problems on the cards.

In the room were different kinds of tools – foam blocks, large sheets of paper, scissors, and Stanley knifes – all served as inspiration tools and helped the participants to act the scenarios out and to create props. During the enactments the participants found new ideas and developed concepts that were later presented for the whole team.

Benefits from personas in innovation

As one of the participant’s expressed “now we are working inside out, normally we work outside in” with this he had the feeling that for the first time they invented from within the user, by understanding the user, instead of trying to push products to the users. The participants had a feeling of knowing the different users, their very different daily lives, the problems they are confronted with, and the values they apply to the problems. From this there seemed to grow, not radical innovation, but solutions to real problems.

The benefit of the acted scenarios, in this case, was the understanding of the context in which the products had to be used and an innovation that took a point of departure in both the personas and the contexts. Most of the participants acted the scenarios out, playing the part of the persona and of people in the surroundings. They used props to illustrate the handling of different products and this way got ideas for new products as well as tested these.

Benefits from using “desired outcomes”

The desired outcomes seemed to provide a setting for the scenarios. In my experience, as I have mentioned in an earlier article, 10 Steps to Personas, there is a tendency to create scenarios with a very happy outcome that overlook conflicts, obstacles, and critical instances in the scenarios. By focusing on problems the desired outcomes method seems to be able to create an awareness of the critical instances and get the participants to include these in the scenarios.

An Empirical Study of the Inventive Aspects of Narrative Scenarios in IT Redesign

Written by:
Sabine Madsen, Department of Informatics, CBS, Howitzvej 60, 2000 Frederiksberg, Sma.inf@cbs.dk
Lene Nielsen, Snitker & Co., Bredgade 21B, 2160 Copenhagen K, ln@snitker.com

ABSTRACT
The purpose of this paper is to understand how and what types of innovation that occur when using the persona/narrative scenario method for IT redesign. The paper reports from a one-day workshop held as a part of a large project concerned with redesign of an e-report portal for Danish governmental bodies. The aim of the workshop was to generate narrative scenarios about the future use of e-reports based on already developed personas. The research shows that: a) innovation occurs as the conversation unfolds and that the unfolding conversation is structured by the participants’ focus on the persona, the scenario assignment, and existing IT oriented artifacts, b) barriers for innovation emerge in the form of the participants’ reliance on existing artifacts, lack of exploration of the obstacles the persona might encounter, and their problems capturing insights and ideas in writing, c) different approaches to scenario development generate different levels of abstraction and empathy and that these levels seem to relate to the types of innovation that occurs, i.e. IT design ideas and/or understanding of users. Based on the research findings, areas for future research are proposed.

INTRODUCTION

Mainstream information systems development (ISD) methods emphasize thorough expert-driven analysis of information and systems requirements and systematic well-planned processes [12]; [19]; [2]. In contrast, methods from the field of Human-Computer-Interaction (HCI) focus on collaborative design processes that view IT development from the user’s perspective and for his/hers benefit. The persona/narrative scenario method for IT design is positioned within the HCI field. It is a ‘soft’ and creative method – and especially so from an ISD perspective – for generating knowledge about users (persona), i.e. who they are and what they value, as well as new ideas for how they will and should use the IT product in the future (scenario) [18]. But how much do we actually know about the persona/narrative scenario method’s ability to create new insights into users and innovative ideas about IT systems? The HCI literature reveals a lack of empirical studies that address the inventive aspects of narrative scenarios in general and in particular when it comes to the method’s application to redesign of already existing IT systems.

The purpose of this paper is to understand how and what types of innovation that occur when using the persona/narrative scenario method for IT redesign. Numerous definitions of the concept of innovation exist [9]. In this paper, an innovation is defined as ‘new to the workshop participants’ [9]. The paper presents an empirical study of a one-day workshop held as a part of a large development project concerned with redesign of a portal of e-reports for Danish governmental bodies. The aim of the workshop was to generate narrative scenarios about the future use of the e-reports based on already developed personas. 16 people from several areas, such as IT development, graphical design, user interface design, and user rights, as well as customer representatives working with marketing/content and project management participated in the workshop. The research was conducted by the two paper authors in the roles of action researcher and present, non-participating observer respectively.

The narrative scenario

Even though the HCI literature contains different approaches to scenarios, the communality is that scenarios are viewed as stories told in different media, i.e. via talk, text, drawings, film, etc. The scenario – or story – is a linear sequence of events that progresses towards a goal, there is a human agent, and actions happening between a human agent and an IT system. IT design scenarios can be viewed from two different approaches: an approach focusing on the system (the system approach) and an approach focusing on the human agent (the narrative approach) [15]. The difference between the two approaches is how much emphasis is put on describing the use and/or on understanding the user.

In the systems approach the focus is on describing the use of the IT system, its functionality, and the actions the system performs. This is expressed in the statement: “Scenarios compel attention to the use that will be made of the design product.” [7] p. 15. Thus, the aim of a system approach scenario is to provide an accurate description that tries to predict the future system and its use, e.g. in the form of a use case [15].

The narrative approach focuses on understanding the user, the user’s motivation for system use, and s/he’s different choices when using the system. The narrative approach is closely connected to the persona method, expressed as: “Scenarios written around personas tend to clearly highlight the impact of your design on your target users.”[18] p. 380. The aim of the narrative scenario is to explore, to stimulate the imagination, and to support the creative process. Narrative scenarios can be used to compare different ways for the user to achieve the same goal and/or to evaluate and decide between different design suggestions [17], [4]. They can also be used to explore design solutions [6], [13] not only for ordinary use, but also for extreme situations, e.g. problem scenarios or scenarios for people with special needs [11]. The problem scenario is in line with the literary story form as it focuses on the tension and interplay between the established and the extraordinary, and how the dramatic elements move the story forward [8].

The narrative scenario follows a linear story structure with a beginning, middle, and end. Moreover, in line with narrative theory [1] it contains four elements:

  • A setting, where the user, the context of use, and the situation that starts the use are presented.
  • A goal, i.e. what the user wants to achieve.
  • A plot, i.e. the way actions develops towards the goal.
  • A resolution, where the user either achieves the goal or, in scenarios with a negative outcome [6], do not.

The narrative scenario relies on a persona description. This description is not part of the scenario, but forms the basis for understanding what the persona does and why the user chooses to act as s/he does.

This paper presents findings from a workshop that draws on the narrative scenario as a story, which focuses on the user and serves as a means for investigating IT design problems and solutions as well as support of creativity.

The Virk.dk case

It is the strategy in Denmark that all communication between companies and government is to be digital in the near future. Virk.dk is part of this strategy. It is a portal that contains more than 1500 forms, which can be used by companies to report to governmental bodies in Denmark. Today the forms can either be printed and sent by post or filled in digitally and returned by e-mail. In the future all forms must be reported digitally.

The process of reporting involves different stakeholders (e.g. tax authorities) who develop the forms, receivers of the forms (e.g. an administrative employee), and the person reporting (e.g. an accountant).

Virk.dk has existed for some years, but has not been widely used due to technical problems and a lack of focus on e-reporting. This paper reports from the redesign of the portal.

Quite early on in the redesign process it was decided to use personas and scenarios as it was the hope that user centered methods could help overcome the problems with lack of use. A structure for the process was proposed and accepted. Experience shows [18] that it is of great importance to involve and get buy-in from all those who participate in the development process. A series of workshops was therefore proposed, based on 10 steps to persona/narrative scenarios developed by one of the paper authors.

The first workshop covered the first three steps: 1. Finding the users. Surveys about e-reporting and interviews with staff at the Virk.dk help desk provided the data. 2. Building a hypothesis. 3. Verification. The workshop lasted half a day and participants were stakeholders, customer representatives, and consultants. In the workshop the participants were presented with the analysis of the data about the users. The aim was to validate the findings from the data gathering session.

The second workshop covered the next 2 steps: 4. Finding patterns. 5. Constructing personas. The workshop lasted half a day and saw the involvement of the same participants as in the first workshop. The participants were introduced to the persona method and asked to write personas descriptions.

The final workshop concerned the last five steps. 6. Defining situations. 7. Validation and buy-in. 8. Dissemination of knowledge. 9. Scenarios. 10. On-going development. The third workshop was a full day workshop aimed at finding photos for the persona descriptions and creating scenarios. Participants were customer representatives, graphic designers, and programmers and covered several areas: development, user rights, graphical design, and marketing. Three of the customer representatives had participated in the earlier workshops, but most of the participants had not previously partaken in the persona/scenario development process.

The aim of the workshop was twofold, namely to get the workshop participants 1) to engage in the persona descriptions, and 2) to use the narrative scenario method to create further insight into users as well as new IT design ideas. The 16 workshop participants were divided into four groups. In the first part of the workshop the groups were asked to find and present a relevant photo that illustrated a written persona description. In the second part of the workshop the narrative scenario method was first introduced. Then each group got a starting situation for their persona, developed a scenario, and presented it to the other groups. This particular design for the third workshop day was chosen because previous research has shown that the prerequisites for collective learning and generation of ideas are that a shared knowledge base is established, that insights are actively processes through joint reflection, negotiation, and expansion, and that storytelling is a relevant means for building a shared understanding, for making sense of past actions, and for envisioning the future [5] [16].

This paper reports from the second part of the third workshop concerned with narrative scenario development and presentation.

THE CASE ANALYSIS

In this section, the analysis of the four groups’ scenarios is outlined to provide an overview of how and what types of innovation that occurred in the workshop. Subsequently, we investigate how one group developed the scenario in order to understand the inventive aspects of the persona/narrative scenario method in more detail.

Presenting Scenarios

The four groups were asked to give a short oral presentation of the scenarios they had developed and to show their written scenarios on a large screen.

The analysis of the plenary session shows that the four groups used three distinctively different approaches to scenarios with regard to the form of the developed scenario and its oral presentation.

  • Approach 1: An oral scenario based on discussions was presented as a simple story, used by group one (Persona: Karina).
  • Approach 2: A short scenario was written and presented as a more enhanced oral story, used by group two (Persona: Michael) and three (Persona: Jesper).
  • Approach 3: A scenario was written and read out load as an elaborate story, used by group four (Persona: Dorte).

The three approaches and the innovations they generate are presented below.

Approach 1: Oral scenario, simple story

The first group had chosen not to write anything down during the scenario development session. The oral presentation of the group’s work was a story that developed smoothly as the persona, Karina, did not encounter any problems. The plot of the scenario was as follows. Karina is presented as an employee in a large company and as an efficient, no nonsense person. She logs in on the front page, finds The Statistical Bank of Denmark, presses wage statistics, and finds sickness benefit. She meets different areas of reporting. She begins to report. She ends by signing with her digital signature as she has done many times before. The system asks if she wants to continue, archive, or quit. She quits. If she looks for information, she uses the search field.

The causal plot has the minimum characteristics of a story: there is a setting, but the story unfolds in a non described surrounding. There is a goal, which drives the story forward. There is a character and her actions are coherent with her character description, e.g. she is the oldest of four siblings, she is used to taking decisions, and she is therefore the company’s administrator of Virk.dk, but apart from the introduction, the character was not elaborated on.

The group investigated the system on an abstract level, like what kinds of areas Karina meets, and they e.g. referred to icons and reports as: “an icon in some form”, “a digital report or another kind of report”. Moreover, the group did not investigate the problems that may be connected to reporting. Even a rather complex area such as control of user rights was dealt with in a superficial way. “She is Virk administrator. This means that no matter what she is reporting she will be able to control user rights.” (Presenter, Group 1).

From the oral narrative the group came up with two IT design ideas:

  • An icon showing whether the report is in digital form or not.
  • The  user expects to be able to see reports dating 5 yers back

Approach 2: Short scenario, enhanced story

The second group explored how their persona, Michael, uses Virk.dk as it is today. The story had a refined set-up with introduction of time and context. Michael, who is the owner of a small shop, closes his shop for the day and has dinner and a glass of wine with his wife. Then he turns on the PC and looks for information on VAT on imports from Turkey. The plot advances despite Michael’s lack of IT skills. He searches using Google, tries things out, follows links, reads. He is familiar with another system “Startvækst”, he searches there, finds a link to the tax authorities, and surfs for fun on Virk.dk, where he does not find what he is looking for. The story ends as Michael gives up and decides to call his accountant the next day.

The written scenario was very short, while the oral narrative was more enhanced. The overall story related to the persona and he was prominent in the plot, whereas Virk.dk received only little attention. Possibilities for helping Michael overcome the identified obstacles were not explored.

The written scenario story had a post script, where the group introduced search engine optimizing. This item was perceived by the group as an innovation together with the introduction of mutual text links to related sites, such as tax authorities, but the scenario did not result in actual IT design ideas.

The third group also wrote a short scenario, which was enhanced in the oral presentation. The written scenario vividly described the 2nd of January 2008, the first day after the Christmas holiday, where Jesper, who is an accountant, has a huge pile of work that has to be done. The oral story described the context of Jesper’s work day in even more detail than the written scenario.

The plot of the story is as follows. When Jesper has to report the first instance for a customer, he realizes that Virk.dk has changed. The realization comes when his bookmarks no longer work. He logs in, keeps focus on his task and finishes what he intends to do, but pays attention to the new functionalities and makes a mental note of exploring the new Virk.dk site later. The urge to explore is motivated by his inclination to help his colleagues. This explanation created an easy frame for an otherwise very sensitive area, namely when and why do users explore and come to understand the new system and its functionalities? However, the group only touched upon the subject without examining it further.

Both the written scenario and the oral presentation here of started with a focus on Jesper, but as the written and the oral story progressed, Jesper was forgotten in favor of a focus on the system.

The group explored three critical incidents:

  • The start where Jesper’s bookmarks no longer work and how to guide him to a log in and an understanding of the redesigned site.
  • Problems concerning bookmarks and how Jesper or the system can recreate them in the new system.
  • Jesper’s need for a view that concerns both the companies he represents and himself.

Each of the incidents led to new IT design ideas.

Approach 3: Written scenario, elaborate story

The fourth group chose a quite different approach as they wrote a scenario centered round their persona Dorte, a secretary in a small company. For presenting, they chose to read from the scenario without showing anything on the screen. The narrative was very detailed. It quite thoroughly explored the situation Dorte is in when she tries Virk.dk for the first time as well as her need for guidance. In the scenario, Dorte has received her digital signature and invites her son to dinner to get him to guide her through Virk.dk. She logs on, searches for reimbursement of trainee wages and recognizes the relevant link as it has the same name as the paper-based form she has used previously. Before she can fill in the form she has to accept an agreement with Virk.dk. She gets confused, but her son reassures her. Dorte accepts, and begins her task of filling in the form. She sends in the form, receives an acceptance, and prints the form. When quitting she receives a message saying that the form is not saved under her favorites with an option to save. Again, Dorte gets confused, but with her son’s encouragement she chooses “save as favorite”.

The group presented afterthoughts as they were aware that they had written a rather idyllic scenario, where they did not explore the problems Dorte might encounter.

The story had intense descriptions of Dorte’s feelings and thoughts. It established an understanding of Dorte and her needs and advanced ideas concerned with how to communicate to and with Dorte.

Scenario presentation summary

The analysis of the scenario presentation session shows that innovation occurred via the groups’ different approaches to scenario development. The different approaches in turn generated different levels of abstraction and empathy that seem to relate to the type of innovations that were created.

The first two approaches can be characterized as abstract rather than empathic. They focused on the IT system and are close to the type of scenarios described earlier as the systems approach. They seemed to generate several new IT design ideas. In contrast, the third approach emphasizes empathy and ability to put oneself in the persona’s position. It was more concrete, maintained a focus on the user, and was closer to the type of scenarios described earlier as the narrative approach. The third approach generated insight into the user’s thoughts and feelings, and ideas for textual communication to the user when interacting with the IT system.

The analysis also reveals that barriers for the groups’ innovativeness emerged in the form of reliance on the existing Virk.dk, e.g. group two focused on Michael’s use of the existing system rather than of the new Virk.dk, and all groups’ lack of exploration of the obstacles their persona might encounter. Thus, while group two and three mentioned problem areas, none of the groups sought to clearly define the problems and they did not try to find ways to help their persona overcome them.

The following section takes a closer look at one group’s approach to scenario development.

Developing Scenarios

Before the groups presented their scenarios, a scenario development session was held. The session lasted a little less than one hour during which the third group, i.e. the Jesper group, was both video-filmed and observed for a total of 51.10 minutes. The group consisted of four people with one person from IT development (Person1) and three customer representatives (Person2 who had participated in the earlier workshops, Person3, and Person4). Person1 and Person3 had access to laptop computers. Person1 used his laptop to take notes during the group’s conversation and to write the scenario. Person3’s laptop provided the group with access to the old Virk.dk. During the scenario development session, the group had access to and used a number of artifacts, i.e. the old Virk.dk, a paper-based prototype of the new Virk.dk, the persona description, and the start situation. The group’s persona is Jesper, a 29-year old married man, who has recently become a farther, likes sports, is ambitious, and works as an accountant. The start situation states that “Jesper is used to Virk.dk but suddenly it looks different. How does he react? How does he get [his bookmarks] into the new system? How does Jesper use ‘MyPage’?” (Start situation).

The Jesper group’s development of the scenario unfolded as follows. Person1 read the first lines of the start situation and the group immediately started discussing how experienced Jesper is with the old Virk.dk and how he uses it. Here, they used Person3’s laptop to go through the old system. Having established that as an accountant Jesper is an experienced user, they continued to talk about how he would be likely to approach the new Virk.dk on the first day. After a 10 minute discussion Person1 returned to the start situation and read the next line concerning bookmarks. Person2 remembered that the new paper-based prototype from the graphical design agency contains an example of how the new Virk.dk might deal with bookmarks and the group continued their conversation by drawing on the old Virk.dk and the new paper-based prototype as reference points. After 20 minutes Person1 realized and remarked that even though it is helpful to know what the old and the new system does they seemed to have forgotten about Jesper as a specific person. This caused the group to shift their attention back to Jesper. The group believed that Jesper is interested and expectant about getting a new work tool and that he will be motivated to become an experienced user of the new Virk.dk, and quickly, as his family situation and work load makes it important for him to be efficient. Moreover, he wants to get prestige from his colleagues and superiors. After 27.50 minutes Person1 smiled and said that he had written a lot of notes, but that they also had to write a story. For the next 13 minutes the group continued their talk about Jesper as an agent who interacts with the new Virk.dk, while Person1 shifted between contributing to the conversation, taking notes, and writing the scenario. During the last 10-12 minutes of the session the group focused exclusively on writing the scenario.

Method use

The description of the Jesper group’s scenario development session reveals a number of interesting points about their use of the persona/narrative scenario method.

First, the group did not at any point in time read the start situation carefully and in full. Yet, the start situation played a significant role in structuring the content of the conversation. E.g., the start situation states that Jesper uses the new Virk.dk for the first time and as the group members know that the new site will be launched on the 1st January 2008 they assumed that Jesper’s first day of work and of using the new Virk.dk is on the 2nd January 2008. This lead to discussions of whether Jesper knows that Virk.dk has been relaunched (especially since it has just been December and holiday), how he will find the new site, if and how he will login, if and when he might need help, if and how he will transfer or recreate his old Virk.dk bookmarks, that it is important for him to set up the new system to save as many clicks as possible, and if and how he will know when he is acting in Virk.dk as himself or on behalf of his/company’s customers. Thus, the start situation caused the Jesper group to discuss how Jesper, as an experienced user of the old Virk.dk, will go about becoming efficient in using the new system.

Second, it took 27.50 minutes before the group started paying attention to the fact that they had to write a scenario and that the written scenario had to be based on the start situation and follow a certain narrative form. Especially Person1 took it upon himself to ensure that they returned to the start situation to refresh their memory several times during the session and it was also him who recorded key words on his laptop during their conversation, reminded the others that they had to write a story, and who actually wrote the scenario in the end.

Third, just like the group was conscious that they were not paying quite enough attention to the start situation and to the fact that they had to write a scenario that follows a specific form, they were aware that they were not focusing on the crisis, or the dramatic elements of the story about Jesper’s use of the new system. Thus, during their conversation Person2 reminded the others that “[B]ut just to get the obstacles and the conflict into it, right…then Jesper has more of a problem seeing how his company is going to get started [with the new Virk.dk]”, but the missing crisis was immediately forgotten again and it was not until Person1 was deeply immersed in writing the story that they returned to the issue. Thus, while writing Person1 suddenly started smiling broadly and said that it is easy to write “He logs in. He gets the right information. He solves his tasks easy and efficiently”, Person4 continued to say “and then he goes home happy” and Person3 threw her arms up and added “It was a success!”. They all laughed, knowing that their scenario lacks drama and that it is much easier to write it than it will be to develop it and for Jesper to use it on the first day.

In general, the Jesper group talked a lot, and a lot more than they wrote and they had problems capturing the understandings and design ideas that emerged during their conversation, and in particular capturing them in the form of a scenario. This is illustrated by the following comment by Person1, who stated that “I’m writing some things here, notes for us, ideas, and solutions, and stuff, and then I write the actual story afterwards.”. However, because they had to write and when they wrote the scenario they were forced to focus on the persona and on understanding system use from the persona’s point of view.

Conversation content

It is noteworthy that the group on several occasions seemed to ‘forget’ their persona, especially when they conversed about technical possibilities, the paper prototype and its functionality, as well as the need for marketing of the new Virk.dk, and when and what type of help texts people (not Jesper) in general would need. The time that the group spent talking about technical possibilities, the paper prototype, and marketing/information needs as abstract topics without making any references at all to the persona amounts to approx. 8 minutes. Moreover, the group spent approx. 10 minutes from 10.01 to 20.31 minutes into the session talking about the old Virk.dk and the paper-based prototype and even though they did try to view the old and the new system from Jesper’s perspective, Jesper had become a more generalized user and it took reminding for them to return to viewing Jesper as a specific person with a particular family and work situation.

With this said, the group did spend most of the time focusing on Jesper, displaying different degrees of certainty about who Jesper is as a person and what he does as an agent, who interacts with the system and who might act differently, e.g., depending on whether he knows that Virk.dk has been relaunched or not. Especially Person2 was very good at keeping the persona in mind, thereby ensuring that the other group members also viewed the abstract, e.g. IT oriented topic under discussion from Jesper’s perspective. In general, as the conversation flowed and with some reminding from the two champions concerned with the scenario assignment (Person1) and the persona (Person2) respectively, the group members seemed to shift easily between their concrete persona and the more abstract topics of technical possibilities and the needs and wants of Virk.dk users as a general group of people.

However, as mentioned, the group experienced problems capturing their understandings and design ideas in writing as they emerged. For example, there was much talk about the need to inform people and Jesper about the relaunch of Virk.dk and if, how, and what type of help Jesper would be interested in. The group agreed that as Jesper is an experienced user who wants efficiency and prestige he is likely to be informed about the changed site via email, the press, and perhaps via a top banner campaign run on the old Virk.dk. The need for top banners was a new idea that came about because the group members realised that when using the old Virk.dk Jesper is likely to go straight to his favourite links e.g. via bookmarks and therefore he will never see the news section on the current Virk.dk’s main page. Moreover, the group agreed that when Jesper starts using the new Virk.dk for the first time he will not be interested in reading much text “[a]nd he definitely does not want to see a film” (Person3) to learn about the site; rather he will only seek help if, and only if he is unable to proceed on his own accord and he will only want short, precise bullet-point information about the specific problem he is facing. Despite the amount of time the group devoted to discussing this topic, none of the understandings and ideas about people’s, and Jesper’s need for information about the new Virk.dk and its functionality was included in the written scenario or in the oral presentation here of. However, they were recorded in the group’s notes document.

Scenario development summary

The analysis of the scenario development session shows that new insights and ideas emerged as the Jesper group’s conversation unfolded. The insights and ideas were captured in a notes document and in the written scenario. The conversation was structured, and therefore also both enabled and constrained [10], by the scenario assignment, the group’s knowledge about and focus on the persona, and their use of the old Virk.dk and the paper-based prototype of the new Virk.dk as reference points. In general, it was difficult for the group to move beyond the existing IT oriented artifacts and come up with completely new IT design ideas. However, the group’s conversation did lead to the following new understandings and ideas:

1) An increased understanding of Jesper’s/experienced users’ marketing/information needs and ideas about how to meet them (e.g. via top banners and short, contextual help texts).

2) An increased understanding of Jesper as a person, and as a prototypical example of the experienced old Virk.dk user, his motivations for quick learning and personalizing of Virk.dk (e.g. by setting up ‘MyPage’ and recreating bookmarks), and his different choices when interacting with the system in order to learn and personalize it.

3) Two IT design ideas that permits Jesper to see who he is acting for and which links and forms he used when he was last working for that particular company.

Summary and discussion

Based on action research of a workshop held with 16 participants divided into four groups, this paper contributes to the fields of ISD and HCI with knowledge about how and what types of innovation that occur in practice when using the persona/narrative scenario method for redesign of an existing IT system.

Analysis of one group’s scenario development shows that new insights and ideas emerged as the group’s conversation unfolded and that the unfolding conversation was both enabled and constrained by the scenario assignment, the group’s focus on the persona, and their use of the old system and the paper-based prototype of the new system as reference points. Analysis of all four groups’ developed scenarios and the oral presentations here of, shows that innovation occurred via the groups’ different approaches to scenario development.

The four groups used three distinctively different approaches. The approaches differed with regard to the form of the developed scenario, its oral presentation as well as its level of abstraction and/or empathy.

  • Approach 1: One group presented an oral scenario as a simple story. The outcome was an abstract scenario that generated IT design ideas.
  • Approach 2: Two groups wrote a short scenario and presented it as a more enhanced oral story. The outcome were scenarios with a medium level of abstraction and some empathy that primarily generated IT design ideas, but which also led to some understanding of the user’s broader context and information needs.
  • Approach 3: One group wrote a detailed scenario and read it out load as an elaborate story. The outcome was a very concrete and empathic scenario that provided understanding of the user’s thoughts, and feelings. New ideas concentrated on the textual communication to the user when interacting with the system.

The different characteristics of the three approaches to scenario development and presentation seem to lead to different types of innovations, i.e. IT design ideas and/or understanding of users. In particular the form of the developed scenario – whether it was merely an outline of or a fully written story – seems to play an influential role for the resulting type of innovation.

Even though all groups generated new and different types of ideas and understandings, barriers for their ability to innovate emerged because:

  • They relied on existing IT oriented artifacts, which made it difficult for them to come up with completely new IT design ideas. This issue is probably more pronounced in this case concerned with IT redesign than it would be in IT design. In general, the use of scenarios for redesign and the special challenges her of receive scant attention in the existing literature.
  • The groups did not seek to clearly identify, define, and solve the problems their persona might experience when using the system. The tendency to develop very optimistic scenarios that focus on actions and solutions rather than problems and conflicts has not, to our knowledge, been theoretically or empirically explored.
  • The groups talked a lot more than they wrote and they had problems capturing their ideas and understandings, and especially in the form of a written story.  Our research shows that scenarios support a focus on the system and the user’s interaction with the system and might spark discussions of the broader context of use, e.g. marketing and information needs. However, issues related to the broader context are not easily included in the actual story.

CONCLUSIONIn the future workshop facilitators have to consider that different approaches to scenario development and presentation lead to different types of innovation. Moreover they have to be aware that there might be barriers for innovation, and to overcome these, that participants have to be assisted.

For these reasons we will in our future research of similar workshops, where the persona/narrative scenario method is used for both IT design and redesign, address the identified barriers for innovation. The aim is to experiment with and analyze the results of different ways of helping workshop participants look beyond existing IT oriented artifacts, e.g. by ‘forbidding’ access, and to assist them in writing more and focusing more on the problematic issues of the scenario, e.g. via: a) use of a more structured scenario assignment that consists of two templates, one for taking notes as input for the story and one for writing the story, and/or b) by developing first, an optimistic and second, a pessimistic version of the scenario.

REFERENCES

1. Abbott, H.P. The Cambridge Introduction to Narrative. The Cambridge University Press, Cambridge, 2002.
2. Avison, D. and Fitzgerald, G. Information Systems Development: Methodologies, Techniques and Tools, 4th ed. McGraw-Hill, Maidenhead,
UK, 2006.
3. Baskerville, R. and Wood-Harper A.T. Diversity in Information Systems Action Research Methods. European Journal of Information Systems,
7, (1998), 90-107.
4. Bliss, D. Narrative scenarios as a design tool. http://www.davidbliss.com/viewEntry.asp?unique_id=232
5. Bruner, J. Acts of Meaning, Harvard University Press, London, 1990.
6. Bødker, S. Scenarios in User-Centered Design – setting the stage for reflection and action. Interacting with Computers, 13 (2000), 61-75
7. Carroll, J.M. Making Use – scenario-based design of human-computer interactions. The MIT Press. Cambridge, Mass., 2000.
8. Egri, L. The Art of Dramatic Writing. 2nd ed., Simon and Schuster, N.Y., 1960.
9. Garcia, R. and Calantone, R. A Critical Look at Technological Innovation Typology and Innovativeness Terminology: a Literature Review. The
Journal of Product Innovation Management, 19, (2002) 110-32
10. Giddens, A. The Constitution of Society: Outline of the Theory of Structuration, University of California Press, Berkeley, USA 1984.
11. Hasdogan, G. The role of user models in product design for assessment of user needs. Design Studies, 17, (1996) 19-33
12. Hirschheim, R. and Klein, H. Four Paradigms of Information Systems Development. Communication of the ACM, 32, 10 (1989), 1199-216.
13. Jarke, M. Scenarios for Modeling. Communication of the ACM, 42, 1, (1999), 47-48.
14. McKay, J. and Marshall, P. The Dual Imperatives of Action Research, Information Technology & People, 14, 1 (2001), 46-59.
15. Nielsen, L. Engaging Personas and Narrative Scenarios, Vol. 17, PhD Series. Samfundslitteratur, Copenhagen, 2004
16. Nielsen, L. and Madsen, S. Using Storytelling to Reflect on IT Projects. Journal of Information Technology Theory and Application (JITTA),
7, 4, (2006). 35-47
17. Potts, C. Using Schematic Scenarios to Understand User Needs. In DIS. ACM, USA, 1995.
18. Pruitt, J. and Adlin, T. The Persona Lifecycle : Keeping People in Mind Throughout Product Design. The Morgan Kaufmann Series in
Interactive Technologies. Morgan Kaufmann, San Fransisco, 2006.
19. Truex, D., Baskerville, R. and Travis, J. Amethodical Systems Development: the Deferred Meaning of Systems Development Methods.
Accounting Management & Information Technologies, 10, 1, (2000), 53-79.