How can Personas be useful for developers??

Christina Braz asks:

I have just finished to read your article about personas on the Web. Although I agree with your statements I still have a question in my mind: How do Personas can be useful for developers?? You provide personas in order to developers start to develop an application. I am in the process of developing personas for a new security application and I have heard from someone else a quotation from one of our developers: “I don’t care about personas at all. I simply don’t use it.”

Christina Braz | Senior Software Engineer, UXD Team |

Answer: Most developers are not involved in the decision about using the personas and do not know how to use them. To put personas posters on the wall or quotes on mugs are just not enough.

In my experience what do help is to let the developers experience the strength of method when a persona description is put in action in a scenario. I do scenario workshops with the developers. In the workshop they learn to use the personas and they experience how thinking about personas gives them new insights for system demands and requirement specifications. Finally we talk about how they can move from the scenario descriptions to e.g. use cases or how they can use personas in their use cases.
So the short answer is Training and experiencing clear the way.

Persona and Scenario Practitioner Inquiry

Nick Trendov wrote:Lene,as a story teller I appreciate your persona descriptions highly.I have used stories, personas and scenarios for over 15 years in business and will teach an advanced Analytics and Scenario Analysis for Competitive Advantage at the University of Toronto in early 2008.

My contribution to the topic is the ability to link stories and numbers via personas with this simple mantra–

Tell a story twice and a process is documented, three times and software is written, four times and brand value is created, five times and a measure or KPI is built.

Any suggestions to persona or scenario links would be appreciated, especially any work that may be related to the ability to deliver knowledge or training in a highly accelerated manner.

My goal for the class is to use my persona and scenario experience to deliver knowledge and tools to the class on the same topic very, very quickly.

Good luck with your work!


Your approach is very interesting. I have recently started to cooperate with Zentropa Interactive, a branch of the Danish Film company Zentropa, to add more expertise on storytelling to my personas courses. A year ago I did a survey on personas and scenario articles on the net. More have come since then, but you can find the list of articles here.

I am not sure you will find what you are looking for as most articles are from a IT perspective. The one who has written most extensively about scenarios in IT is John Carroll, maybe you will find some of his works useful. He does not have the personas perspective though.

Personas – Communication or Process?


Personas is viewed as a method for communicating user data to all members of the design team and customers, but maybe it should rather be viewed as a process method that ensures a user centered design process.
Personas are fictitious descriptions of users based on field data. Personas encourage a user-centered design process. When design solutions are discussed the persona is inserted into various scenarios that form the point of departure for design decisions. The design of the personas method varies. Cooper, with the introduction of the goal-directed method, emphasizes detailed user descriptions (precision), while Pruitt and Grudin[12] focus on accuracy through relations to field data. The precise persona approach sees the advantages of the method as its ability to focus design and its ability to end discussions in its capacity of being a communication tool, [1], [2], [3]. The accurate approach [4], [11], [10] focuses on a strict relationship between data and what is communicated in the personas description. Focus areas in the descriptions are: computer skills, market size and influence, activities a typical day or week in the user’s life, the persona’s fears and aspirations. Added are strategic and tactical reflections. Both view the method as a communication tool for data.


The question of seeing a method as a communication tool implies a communication model of sender, message, media, and receiver [6]. In the personas method this can be seen in the attitude towards how the personas are created and communicated; someone translates the data into personas descriptions that are communicated to the design team via campaigns, e.g. slideshows, posters, emails, mugs [12] or as [11] puts it: “information about your complete personas is sent off into your organization”. This sender receiver model obscures one of the biggest challenges in the personas methods: how to get buy-in for using the method from the whole organization. Rather than seeing the methods as a communication tool, it could be viewed as a process tool – a movement, or a designed sequence of changes, towards a user centered design involving all parties in the design process.


From a practical and a research perspective I propose a model that views the personas method as a process. In the following I will go through the model from a process perspective.

3.1 Step 1: Finding the Users

The initial step is to get hold of as much knowledge of the users as possible. The data can originate from several sources: interviews, observations, second hand information, questionnaires, reports, cultural probes etc.

3.2 Step 2: Building a Hypothesis

Working with the personas method is focusing on users in a certain project context or domain and building a hypothesis of how the context might influence what constitutes a persona and the number of personas.

