Brugen af personas har altid været kontroversiel blandt designere og fagfolk inden for branchen. Men for nylig pressede et par praktikere på området for udskiftning af persona metode til opgaver, der skal udføres (JTBD) ramme.
En omhyggelig analyse af både persona- og JTBD-metoden sammen med indsigten fra feltpraksis får mig til at tro, at selvom der faktisk er nogle problemer med persona-metoden, hjælper denne teknik i nogle kritiske aspekter af design, som JTBD-metoden ikke er i stand til at dække.
Fra dette tidspunkt kommer et par spørgsmål i tankerne: Hvad er den bedste metode? Skal du skifte fra personas til JTBD?
For at samle det bedste fra hver, en mulig tilgang er at fusionere begge teknikkerhvilket resulterer i en hybrid løsning.
Jobs, der skal udføres, er en ramme, der kan bruges til at hjælpe med at definere et produktomfang, dets krav eller markedsføringspositionering. Det er baseret på den forudsætning, at når en person køber et produkt eller en tjeneste, køber den person faktisk ikke det, men ansætter det til at udføre et bestemt job: Folk vil ikke have en kvart tommer boremaskine, de vil have et kvart tommer hul.
Sammenfattende består et job, der skal udføres, i fire hovedaspekter:
Det første trin, udstilling, præsenterer produktets kontekst og forklarer kort hvem, hvad, hvornår og hvor (men ikke hvorfor).
I observationstrinnet identificeres den nuværende og tidligere brugers adfærd - nemlig hvilke produkter de bruger.
Situationsanalysen vedrører brugernes motivationer og bekymringer, forklarer de udfordringer, som kunderne står over for, og hvad der skubber dem mod forskellige løsninger.
Endelig handler jobbet, der skal udføres i sig selv, om det ønskede resultat, som brugeren leder efter. Det bør ikke præsentere en løsning - hverken et produkt, funktion eller krav - men i stedet en beskrivelse af, hvad brugeren skal opnå på et højere niveau.
Denne metode betragtes ofte som bedre egnet end personas til produktudvikling på grund af det faktum, at det er resultatdrevet, objektiv og målbar.
Der er mange tilgange, der kan tages til personas. Nogle er ret fattige, mens andre gør lige nok til at blive accepteret. I begge tilfælde tjener de kun specifikke formål, der ikke bør omfatte produktdesign og -udvikling.
Løst definerede personas er en teknik til at modellere brugere. De er arketyper, formaliseret som fiktive - men realistiske - karakterer. Mens mange designere hævder at bruge personas, ser vi, når vi analyserer deres praksis, at det, der kaldes „personas“, inkluderer en række meget forskellige materialer.
De oplysninger, som en persona konfigurerer, ændres betydeligt fra en designer til en anden, og så ændres naturligvis potentialet i denne teknik også. Hvis vi nøje observerer de forskellige måder at udføre personas på, kan vi identificere fire forskellige typer:
Den første type persona er faktisk ikke en persona, men en proto-person og alle følgende typer personas kan vise sig at være en ægte persona eller en proto-persona.
Proto-personas er ikke baseret på faktisk forskning, men i stedet i antagelser om brugerne. Denne type persona kræver, at de mennesker, der er involveret i at gøre dem, har indsigtsfuld viden om de virkelige brugere. Du skal ikke kun have designere eller ingeniører, der laver dem, men i stedet bør samle folk fra kundesupportafdelingen, for eksempel, ved bordet.
Proto-personas bør kun bruges som et første skridt til at vejlede yderligere brugerundersøgelser, men aldrig som grundlag for at definere produktkravene.
Den anden type personas, vi kan identificere, er empati personer. Disse er bygget op omkring en personas baggrundshistorie (en fortælling om personlivet og konteksten) normalt med et navn, alder, foto og citat.
Denne type persona kan være nyttig til at skabe empati i udviklingsteamet og hjælpe dem med at holde motivationen under projektet.
Fagfolk, der ikke har regelmæssig kontakt med kunderne, kan miste visionen om produktets anvendelighed og relevans, i hvilket tilfælde, at kende nogen, for hvem produktet vil gøre en forskel, kan hjælpe dem med at forstå deres indsats i en højere kontekst.
I sidste ende er denne type persona til ringe eller ingen nytte, når det kommer til at fastlægge produktkravene og projektplanen.
Den tredje type personas, vi kan identificere, er Markedsføring/Demografisk personer.
Mens det værste, der kan ske med en empati-persona, der bruges til andre mål udover dem, der er anført ovenfor, er, at det kan vise sig at være spild af tid, de marketing/demografiske personaer kan virkelig skade din produktudvikling (især hvis vi taler om markedsføring af proto-personas).
Markedsføringspersoner har fokus på demografi, søger at finde roden til brugerens adfærd og ønsker i disse data.
Dette er den type personas, som de fleste forsvarere, der skal gøres, rejser sig imod, da der ikke er nogen ægte kausalitet mellem demografi, mål og adfærd. De identificerede mønstre er normalt resultatet af fordomme og stereotyper.
Denne fjerde tilgang, navngivet målorienterede/designpersoner, henviser personaens baggrundshistorie og demografi til en sekundær plan og Fokuserer på mål og behov.
Disse personaer identificerer specifikt livsmål, oplevelsesmål, og slutmål, såvel som behov, frustrationer og adfærd. Denne type persona kommer meget tæt på de job, der skal udføres, metodikken, samtidig med at nogle attributter bevares, der giver personas noget af deres magt, en der går ud over at skabe empati for at motivere teamet.
Hvis du vil vide mere om målorienterede personas, anbefaler jeg dig at tjekke Alan Coopers bog Om Face.
Ser på Anmelder fra IntercomFor eksempel, en af de mest fremtrædende stemmer til forsvar for JTBD og mod personas, præsenterer de os følgende brugerhistorie baseret på en persona:
„Som en 35 gammel mand ved navn Peter vil jeg spise noget velsmagende, når jeg er sulten, så jeg ikke føler mig sulten mere“.
Selvom vi ikke kunne være mere enige med kritikeren, da hun påpeger, at den første del „Som en 35 gammel mand kaldet Peter...“ er irrelevant - da der ikke er nogen kausalitet mellem disse data og den sidste del af sætningen - dette er et persona-metodeeksempel, der bruger brugerhistorier og ikke brugerrejser.
Derfor, som vi ser, Dette argument gælder kun for markedsføringspersoner og ikke for målrettede personer/designpersoner.
Hvis det var en målorienteret persona, ville historien være anderledes:
“ Som seniorkronikepatient, der ønsker at nyde pensionering mest, vil jeg gerne være i stand til nemt at kontakte min læge når som helst, så jeg kan føle mig godt tilpas med min helbredstilstand“
Det vil kun nævne demografi, der ville have en kausalitetsrelation med personaens mål og fokusere på det ønskede resultat, hvilket gør det meget lig det job, der skal udføres.
Stadig på Anmelder fra Intercom, når der præsenteres den ækvivalente JTBD, gives følgende eksempel:
„Når jeg kun har 2 minutter til at afværge sult mellem møderne, vil jeg gribe noget, der vil være hurtigt og nemt“.
Men hvad er „let“?
Ting som „let“ eller „behageligt“ er subjektive egenskaber, de vedrører ikke selve produktet, men brugerens oplevelse med produktet, idet de er helt afhængige af brugerens egenskaber.
Det betyder, at det er umuligt at evaluere disse attributter uden at have en slags brugerprofil. Specifikt oplevelsesmål, ekspertise, viden, intellektuelle og motoriske færdigheder, for eksempel.
Lad os sige, at JTBD er „at have et sted at gemme mine filer på en måde, der er let at finde dem“. Med hensyn til design kan dette afspejle sig i en hierarkisk og velorganiseret mappestruktur eller i en simpel opbevaringsmappe med et søgefelt.
Dette bringer os til tre almindelige projekt-faldgruber, som personas har potentialet til at undgå, men JTBD gør det ikke: den elastiske bruger, selvrefererende design og kantetuier.
Hvis vi ikke forklarer udtrykket „bruger“, vil det være besværligt, når det anvendes på specifikke designproblemer. Alle i et produktteam har deres egne forestillinger, når de træffer produktbeslutninger, og derfor bliver denne „bruger“ elastisk, bekvemt bøjet og strakt for at passe til meninger og formodninger fra den, der taler.
Når man træffer designbeslutninger, kan et givet produkt betragtes som „let for brugeren“ og det næste, af samme kompleksitet, „for hårdt for brugeren“.
Uundgåeligt falder tingene ind en selvrefererende proces med enten designere eller kunder, afhængigt af hvem der har mere magt til at beslutte i projektet, og ender med at træffe beslutninger baseret på deres smag og præferencer.
På samme måde, „let“, „behageligt“ og „smukt“ er subjektive begreber, og det er også „vigtigt“. Når du begynder at tænke over de mange opgaver, der skal udføres for produktet, vil du sandsynligvis ende med en liste, som du ikke har tid eller budget til fuldt ud at udvikle.
Selvom du har budgettet, bliver du nødt til at vide, hvor du skal starte. Oplysninger som hvor ofte en persona udfører en bestemt handling vil hjælpe meget, når det kommer til prioritering af funktioner.
Jobs-metoden viser sig meget nyttig til at afdække „hvad“ ved et produkt, men det giver ikke meget indsigt i „hvordan“. Imidlertid, brugerne er lige så optaget af at nå målet som med processen for at nå det.
Dette er, hvad brugeroplevelsesdesign handler om. JTBD's ligefremhed er fristende, men det falder tilbage til den tekniske tankegang om universalitet og objektivitet og det ignorerer, at der for det første er forskellige måder at nå det samme mål på, og for det andet, brugere er følelsesmæssige væsener, der leder efter mere end opfyldelsen af objektive mål.
Er målorienterede personer svaret? Jeg kan ikke sige med sikkerhed. I vores praksis finder vi stadig et par problemer med denne metode. Mens demografi og baggrundshistorier henvises til anden plan, er de stadig til stede, hvilket forårsager et par problemer.
De er beregnet til at være et kommunikationsværktøj mellem hele teamet, men personas håndteres af mennesker med forskellig baggrund, fra udviklere til klienter, og det sker ofte, at ikke alle er involveret i denne proces med at dekonstruere demografiens rolle.
Når det er sagt, afslører disse attributter sig ofte for at være betydelige distraktorer. Udviklere befinder sig lidt tabt i personas og assimilerer ikke deres betydning for implementeringsarbejdet og har problemer med at forstå dens relevante information.
Kunder har også nogle gange problemer med at distancere sig fra forudfattelser om, hvordan den „single og generte“ demografi i personaen forholder sig til ting som produktets udseende og fornemmelse.
Henvis til personaen som en han, og du vil finde dig selv i at kæmpe for at forklare, hvorfor lavendel stadig er den bedste farve til din grænseflade, da personaens oplevelsesmål er at føle sig rolig, afslappet og luksuriøs.
Når vi vejer begge muligheder, hvordan skaber vi en karakter, som teammedlemmer kan forholde sig til, som ses som den person, hvis mening skal være den vigtigste i beslutningsprocessen og undgå stereotyper og fordomme relateret til profilering?
En mulig løsning er at fusionere både persona- og JTBD-metoden. Udvikle personas, men på en måde, der er tættere på job, der skal udføres:
Navnet „job, der skal udføres“ får folk let til at tænke på løsninger snarere end om ønskede resultater fra brugerens synspunkt. Dette er for tidligt på dette tidspunkt i designtænkningsprocessen, hvor der endnu ikke blev undersøgt og udarbejdet designløsninger.
For en person, der ikke er bekendt med JTBD-metoden, er det heller ikke klart, hvad observation og situationsanalyse handler om, og hvad er forskellen mellem dem.
Der er ikke en perfekt metode, og vi bør holde en kritisk holdning over for alle metoder, anerkender, at nogle projekter (eller nogle klienter og teams) kan blive bedre tjent med noget tættere på en metode og andre projekter/klienter/teams med en anden metode.
I sidste ende bør metoder frem for alt andet stå over for en fleksibel tankegang, der ses mere som retningslinjer end som stive forskrifter. Rummet for forbedringer skal altid anerkendes.
Kort sagt, du skal ikke være bange for at innovere på den måde, der passer bedre til dit produkt, teams og faglige færdigheder.
Ved Imaginær sky vi har et team af eksperter på UI og UX design. Hvis du tror, du kunne bruge lidt hjælp til design, så send os en linje her!
Fandt du denne artikel nyttig? Du kan måske også lide disse!
Med 10 års erfaring og en baggrund inden for kognitiv videnskab. Jeg brænder for inkluderende design og rolig teknologi.
People who read this post, also found these interesting:
