 |
| Personan "Foliehundägaren" |
Senast pratade vi ju om workshops. Idag ska vi prata om hur vi gör för att närma oss våra användare mer och hur man kan göra för att sammanställa det man vet om användarna.
Alan Cooper skrev en gång en bok som heter "The inmates are running the asylum". Den innehåller en del underliga saker (mer om det i ett senare inlägg), men boken innehåller också en del bra grejer, till exempel den fina uppfinningen Personor och det ska vi prata om idag!
Jag vet att jag börjar låta som en gammal repig skiva (fattar ni inte referensen får ni fråga er mamma eller pappa) men det vi gör som UX-designers handlar i första hand om kommunikation. Även personor används för att kommunicera något. Och att skapa förståelse för någons behov och drivkrafter.
Vad är då en persona, sluta hålla oss på halster, Eric!!!!
Okejrå, nu kör vi.
En persona, flera personor
En persona är en sorts användarprofil, en representant för en målgrupp. Minns ni målgrupper? Vi pratade om det i bland annat inlägget om effektkartor. Målgrupper är alltså en grupp användare med likartade drivkrafter och behov och som kan bidra till att verksamhetsmålet uppstår. Och en persona är en beskrivning av en sådan.
Personor används som en sorts användar-stand in och innehåller information som hjälper dig att fatta beslut av olika slag
"Kul! Då är det bara att hitta på lite personor så kör vi sen, eller hur!?"
NEIN! Du hittar inte på personor. Det är ju helt bizarrt att ens tänka sig något sådant. En persona innehåller faktiska data, information, som du skaffat genom intervjuer och annan typ av datainsamling, såsom statistik och andra grejer. Det är alltså en korrekt beskrivning av målgruppen vi talar om här, inget hittepå-trams.
När du samlat in tillräckligt mycket kunskaper om målgruppen så kan du sedan sätta ihop en Persona.
En bra persona hjälper dig att fatta designbeslut, medan en dålig bara är jobbig och pinsam för alla inblandade. En bra persona kan innehålla information som till exempel:
- Vilka drivkrafter som finns att använda en tjänst
- Vilka saker personan ogillar med befintliga lösningar
- Hur mycket tid som spenderas med att använda en tjänst
- Vanor som påverkar användningen eller upplevelsen av tjänsten
- Inställning till saker som teknik, sociala medier eller vad det nu kan vara som påverkar användningen av tjänsten
Medan du kan strunta i grejer som inte tillför ett dugg:
- Om personan har katt eller inte
- Om personan gillar att dricka öl med polarna
- Om personan har en beggad bil
- Om personan gillar inredning.
Förutsatt att ovanstående grejer inte är direkt relevanta för tjänsten som du designar. Då ska de såklart finnas med.
Det viktiga är att personans egenskaper ska hjälpa dig att dels få förståelse för målgruppen och dels fatta vettiga designbeslut. Och inte minst: så att alla de i projektet och hos beställaren som INTE träffar användare i jobbet faktiskt får en uppfattning om vilka de bygger den här grejen åt.
Personan använder du sedan i de fall som du skulle fråga en användare eller kund om det fanns någon närvarande. Exempel:
Du ska ta fram en tjänst för djurägare och du behöver nu veta hur viktigt det är för en djurägare att ha tillgång till kontaktuppgifter till närmaste djursjukhus. Ditt team rådfrågar Personan och där ser ni att personan "Uppfattar husdjuret som en sorts luden familjemedlem". Ni drar slutsatsen att personan vill ha tillgång till kontaktuppgifter till djursjukhus. Efter en kortare diskussion kommer ni fram till att användarna av tjänsten ska kunna se vilka djursjukhus som finns i närheten av där de befinner sig, samt vilken typ av specialitet djursjukhusen har.
Ni har nu fått en gemensam bild av målgruppens (personans) behov och drivkrafter och slipper hamna i situationen att ni börjar se er själva som användare av tjänsten: "Nu hatar jag visserligen husdjur, men om jag hade katt så skulle jag..." Ja, vad skulle du? Jo, det kan jag tala om: du skulle fatta ett felaktigt beslut kring designen av tjänsten.
I morgon kommer vi sannolikt att prata om interaktionsdesign, UX-designers smör och bröd.
Personan använder du sedan i de fall som du skulle fråga en användare eller kund om det fanns någon närvarande. Exempel:
Du ska ta fram en tjänst för djurägare och du behöver nu veta hur viktigt det är för en djurägare att ha tillgång till kontaktuppgifter till närmaste djursjukhus. Ditt team rådfrågar Personan och där ser ni att personan "Uppfattar husdjuret som en sorts luden familjemedlem". Ni drar slutsatsen att personan vill ha tillgång till kontaktuppgifter till djursjukhus. Efter en kortare diskussion kommer ni fram till att användarna av tjänsten ska kunna se vilka djursjukhus som finns i närheten av där de befinner sig, samt vilken typ av specialitet djursjukhusen har.
Ni har nu fått en gemensam bild av målgruppens (personans) behov och drivkrafter och slipper hamna i situationen att ni börjar se er själva som användare av tjänsten: "Nu hatar jag visserligen husdjur, men om jag hade katt så skulle jag..." Ja, vad skulle du? Jo, det kan jag tala om: du skulle fatta ett felaktigt beslut kring designen av tjänsten.
I morgon kommer vi sannolikt att prata om interaktionsdesign, UX-designers smör och bröd.
Inga kommentarer:
Skicka en kommentar