This is illustrated in the following example. A project for a national Danish authority concerning redesign of a web portal for business reports to different governmental authorities. The national authority had a tradition for dividing Danish businesses into categories of size and trades. When using the personas method this division of businesses did not make sense. The domain is not business size or trade, but reporting. What mattered is how big the company is – big companies have dedicated staff to do the reporting, small companies have staff where reporting is a minor part of their job. Another factor is whether the person who reports is employed within the company or is a consultant [9].

3.3 Step 3: Verification

In the step ‘Verification’ the focus is on finding data that supports the initial patterns and at the same time supports the personas descriptions and the scenario writing e.g. what are the users values? What are their attitudes towards the system/site? The personas method is fundamentally a qualitative method and as such it requires several phases of looking at the result from both a partial and total perspective. In ‘Verification’ the partial result is tested to see if it obtains meaning in comparison with the overall result [5]. From a process perspective this test can be facilitated by involved members of the design project.

3.4 Step 4: Finding Patterns

Finding patterns is a categorization of the data into meaningful patterns that can support the personas descriptions. From a process perspective it is of importance to show the categorization to other team members, project partners etc.

In the above mentioned case we conducted a workshop with project partners and report suppliers in order to get their approval of the findings and patterns. This gave them not only an understanding of the underlying data and their comments to the interpretations, but provided also their support of the method.

3.5 Step 5: Constructing Personas

This step is not only a description of users, but includes an awareness of the final goal of the method; to create design solutions that takes the needs of the persona as starting point [7]. The fifth step might enhance buy-in. Pruitt and Adlin [11] address a “you” – the author of personas descriptions – in their book, when writing about this step. The personas method should rather be perceived as a collective process where everybody should understand how the descriptions came about and what they can be used for. If different team members are allowed to be part of the writing process they feel ownership of the personas. Afterwards the descriptions can be rewritten by a single person to ensure homogeneity in writing and presentation.

3.6 Step 6: Defining Situations

This step is a preparation for the scenarios. Here the situations in which the persona will use the system/site are described. Again it is a step where inclusion of partners can prove valuable for the process of adapting the method.

3.7 Step 7: Validation and Buy-in

To ensure that all participants agree on the descriptions and the situations two strategies can be followed. 1: ask everybody their opinion. 2: let them participate in the process. Having a process view helps create sessions where as many stakeholders as possible can be involved in the developing the personas and in using them for design.

3.8 Step 8: Dissemination of Knowledge

If the personas are not disseminated to participants they are not worth anything. It is not only the personas that needs to be distributes to everybody, but also the data – the foundation document [11], [4].

3.9 Step 9: Creating Scenarios

The personas method proves valuable when a persona enters a scenario. Teaching designers to think in persona-focused scenarios is part of the process. If they are not taught, the method might not be used by the individuals during the design phase where personas advocates are long gone.

3.10 Step 10: Ongoing Development

Lastly information on the personas should be updated [8]. It is crucial that not everybody is able to change the information, but knows whom to contact. I recommend having a personas ambassador who looks into the descriptions and who project participants can contact if they find irregularities in the descriptions. It is also the ambassador’s duty to let the personas die when they have outlived their purpose [11].


This project model is a proposal. The insistence on a process view in the method seems to clear some of the problems reported in communicating the method to designers [8]. To refine the process and to test it further studies are needed.


[1] Cooper, A. The Inmates Are Running the Asylum. SAMS, Indianapolis, 1999.

[2] Goodwin, K. Perfecting your Personas., 2001.

[3] Goodwin, K., Getting from Research to Personas., 2002.

[4] Grudin, J. and J. Pruitt. Personas, Participatory Design and Product Development. In PDA 2002, Malmoe, 2002.

[5] Kvale, S. InterView. Hans Reitzel, København, 1997.

[6] McQuail, D. Audience Analysis. Sage, London, 1997.

[7] Nielsen, L. Engaging Personas and Narrative Scenarios, PhD Series. Samfundslitteratur, Copenhagen, 2004.

[8] Nielsen, L. Then the picture comes in your mind of what you have seen on TV. In The 5th DHCIR Symposium, Copenhagen, 2005.

[9] Nielsen, L., E. Landbo, and A. Vorre Hansen. Personas for – beskrivelser af personas, orbitter og deres tilknyttede data. Snitker & Co, 2007.

[10] Olsen, G., Making Personas More Powerful., 2004.

[11] Pruitt, J. and T. Adlin. The Persona Lifecycle. The Morgan Kaufmann Series in Interactive Technologies. San Francisco, 2006.

[12] Pruitt, J. and J. Grudin, Personas: Practice and Theory., 2003.

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.


The end goal of using personas is to, so to speak, let the persona enter a scenario and this way explore the interactions and design through the eyes of the persona.Scenarios do not possess a single definition and in the literature a wide range of different scenarios are mentioned. They serve different purposes and are to be used at different points in the design process. Sabine Madsen and I have tried to get an overview of the different kinds of scenarios, mentioned in the current literature.

In my experience the biggest challenge is between problem scenarios (springboard stories, point of pain stories) and idea generating scenarios (context scenarios, key scenarios). I often find the describing the present problems in a scenario disturbs the idea generation and the possibility to clean the slate. This prevents knowledge that the problems and challenges might not be with the system, but in the context. Or that an IT system might not be the answers to the problem, – (e.g. writing a proper manual, as I have encountered in connection to a system). Problem scenarios are really good at pointing to problems with the present system and creates space for creating solutions to these problems.

So far I have not found a solutions of how to manage the two kinds of scenarios at the same time. Until then I suggest to write idea generating scenarios first and problem scenarios afterwards.

The third kind of scenarios are test-scenarios (validation scenarios, narrative scenarios). I find that this is the most common form of scenario I meet when designers redesign. What they do is to explore the present site from the persona’s point of view, thereby finding problems with the present site. The problem here is that beginning a process with these scenarios might create an process of fixing problems rather than understanding the whole site in a broader context and design from the needs of the personas.

1. Cooper, A., R. Reimann, et al. (2007). About Face 3: The Essentials of Interaction Design, Wiley.

2. Quesenbury IN: Pruitt, J. and Adlin, T. (2006). The Persona Lifecycle: Keeping People in Mind Throughout Product Design. The Morgan Kaufmann Series in Interactive Technologies. Morgan Kaufmann, San Francisco,

3. Pruitt, J. and Adlin, T. (, 2006). <The Persona Lifecycle: Keeping People in Mind Throughout Product Design. The Morgan Kaufmann Series in Interactive Technologies. Morgan Kaufmann, San Francisco.

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

Cooper(1)Context scenario Explores how the product can serve the need of the persona.The most story-like scenario. Functionality and data elements can be extracted. Key path scenario Describes the user’s interactions with a product. Focuses on the most significant user interactions. Maintains attention on how the persona uses the product to achieve goals.Validation scenarioTests design solutions.
Quesenbury(2)Springboard storyShort stories that illustrate a dilemma in present time and provide a brief description of a solution..Points of pain storyDescribe a problem Key scenario Concrete illustrations of interactionswith the product.  Design map and flow diagram Explore details of an issue. Can be produced before or after scenarios.  Use caseLook at details and bridge scenarios and implementation details.  Narrative scenarioPresent entire tasks in a narrative form after the design has been developed.
Pruitt & Adlin(3)Reality mapCapture and communicate the entire end to end experience from the user’s point of viewWalk-through scenarioBased on a persona. Communicate and clarify what a feature is and does.
Mulder & Yar(3)ScenarioIdealistic visions, the persona’s documented journeys through web site. 

My Articles on Personas


Madsen, Sabine ; Nielsen, Lene. / Using Storytelling to Reflect on IT Projects. I: Journal of Information Technology Theory and Application (JITTA). 2006 ; vol. 7, nr. 4, s. 35-47

Nielsen, Lene ; Bødker, Mads. / To do or not to do : Usability in open source development. I: Interfaces. 2007 ; vol. 71, summer. s. 10-11

Bødker, Mads ; Nielsen, Lene ; Ørngreen, Rikke. / Enabling user centered design processes in open source communities. I: Usability and internationalization. Berlin : HCII / Springer Verlag, 2007. s. 10-18 (Lecture Notes in Computer Science; 4559).

Nielsen, Lene ; Chavan, Sameer. / Differences in task description in the think aloud test. I: Usability and internationalization. Berlin : HCII / Springer Verlag, 2007. s. 174-180 (Lecture Notes in Computer Science; 4559).

Nielsen, Lene. / Personas : communication or process? I: Proceedings of the 7th Danish HCI Research Symposium. 2007. s. 25-26

