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.
