10 skridt mod personas

lenesillustration1.jpg

Af en eller anden grund så er der en efterspørgsel efter at metoder præsenteres i trinvis modeller. Modeller er overskuelige, de skærer mellemregninger væk og de giver den uøvede mulighed for at følge modellen slavisk, mens den øvede kan tage udgangspunkt i modellen, men forandre den efter behov. Derfor har jeg brugt mine egne erfaringer og inspiration fra litteraturen på at udvikle en 10-trins model. Modellen har tvunget mig til at reflektere over, hvilke områder jeg mener er vigtigt i personas udviklingen og også over hvilke rækkefølge jeg mener er vigtig.

Adlin og Pruitt har i deres model brugt en metafor der tager udgangspunkt i livet fra undfangelse til fødsel, men jeg er ikke så fantasifuld, så jeg har bare valgt 10 skridt.
De 10 skridt er:

  1. Find brugerne (indsamling af data)
  2. Dannelse af en hypotese
  3. Verifikation
  4. Mønster udformning
  5. Definition og konstruktion af personas
  6. Dannelse af eksempler på situationer
  7. Validering og buy-in fra organisationen
  8. Spredning af viden
  9. Scenarier
  10. Fortsat udvikling og brug

Når jeg kigger på modellen så er der to områder som går igen og som måske kan virke meget firkantede og insisterende: pkt. 3: verifikation og pkt. 7: validering og buy-in. noget af det der er grundlaget for personas er, at de udspringer af data. At fokusere på data er også et argument der er med til at markedsføre metoden. Selvom resultatet, selve personabeskrivelsen, på overfladen ser fiktiv og fortællende ud, så er der et stort materiale nedenunder. Samtidig så sigter de to punkter på at få så mange som muligt med fra organisationen/udviklingsgruppen til at være med i beslutningsprocessen om, at det her er altså de rigtige personas som der skal udvikles til. Det giver ejerskab på længere sigt, men det stopper også mange fremtidige diskussioner om hvorfor er det netop lige disse 4 eller 5 personas der er beskrevet.

De 10 skridt kan godt se meget omstændelige ud, men det er ikke meningen at de skal tages 1 af gangen. Nogle skridt vil foregå som hop, hvor man i én og samme proces f.eks. verificerer og danner mønstre.

Jeg vil i den kommende tid beskrive hvert skridt.

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.

10 Steps to Personas

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

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

PRODUCT PLANNINGDEVELOPMENT PHASETEST 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 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. 

Personas til BabySam

Jeg bad Anne-Marie Christina Thoft om at beskrive sine erfaringer med at udvikle personas til et brugerfokuseret innovationsprojekt til babyudstyrsforretningen Babysam. Her er hendes erfaringer:

Prøv at beskrive projektet i korte træk?

BabySam er Danmarks største babyudstyrskæde med 32 forretninger fordelt over hele landet. En af BabySams nøgleudfordringer er at levere en på den ene side kundetilpasset service af høj kvalitet og på den anden side ensartet serviceydelse på tværs af salgserfaring og branchekendskab. Desuden er produktkompleksiteten og brugernes produktviden steget mærkbart de seneste år, hvilket stiller høje krav til medarbejdernes viden og kompetence.

Igennem flere afklarende workshops mellem ledelse og butikschefer samt DESIGN CONCERN og konsulentvirksomheden, GEMBA Innovation, blev dette gjort klart.

Herefter blev der indsamlet data vha. online bruger-survey, semi-strukturerede interviews med kunder i butikken, fokus-gruppe interviews i mødregruppe og endeligt idé-sessions med BabySams nøglemedarbejdere. Det har givet et solidt vidensgrundlag om kundernes behov, og de ansattes forudsætninger for at kunne genkende disse behov. Løbende blev data omdannet til fiktive brugere, personas.

Denne proces er mundet ud i
•    Koncept 1: Et uddannelsesmodul for servicemedarbejdere i at yde målrettet personlig rådgivning af kunder i BabySam-butikker med afsæt i kundernes individuelle behov. Uddannelsesmodulet er struktureret over et rollespil om rådgivningssituationen
•    Koncept 2: Et virtuelt videncenter med bl.a. en produktwiki på intra/internettet, der beskriver en lang række af informationer om produktkategorier samt et ressourcecenter om babyer og børns udvikling og behov, som særligt førstegangsfødende søger op til og umiddelbart efter fødslen.

Hvorfor blev det personas I valgte at bruge

Services adskiller sig fra produkter ved, at de er mere uhåndgribelige, konsumeres i det øjeblik, de produceres og er stærkt afhængige af personen, der yder den pågældende service. Der stilles derfor store krav til formidlingen af brugerdata ved brugerdreven serviceinnovation, da det er personalet, der skal forstå og anvende den nye viden i praksis (viden indlejres ikke i et produkt, som ved produktinnovation).

Det var derfor målsætningen, at dokumentationen skulle formidles på en måde, så den giver mening for medarbejderne i BabySam – så de kunne bære den nye viden om brugerne og deres behov ind i en bedre rådgivning. Især er det vigtigt, at salgspersonalet lever sig ind i brugernes behov både før og under de står ansigt-til-ansigt med kunden i rådgivningssituationen. Persona-metoden blev valgt, da den kan fungere som et værktøj for salgsmedarbejderne til at skabe indlevelse i brugenes univers og forstå kundernes forskellige behov for produkter, rådgivning og service. En rapport med anbefalinger ville sandsynligvis have samlet støv på reolen.

Prøv at beskrive jeres personas proces i korte træk

Persona-metoden blev valgt som en af flere metoder tidligt i forløbet under afklaring af projektets sigte og indhold. Design Concern indsamlede herefter data om brugerne og begyndte at skabe konjunkturerne af persona’erne. Disse konjunkturer blev derefter præsenteret på en strategiworkshop med BabySams ledelse og GEMBA Innovation. I en co-creation proces blev personaerne justeret og modnet, efterfulgt af indsamling af flere brugerdata. Der var flere iterationer i denne proces. Til sidste blev de færdige personas præsenteret for BabySams butikschefer på en workshop, hvor GEMBA Innovation underviste i metoden, og hvordan de skulle bruge dem fremover. Herunder blev rollespil anvendt ligesom der var udviklet et værktøj til afkodning af kundebehov.

Var der noget der var svært i processen?

Det er altid en stor fare for at personas bliver karikerede og stereotype, når de anvendes i praksis af en større gruppe. Og har vi valgt de rigtige – for mange eller for få?

Hvad var den største fordel ved at bruge metoden?

Metoden skaber engagement og indlevelse for større grupper, i såvel konstruktion som i praktisk anvendelse. Fx skabte det debat, hvorvidt bedsteforældre mm skulle fungere som en selvstændig persona eller ej. Herigennem blev bedsteforældrenes købsmønstre diskuteret på en meget struktureret måde af flere end blot dataindsamlerne (Design Concern og GEMBA Innovation) og ledelsen i BabySam. En diskussion som er berigende for forståelsen af kunderne, deres forskellige behov og hvordan BabySam møder dem med produkter og rådgivning.

Hvis I skulle gøre det igen, var der så noget I ville gøre om?

Vi ville gøre en større indsats for at undgå karikerede og stereotype personas. Alene dét at give personas navne, der adskiller sig væsentligt fra almindelige navne, gør personas nemmere at huske og tillægge dem flere nuancerede følelser. De skal adskille sig markant fra hinanden ved forskellige behov for rådgivning og service.