Nielsen, Lene ; Filskov Andersen, Steen. / Challenging the borders between East and West. I: Proceedings of the 7th Danish HCI Research Symposium. 2007. s. 39-40


Nielsen, Lene ; Ørngreen, Rikke ; Nielsen, Janni. / Engagement in Users : A New Approach to Open Source Development. I: Proceedings of the fourth Nordic conference on Human-Computer Interaction (NordiCHI 2006), Workshop 10: 3rd International Design for Engagement Conference (Idec3), 14-18 Oktober, 2006, Oslo, Norway. 2006.

Nielsen, Lene ; Bødker, Mads ; Ørngreen, Rikke. / How do you get developers to care for the itches of others? : Introducing usability to an open source community. I: Proceedings of The Sixth Danish Human-Computer Interaction (HCI) Research Symposium 2006, November 15, 2006, University of Aarhus, Denmark. Århus : Århus University, 2006. s. 13-14

Nielsen, Lene ; Madsen, Sabine. / Storytelling as Method for Sharing Knowledge across IT Projects. 2006. Konferencen: The 39th Annual Hawaii International Conference on System Sciences, nr. 39, Kauai, Hawaii, USA, 4. januar 2006 – 7. januar 2006.


Clemmensen, Torkil ; Nielsen, Lene. / Proceedings of the 5th Danish Human-Computer Interaction Research Symposium. København. 2005. 124 s. (Working paper (wp); 2005-012).

Nielsen, Lene ; Brandt, Eva. / How to use design games to create engaging personas. 2005. Konferencen: The 19th British HCI Group Annual Conference: “The Bigger Picture”, Napier University, Edinburgh, UK 5-9 September 2005,

Nielsen, Lene. / Then the picture comes in your mind of what you have seen on TV : A study of personas descriptions and use. I: Proceedings of The 5th Danish Human-Computer Interaction Research Symposium 8. november 2005. København : Copenhagen Business School, 2005. s. 68-73


Anhøj, Jacob ; Nielsen, Lene. / Quantitative and Qualitative Usage Data of an Internet-Based Asthma Monitoring Tool. I: Journal of Medical Internet Research. 2004 ; vol. 6, nr. 3, s. 16

Nielsen, Lene. / Engaging Personas and Narrative Scenarios : A study on how user-centered approach influenced the perception of the design process in the e-business group at AstraZeneca.København : Samfundslitteratur, 2004. 354 s. (Ph.D.serie; 2004-17).

For download: my ph.d – and one of my articles on personas Engaging Personas and Narrative Scenarios – 2004 – Ph.d

Nielsen, Lene. / Engaging Personas and Narrative Scenarios. København. 2004. 13 s. (Working paper (wp); 2004-016).

Nielsen, Lene. / Design Through Engagement. 2004. s. 2 Konferencen: The Fourth Danish Human-Computer Interaction research Symposium. Aalborg University, nr. 4, Aalborg, Danmark, 16. november 2004 – 16. november 2004.


Nielsen, Lene. / Constructing the User.Lawrence Erlbaum Associates, Inc., 2003. Konferencen: Human – Computer Interaction, Theory and Practice, part 2: S. 430-434 Proceedings of the Human Computer Interaction International Conference. HCII 20003, June 22-27, Crete, Greece,


Nielsen, Lene. / Scenarios : A Design Tool to Ensure User-narratives. I: Learning and narrativity in digital media. red. / Oluf Danielsen ; Janni Nielsen ; Birgitte Holm Sørensen. København : Samfundslitteratur, 2002. s. 165-181

Nielsen, Lene. / From user to character : an investigation into user-descriptions in scenarios.København. 2002. 6 s. (Working paper; 2002-1).

Nielsen, Lene; Petersen, Gregers. / Understanding users : merging video card games with model-users and scenarios. 2002. Konferencen: 8th Asia Pacific Conference on computer human interaction, Institute of Software, Beijing, China, Nov. 1-4, 2002,

Hvordan skal oplysningerne vægtes i personasbeskrivelsen

Nu har jeg igen skulle arbejde med en række personas, hvor hovedparten af oplysningerne er definerede ud fra de forskellige persona’ers forhold til IT og hvor der næsten ingen oplysninger er om andre forhold, herunder domænet. Igen er oplevelsen at personas beskrivelserne er meget svære at anvende.

