Kategori: English

ABSTRACT

By Sabine Madsen, Lene Nielsen

In this paper we explore the persona-scenario method as a means for requirements determination. More specifically, we investigate how the method can support groups of diverse ISD project participants in constructing and presenting multiple stories that complement each other in generating many, new, and shared understandings and design ideas. As persona-scenarios are stories about personas using IT systems we draw on narrative theory to define what a persona-scenario is and which narrative elements it should consist of. The conceptual clarification is used as an analytical lens for understanding an empirical study of a workshop that was 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 develop persona-scenarios about the future use of e-reports. A key finding is that despite our inherent human ability to construct, tell, and interpret stories it is not easy to write and present a good, coherent, and design-oriented story without methodical support. The paper therefore contributes to the field of ISD with theoretical and empirically grounded guidelines that delineate a) what a design-oriented persona-scenario should consist of (product) and b) how to write it (procedure) in order to generate and validate as many, new, and shared understandings and design ideas as possible (purpose).

Download the full paper

Tags: e-reporting, information systems development, narrative theory, Personas (DK), scenarios, Storytelling

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!

Answer:

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.

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.

“Think of segmentation as the art of finding patterns and stories in the data.”
The User Is Always Right (2007), Steve Mulder and Ziv Yaar

Som tidligere nævnt er et af de væsentligste kriterier for godt underbyggede personas at data materialet er i orden, men det sværeste er at finde ud af hvor mange personas man skal have og hvordan man se dette ud fra data. Ovenstående citat angiver lidt af arbejdet med at finde en klynge eller et segment på baggrund af data – det involverer en form for kunst.

Læser man Kim Goodwin fra Cooper.com så anbefaler hun at man opstiller et modsætningspar på en skala som man så kan sige hvor mange brugerne der befinder sig hvor på den givne skala. Dette gentages for en lang række parametre og når man er færdig står man med et billede af brugerne. Denne metode forudsætter naturligvis at man kan opstille modsætningspar for sine brugere, hvilket ikke altid giver mening. Hvad man skal gøre afhænger naturligvis også hvilke metoder man bruger, men en god måde at få mening i data er affinitetsdiagrammer: Man skriver stikord på post-it og grupperer disse. Pludselig står man med en række sammenhænge, der kan udtrykke forskellighederne. Ud fra forskellighederne kan man nu danne en hypotese om hvordan forskellighederne kan udtrykkes i pers
Da jeg i forbindelse med min ph.d. arbejdede med astmatikere og deres pårørende fandt vi ud af at der var 4 forskellige grupper: de der kontrollerede deres sygdom, de der negligerede deres sygdom. Mødre der kontrollerede deres børns sygdom og mødre der var emotionelt berørte af at deres børn var syge. Astmatikerne var udtryk for et modsætningspar, mens mødrene ikke var det. I et for nyligt overstået projekt fandt vi 3 forskellige kategorier for folk der bruger trafikinformationer og deres forskelligheder ville have været svære at rubricere i modsætningspar.

Så på mange måder har Mulder og Yaar ret – det er en kunst.

Personas are never alone in the world. They are surrounded by people who influence their decisions and jobs. I call these influencers for “satellites” as they float around the persona – it can be a parent who buys a mobile phone for a child, a teacher who decides to use an IT system in class, or a system manager who is responsible for a system is installed. The satellites should be described and play a role in the scenarios. The descriptions should not be as thorough as the personas descriptions and the satellites do not necessarily have a name, but they are important because of the function they possess – often as either helper or antagonist. 

In the redesign of Virk.dk, a website where companies report digitally to governmental bodies, we found a number of people who influenced the work of the ones doing the actual reporting, especially when it came to acquisition of a digital signature. We identified three satellites: the boss, the IT systems manager, and the person receiving the digital report. The three satellites where described in a brief form that lacked personal details, they had a name and a photo. The three satellites had very different influence on the four personas identified in the project.

ABSTRACT

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

2. COMMUNICATION OR PROCESS

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.

3. TEN STEPS – A PROCESS MODEL

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

4. CONCLUSION

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.

5. REFERENCES

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

[2] Goodwin, K. Perfecting your Personas. www.cooper.com, 2001.

[3] Goodwin, K., Getting from Research to Personas. www.cooper.com, 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 Virk.dk – beskrivelser af personas, orbitter og deres tilknyttede data. Snitker & Co, 2007.

[10] Olsen, G., Making Personas More Powerful. www.boxesandarrows.com, 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. www.research.microsoft.com, 2003.

The number of articles written on personas are immense. The value of the articles is debatable as most are based on “best practice” on a single case.

A couple of books has been published: Alan Cooper started in 1999 with his “The Inmates Are Running The Asylum”, recently “About Face 3.0″ arrived, written together with Robert Reiman and David Cronin. I wrote my dissertation in 2004 “Engaging Characters and Narrative Scenarios”. In 2006 Adlin and Pruitt released: “The Personas Lifecycle”. I 2007 Mulder & Yarrs published “The User Is Always Right“.

During the summer of 06 I tried to collect what I could find on the net. The result is an enormous list that I willingly share with others. More has arrived and will be added (when I find the time). You can see the list here in PDF.

An interesting pod cast on how personas can be useful to the open source community behind TYPO3. Mette Bjødstrup shows Kasper Skårhøj, who is one of the core developers, the process behind the personas and Kasper tells how he can relate to the descriptions. Down load at:
http://castor.t3o.punkt.de/files/personas.m4v

For download: my Ph.D – dissertation
Engaging Personas and Narrative Scenarios – 2004 – Ph.d

Having worked with personas before the method ever came to be known as personas there are, from my research and practical experience, three important areas that have to be considered: the data material, engagement in the personas descriptions, and buy-in from the organization which is part of the development process whether it is redesign or a development from scratch. This is the rationale behind my development of 10 steps to personas, an attempt to cover the entire process from initial data gathering to ongoing development.

In the following I will briefly outline the 10 steps. Any project that uses personas does not necessarily need to follow all 10 steps as long as the responsible party knows the consequences of skipping a step.

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.

In my experience large companies have often a lot of information about the users, reports from marketing, call centers etc. these can in some extend substitute real life meetings with users, but they also create problems as they do not focus on the subject that the project is about. This might become visible in the next step.

Step 2: Building a Hypothesis
Working with the personas method is to focus on users in a certain context which originates from the project. Often companies have a certain way of talking about their users that does not take into consideration the different context the users might be in when using a website or a system.

In a recent project for a national Danish authority concerning redesign of a web portal business reports to different governmental authorities, the national authority had a tradition for dividing Danish businesses into categories of size and trades. From interviews with staff in the call center and reading of several reports a hypothesis was formed. The former division of businesses did not make sense in this project, as it does not matter which trade the one who has to do the reporting is in. What matters is how big the company is and whether the persons who reports are employed within the company or are consultants. Earlier on a number of surveys had been a conducted, but none of these had this division in mind. In this step we reread the surveys from this new perspective and formed the initial hypotheses.

Step 3: Verification
In my experience the most difficult task in persona project is “how to cut the cake” – coming from data to a decision of how may personas descriptions to include. This takes several of the 10 steps and involves more than a group of consultants or project members to just hand over some descriptions.

In “Verification” the focus is on finding data that supports the initial patterns from external sources e.g. research reports or in-house knowledge e.g. confronting partners with the hypothesis. It is also necessary to focus on if the data is able to support the personas descriptions and the scenario writings.

The persona method requires a certain kind of information that can help generate engagement in the descriptions and support scenario writing e.g. what does the users like and dislike?, what are their values?, what are their attitudes towards the system/site?, in what conditions will they use the system/site?

The verification step is to look at the data are again and assess whether they support or go against the initial data.

Step 4: Finding Patterns
My inspiration in this and the previous step originates from making sense of data in qualitative inquiries. The way you know that you are on the right track is when others can follow your argumentation and others can come to the same result. In order to do so, it becomes important to show the final patterns to other team members, project partners etc.

Step 5: Constructing Personas
A crucial step is what to include in a personas description and how to avoid creating stereotypes. I have quite often seen personas descriptions that either depict super humans or stereotypes that is difficult to engage in. In this phase you must remember that the whole purpose of personas is not to describe users as such, but to create solutions that take the needs of the persona as a starting point.

Drawing on knowledge from fictional writing of characters 5 areas need to be present in the description, not mentioned specifically, but possible for the reader to deduct from the description.

– Body (a photo or a description of how the person looks creates a feeling of the person as a human being, posture and clothing tells a lot about the person)
– Psyche (we all have an overall attitude towards life and our surroundings which also influence the way we meet technology e.g. is the persona introvert or extrovert)
– Background (we all have a social background, education, upbringing which influence our abilities, attitudes and understanding of the world)
– Emotions and attitudes towards technology and the domain designed for
– Personal traits. This one is tricky, in fictional writing there is a distinction between flat characters and rounded characters. The flat character is characterized by having only one character trait which is reflected in all actions the character does and creates a highly predictable character close to the stereotype. The flat character is difficult to engage in. The rounded character has more than one character trait, is not predictable and creates engagement.

When writing personas is becomes essential to avoid the stereotype and to create descriptions that the project team members can engage in. One way to avoid the stereotype is to look for information that repeats the same trait.

In a case the persona to be described wanted to be in control of her illness. From this information the writers created a female persona who worked for the tax authorities. This came to reflect her attitude to life she wanted to be in control of everything, she was overweight and had few friends. For them the information of being in control created a negative attitude towards the persona that was repeated in all subsequent information.

The fifth step is also a step that might enhance buy-in. In my experience it is few organizations who allow team members to be part of the writing process. Instead they use consultants or the usability department to write the descriptions. The personas method should rather be perceived as a process where everybody should understand how the descriptions came about and what they can be used for. If you allow different team members to be part of the writing process they feel ownership of the personas. Afterwards they can be rewritten by a single person to ensure homogeneity in writing and presentation, but it pays off later to include more in the writing process – or as we did in a project, to let the participant choose the pictures for the personas.

I am fully aware that not everybody can be part of the process, newcomers arrive and many companies might be involved. Nevertheless, if the personas are not disseminated to participants they are not worth anything. It is not only the personas that need to be distributed to everybody, but also the data behind (the foundation document as Grudin, Pruitt, Adlin calls it) and, not least, how and for what you are to use the personas. Many projects forget to inform and teach developers and designers how to use the personas, how to think in scenarios, or how to use them in the use-cases.

Step 6: Defining Situations
As mentioned earlier the real purpose of the personas is to create scenarios from the descriptions. This step is a preparation for the scenarios where it is described in which situations the persona will use the system/site or which needs the persona has that will lead to a use situation. Each need or situation is the beginning for a scenario.

Step 7: Validation and Buy-in
To ensure that all participants agree on the descriptions and the situations two strategies can be followed: ask everybody about their opinion and let them participate in the process. Often the persona method is viewed as a means for communication of users needs to developers and others, but is as much a process that ensures a user-centered development. 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.

Step 8: Dissemination of Knowledge
I am fully aware that not everybody can be part of the process, newcomers arrive, a row of companies might be involved, but 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 behind (the foundation document, see Grudin, Pruitt, Adlin). Not least is how and for what you are to use the personas. Many projects forget to inform and teach developers and designers how to use the personas, how to think in scenarios or how to use them in the use-cases.

Step 9: Creating Scenarios
Personas has no value unless they enter a scenario. A scenario is like a story, it has a main character (the persona), a setting (somewhere the action takes place), it has a goal (what the persona wants to achieve), it has actions that lead to the goal (interactions with the system/site/device), and it has obstacles that hinders the way to the goal.

I have seen quite a number of what I call happy scenarios, where a device solves all problems. Try to read this description of Mrs Tahira Khan and how she overcomes her diabetes and you will see what I mean. It is neither a realistic nor a convincing scenario that makes a 65-year old woman, who recently traveled to the UK, suffers from undiscovered diabetes, hardly understands the English language, and has relatively poor literacy in her own language, overcome her diabetes with an electronic device.

Step 10: Ongoing Development
Lastly I recommend updating information on the personas. This can be done if user tests suddenly show new results or if something changes in the personas environments. It is crucial that not everybody is able to change the information, but that everybody knows whom to contact if a change is necessary. I often recommend having a personas ambassador, who looks into the descriptions now and then and who project participants can contact if they find irregularities in the descriptions. And, as Adlin and Pruitt recommend in ‘The Personas Lifecycle’, to let the personas die, when they have outlived their purpose.

Literature

Pruitt, J. and T. Adlin (2006). The Persona Lifecycle : Keeping People in Mind Throughout Product Design.

San Francisco, Morgan Kaufmann.

Pruitt, J. and J. Grudin (2003). Personas: Practice and Theory. 2003.

3 Responses to “10 Steps to Personas”

1. Peter SjølinDecember 15, 2007Først og fremmest et fantastisk indlæg, det har virkelig hjulpet mig meget i mit datalogi projekt på HA(DAT) ved handelshøjskolen i København.Dertil vil jeg gerne takke for indlægget er frit tilgængeligt her på bloggen.De bedste hilsner.
   Peter Sjølin

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

	PRODUCT PLANNING	DEVELOPMENT PHASE	TEST PHASE
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 view	Walk-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.