Personas – några exempel och reflektioner

En presentation över ämnet: "Personas – några exempel och reflektioner"— Presentationens avskrift:

1 Personas – några exempel och reflektioner
Henrik Artman KTH

2 Hur känns det att vara Persona?
Dessy Design – Teknik för alla – inte bara ord! 26 år Mål: Lära sig nya metoder för att utveckla ny teknik Lära sig om hur människor tänker om teknik I framtiden vill Dessy gärna arbeta som konsult med kreativa projekt Beskrivning: Dessy är en kreativ person. Dessy spelar gitarr och skriver en hel del låtar på fritiden. Hon spelar dessutom i ett rockband tillsammans med sin bästa vän Karin. Den senaste tiden har KTH-studierna upptagit det mesta av hennes tid men hon drömmer ofta om att kunna återuppta olika kreativa former. Dessy går kursen Människa-Datorinteraktion för att hon tänker sig en framtid som utvecklare av interaktiva datorsystem. Hon har valt kursen för att hon gärna vill bredda sitt teknikkunnande och se på ett nytt sätt hur man kan arbeta med teknikutveckling. Dessy bor idag i en studentlägenhet och trivs med livet i Stockholms studentliv. För 2 månader sedan träffade hon Richard på en fest hos Karin. Richard är nu hennes pojkvän. Scenario: Dessy vaknar lite sömning en torsdagsmorgon. Resttentorna är avklarade så nu ska det bli nya tag med en ny termin. Även om sommaren har varit bra och avslappnande så skulle hon kunna behöva ytterligare två dagar för att ladda om batterierna efter tentapluggandet. Efter frukost går hon in på KTH:s hemsida och letar reda på schemageneratorn för att planera de närmaste veckornas pluggande. Där skriver hon en av sina kursers namn och hoppsan: föreläsning idag klockan 15. Hon skriver ut schemat på sin bläckstråleskrivare. Aj då, utskriften får inte plats. Hon uppmärksammar för femtioelfte gången att man måste trycka på länken ”utskriftsvänlig version”. Hon skriver ut en gång till och funderar på om det finns kurser där hon kan lära sig hur man designar, för användaren, bättre system.

3 Hur känns det att vara Persona?
Pontus Problemlösare Datorer är kul! 24 år Mål Klara kursen med goda betyg (minst 4:a!) Få en klar och entydig bild över hur man kan skapa bra gränssnitt Pontus ser sig i framtiden som utvecklingsingenjör på något större företag där man kan arbeta med långsiktiga projekt. Eller kanske som speldesigner… Beskrivning Pontus har sedan länge varit intresserad av datorer och teknik överlag. Han valde målmedvetet en naturvetenskaplig utbildning. På fritiden gillar Pontus, förutom att spela datorspel, att umgås med kompisar. Pontus har spånat på många idéer för datorspel och andra högtflygande projekt. Pontus gillar att klura ut lösningar på både enkla och komplexa problem. Några har kommit på papper men de flesta är glömda. Det stora teknikintresse som Pontus har gör att hans etta i Vällingby, vilken har hyr i andrahand, mest ser ut som ett mindre ON-OFF. Han hyr lägenheten av Stina som är en nära kompis. Han gillar nya prylar och att koppla samman saker eller på annat sätt nyttja tekniken. Scenario Pontus har jobbat i ett år som utvecklingskonsult på Skatteverket. Han har just fått sig tilldelat att göra en förändring i användargränssnittet av medborgarnas skattekonto. Han sätter sig ner och börjar skissa på hur det skulle kunna se ut. I sitt första förslag inser han att han kanske låtit sina drömmar om att bli speldesigner fått påverka lite för mycket – riktigt så flashigt ska nog inte ett skattekonto vara. Han kastar skissen och börjar om. Han funderar tillbaks på hur det var när han själv använde skattekontot i samband med deklarationen. Medan han sitter där och funderar på vad som vore den bästa lösningen så minns han plötsligt sin AHA-upplevelse ifrån MDI-kursen: det han själv som teknolog tycker är bra är inte alltid det som slutanvändaren tycker är bra. Han inser att det här behöver han hjälp med och går till sin chef för att begära användbarhetsexpertis.

4 Jag-tycker-mötet – Skvadervarning!

5 En modern Skvader skapas!

6 Personas – ett sätt att se haren eller tjädern!
En metod för att; skapa trovärdig ”beskrivning” av användarna levandegör användningssituationen abstrahera från nuvarande användare ge design- och ideutrymme för utvecklare/forskare Särskilt lämplig vid otillgängliga användare Slippa långa och svåra dokument som aldrig läses

7 Användarorienterad systemutveckling
A. Övergripande kravdefiniering B. Design och analys (detaljerad kravdefiniering) 3. Användarkrav 2. Beställarkrav 1. Varumärkeskrav 6. Prototyputveckling 7. Användbarhetstest Prototyp 4. Konceptuell design Krav-specifikation 5. Teknisk kravspecificering C. Utveckling och leverans Prototyp Inga användar-centrerade aktiviteter = Lite användar-centrerade aktiviteter Mycket användar-centrerade aktiviteter 8. Implementering 9. Verifiering 10. Leverans Krav-specifikation

8 ”Som designverktyg är det viktigare att en persona är precis och specifik än riktig.”
Detta är sant men kan låta lite konstigt eftersom det är motsatsen till målet med interaktionsdesign; att designa precis rätt. Men genom att designa för en persona kommer vi hamna så rätt att de flesta användarna som vi vänder oss till kommer att bli överlyckliga. Det ska vara lätt att använda. För vem? Användaren. Termen ”användare” är för oprecis. Ett medelvärde av alla möjliga behov, som ofta är i konflikt med varandra. Har ni någonsin hört en programmerare eller er själva säga ”Tänk om någon…” EXEMPEL sid 132 Programmerare älskar ”edge cases” Det kan slå hål på en argumentation och skapar utmaningar. Men medan programmering styrs av edge cases för att inte krascha styrs interaktionsdesign av ”middle cases” Genom samma resonemang måste alla medelperosonas ut. Medelpappan in stockholm kanske har 2,3 barn men ingen i Stockholm har faktiskt 2.3 barn. Om vi använder termen användare är det risk för att vi anpassar dess semantiska mening från situation till situation Med en precis och påtaglig persona är användaren alltid närvarande i designbeslut. Var specifik När en viss persona, Peter, avgränsas från de andra genom sina detaljerade och specifika mål blir den plötsligt levande för projektteamet. Man börjar referera till den vid namn och blir en referenspunkt och bollplank för alla våra designidéer. Namn är ett måste men kan även kompletteras med foto och till och med gestalt. En persona är ett mycket kraftfullt kommunikationsverktyg. EXEMPEL sid 133 TOP För att verkligen nå framgång måste man dock få programmerarna att också sluta resonera i termer av användare och istället börja referera till de personas som finns. Detta kan bara åstadkommas genom tålmodigt användande av personas själv och genom att ALDRIG falla tillbaka till termen användare. Läs EXEMPEL sid 133 botten. SUMMERA: Idén med personas är att när vi har lyckats hitta de gemensamma nämnarna för våra målgrupper och representerat dem som personas ska vi stanna på den generella nivån och inte gå tillbaka och fråga enskilda användare. Men för att verkligen slå igenom måste vi själva ha en specifik användare som styr designprocessen. Det är personans roll. Erik Markensten, Antrop

9 Manpower (hemligt, hemligt…)
Mitt första Persona-projekt (2000) Manpower skulle lansera en rekryteringssajt Mycket hemligt Problem med att få tillgång till användare Förlita mig på rekryterare/handläggare Fem intervjuer (i samband med utvärdering…) Personas mycket rudimentära (stereotypa) Mycket fokus på att yngre är en annan människosort..

10 Fråga? Hur skulle du/ni göra?
Behöver en persona vara äkta eller trovärdig? Vad betyder det att inte kunna vara öppen med Persona?

11 Arbetsförmedlingen (kundperspektiv)
Platsbanken.se skulle förbättras Anpassning till målgruppen Man hade analyserat att många la upp CV men inte använde portalen Problem med att alla inte riktigt hade IT- och/eller språkkunskaper

12 Intervjuer och analys Inleddes med intern workshop och skapande av Persona-hypoteser 21 intervjuer med arbetssökande Vid skapande av Personas uppfattade beställare att två användargrupper (intern/press) saknades Skapade Personor med hjälp av intervjuer Analysen gjorde att man kunde urskilja två starka mönster; Från kort/långtidsarbetssökande – till om man är anställd idag eller inte… Konkret arbetssätt som fick beställare att förstå

13 Personas

14 Persona fick uppmärksamhet
Personor fick ben… utbildningsenheten såg att de kunde använda Personor som en del i sin handläggarutbildning.

15 Resultat – med olika ingångar

16 Frågor Vad betyder det att Persona får ben? Bra / dåligt?
Kan man lita på att ”beställare” har god koll på sina Persona? Var drar man gränsen för sin skepsis? Hur hanterar man när det finns korrelerade / överlappande målgrupper?

17 Kronofodgen (verksamhetsutveckling)
Ett större och internt systemprojekt Lagförändring Behov av enhetlig process Behov att kunna hantera många ärenden Historik med flera misslyckade projekt inom myndigheten

18 Från avsedda effekter till systemfunktion
Effects Target groups Use goals System functionality

19 Processbeskrivning Behovet av en enhetlig hantering
Startpunkten för process

20

21 Verbal description Namn
Namnet ska vara beskrivande för det som utförs i processen Syfte Vad ska vi göra, för vilka och varför.... Leverantör Beskrivning av dem som levererar insatsen till processen Insats Beskrivning av den information/meddelande/saker som startar processen Produkt Beskrivning av det resultat som processen ska producera Kund Beskrivning av dem som tar emot resultatet av processen Kundkrav Beskrivning av kundernas krav Villkor/regler Beskrivning Sammanfattande beskrivning av det som utförs i processteget Undantag Övrigt Kritisk faktor Förbättrings- förslag Teknik

22 Requirements – listing and ranking
Workshop - granskning av material - Personahypoteser Intervjuer – interna och externa Utvärdering av befintliga system Analys av intervjuer Scenarios Prioriterade krav - effekter och användarbehov Projektgrupp – Vi har också haft stöd av en konsult från ett företag som arbetar på liknande sätt i detta. Fredrik Andersson har stått för den kontakten och upplägget. Ansvar för genomförandet av aktiviteterna har legat hos VE. Framförallt har konsulten utbildat och stöttat Mona och Lina. Vi startade med en workshop. Vi gick igenom skuldsaneringsprocessen enligt processbeskrivningen, direktiv, nyttobedömning, rapporter om skuldsaneringen m.m. Behov och krav från verksamheten. Sedan gjorde vi en personahypotes. En persona är en typanvändare. Det handlar om att se om det finns så olika typer av användare att de behöver egna gränssnitt i IT-stödet. De olika typer av interna användare som vi identifierade var teamledare, handläggare, jurister och samordnare. Vi identifierade även externa användare. Med denna hypotes som grund genomförde sedan Mona och Lina intervjuer med totalt 17 personer från alla team. De här intervjuerna kallas kontextuella intervjuer eftersom de genomförs i personens egen kontext, dvs på personens arbetsplats, vid skrivbordet. Intervjuerna består av både frågor och observationer. Hur gör handläggaren vissa moment, vad är manuellt, vilket stöd finns från systemet. Intervjufrågorna handlar bl.a om mål med arbetet, attityder, vilka drivkrafter som finns och om behov av IT-stöd. Parallellt med de här intervjuerna genomfördes en s.k. utvärdering av SKUSAN. SUMI står för software usability measurment inventory. Det är en generell utvärdering som används för alla slags IT-system. Frågorna handlar om lärbarhet, hjälpsamhet, effektivitet, kontroll m.m. i systemet. Man får fram nyckeltal som gör att man kan jämföra olika system med varandra. Det gav en bild av hur användarna ser på sitt nuvarande system.

23 Birgitta är prioriterad handläggare. Hennes behov och mål har vägts in
Birgitta är prioriterad handläggare. Hennes behov och mål har vägts in. Nasrin är samordnare. Arbetet med typanvändare kändes lite märkligt först. Men det var ett bra sätt att kunna fokusera på användarna. Vi pratade om Birgitta, Ulla, Nasrin, Christer som riktiga personer. I vissa funktioner kunde vi tydligt se att Ulla inte bryr sig om det medan det är viktigt för Birgitta... det blir enklare att se olika användares behov utan att hänga upp sig på enskilda individer. Birgitta är ett hopkok av många riktiga användare.

24

25 Detaljerad kravspecifikation
Textbeskrivning En fungerande och utvärderad prototyp

26 Frågor Ambitiösa projekt: hur får man hela projektet att se fördelen och inte bara de som är med i Persona-delen? Går det att designa hela vägen med hjälp av Persona?

27 Nyttan – kommunikationsverktyg
Skapar enhetligt fokus mellan aktörer Formalisera dold kunskap om användarna Diskutera medvetna designval Skapar diskussion om framtiden

28 Vad har det för betydelse att man skapar Personahypoteser internt?
Finns det andra tankar kring hur man kan utveckla Persona-hypoteser?