Disse personas beskrivelser indeholder oplysninger om demografi: alder, ægtestand, antal børn, oplysninger om arbejdsdag og arbejdsgang samt oplysninger om brug af og holdninger til IT. Men intet om forholdet til arbejdet, forholdet til arbejdspladsen, personligheds træk mm.
I det nye projekt vil vi gerne undersøge personaernes holdninger til kommunikation og kommunikationsgange, men da der ikke er nogle oplysninger om forhold til arbejdet og arbejdspladsen er det pludselig meget svært at sige noget andet end om forhold til IT. Det betyder at disse personas er meget lidt brugbare. På trods af, at vi er indenfor det samme domæne – arbejdsplads kommunikation.

Når man laver en personasbeskrivelse skal den kunne bruge af rigtig mange forskellige personer, der er involveret i et givent projekt, f.eks.

  • Ledelsesgruppen, hvor beskrivelsen er et udtryk for en strategisk beslutning om at netop disse personas beskriver vores brugere
  • Projektgruppen, der skal kunne leve sig ind i beskrivelserne og bruge dem til at træffe overordnede beslutninger om hvilken retning projektet skal bevære sig i
  • Designere (system og grafik), der skal kunne leve sig ind i beskrivelserne og bruge dem til at træffe detailbeslutninger
  • Testledere, der skal kunne rekruttere brugere til test på baggrund af personasbeskrivelsern

Når man ser på disse meget forskellige brugsmåder er det klart at det skaber store krav til personasbeskrivelserne, hvor der skal være et meget nøje forhold mellem de personlige beskrivelser, der giver indlevelse og de domæne faglige beskrivelser, der giver indsigt. Det skal være muligt for:

  • Designere og projektgruppe at kunne engagere sig i beskrivelserne, forstå arbejdsgange og brug samt den kontekst som brugeren befinder sig i.
  • Testlederen skal kunne gennemskue de data der ligger til grund for beskrivelsen, og som kan bruges i en rekruttering.

Det stiller krav til personas beskrivelsen, men det er ikke umuligt at honorere når bare man tænker på hvad personas beskrivelsen skal bruges til og hvem den skal bruges af.

Alle bruger personas

Her er et uddrag fra en artikel i Information om den danske stand på EXPO 2008.

“Hotdog fra grunden

I køkkenet på den danske stand var der svedagtig travlhed. Man havde ikke inviteret smarte kokkedrenge, men medlemmer af en fagforening med 8.000 medlemmer, Kost- og Ernøringsforbundet, et helt usødvanligt fagforeningsinitiativ. Konceptet er dansk hverdagsmad med henblik på alt fra børneinstitutioner og hospitaler til plejehjem og sportsfolk, så det kan blive mere spøndende. Samtidig får medlemmerne nogle erfaringer, som de kan bruge i deres arbejde senere, en slags efteruddannelse.

Man opererer med fire ‘persona’, fiktive personer, fortøller Mary-Ann Sørensen, der er Mad- og Måltidschef i Jammerbugt Kommune. Hugo på 80 vil helst have det hele serveret, mens andre gerne vil prøve noget nyt og derfor lører at bygge deres egen kartoffelmad eller hotdog op fra grunden – ved hjølp af en ‘pixibog’ med transparente sider, der viser hvordan. En kok fra Madeleines Madteater er også inde over.”

Hele artiklen her:

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,
Lene Nielsen, Snitker & Co., Bredgade 21B, 2160 Copenhagen K,

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.


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 case

It is the strategy in Denmark that all communication between companies and government is to be digital in the near future. 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). 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 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.


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, 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 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, 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 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 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 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 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 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 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, e.g. group two focused on Michael’s use of the existing system rather than of the new, 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 During the scenario development session, the group had access to and used a number of artifacts, i.e. the old, a paper-based prototype of the new, 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 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 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 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 might deal with bookmarks and the group continued their conversation by drawing on the old 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, 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, 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 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 is on the 2nd January 2008. This lead to discussions of whether Jesper knows that 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 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 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, 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]”, 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, 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 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 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 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 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 The need for top banners was a new idea that came about because the group members realised that when using the old 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’s main page. Moreover, the group agreed that when Jesper starts using the new 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 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 and the paper-based prototype of the new 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 user, his motivations for quick learning and personalizing of (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.


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.
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.