Användningen av personas har alltid varit kontroversiell bland designers och proffs inom branschen. Men nyligen har några utövare i fältet pressat på för att ersätta persona metod för jobb som ska göras (JTBD) ramverk.
En noggrann analys av både persona- och JTBD-metoden, tillsammans med insikter från fältpraxis, får mig att tro att även om det faktiskt finns några problem med personametoden, hjälper denna teknik i vissa kritiska aspekter av design som JTBD-metoden inte kan täcka.
Från denna punkt kommer några frågor att tänka på: Vilken är den bästa metoden? Ska du byta från personas till JTBD?
För att sammanföra det bästa av var och en, ett möjligt tillvägagångssätt är att slå samman båda teknikernavilket resulterar i en hybridlösning.
Jobb som ska göras är ett ramverk som kan användas för att definiera en produktomfattning, dess krav eller marknadspositionering. Det är baserat på förutsättningen att när en person köper en produkt eller tjänst köper den personen faktiskt inte den, utan anställer den för att utföra ett visst jobb: Folk vill inte ha en kvarts tums borr, de vill ha ett kvarts tum hål.
Sammanfattningsvis består ett arbete som ska göras i fyra huvudaspekter:
Det första steget, utläggning, presenterar produktens sammanhang och förklarar kort vem, vad, när och var (men inte varför).
I observationssteget identifieras nuvarande och tidigare användares beteende - nämligen vilka produkter de använder.
Situationsanalysen handlar om användarnas motivation och oro, förklarar de utmaningar som kunderna står inför och vad som driver dem mot olika lösningar.
Slutligen handlar jobbet som ska göras i sig om det önskade resultatet som användaren letar efter. Det bör inte presentera en lösning - vare sig en produkt, funktion eller krav - utan istället en beskrivning av vad som ska åstadkommas av användaren på en högre nivå.
Denna metod anses ofta vara bättre lämpad än personas för produktutveckling på grund av att den är resultatstyrd, objektiv och mätbar.
Det finns många tillvägagångssätt som kan tas till personas. Vissa är ganska fattiga, medan andra gör precis tillräckligt för att accepteras. I båda fallen tjänar de bara specifika syften som inte bör inkludera produktdesign och utveckling.
Löst definierade personor är en teknik för att modellera användare. De är arketyper, formaliserade som fiktiva - men realistiska - karaktärer. Medan många designers hävdar att de använder personas, när vi analyserar deras praxis, ser vi att det som kallas ”personas” innehåller en rad mycket olika material.
Informationen som en persona konfigurerar förändras avsevärt från en designer till en annan, och så förändras naturligtvis potentialen i denna teknik också. Om vi noggrant observerar de olika sätten att göra personas kan vi identifiera fyra olika typer:
Den första typen av persona är faktiskt inte en persona utan en proto-person och alla följande typer av personor kan visa sig vara en sann persona eller en proto-persona.
Proto-personas är inte baserade på faktisk forskning, utan istället i antaganden om användarna. Denna typ av persona kräver att de människor som är involverade i att göra dem har insiktsfull kunskap om de verkliga användarna. Du bör inte bara ha designers eller ingenjörer som gör dem, utan istället bör samla människor från kundsupportavdelningen, till exempel, vid bordet.
Proto-personas bör bara användas som ett första steg för att vägleda vidare användarforskning, men aldrig som en bas för att definiera produktkraven.
Den andra typen av personas vi kan identifiera är empati personer. Dessa är byggd kring en personas bakgrundshistoria (en berättelse om personlivet och sammanhanget) vanligtvis med namn, ålder, foto och citat.
Denna typ av persona kan vara användbar för att skapa empati i utvecklingsteamet och hjälpa dem att hålla sig motiverade under projektet.
Professionella som inte har regelbunden kontakt med kunder kan förlora visionen om produktens användbarhet och relevans, i vilket fall, Att känna någon för vilken produkten kommer att göra skillnad kan hjälpa dem att förstå sina ansträngningar i ett högre sammanhang.
I slutändan är denna typ av persona till liten eller ingen nytta när det gäller att fastställa produktkraven och projektplanen.
Den tredje typen av personer som vi kan identifiera är Marknadsföring/Demografi personer.
Medan det värsta som kan hända med en empatipersona som används för andra mål förutom de som anges ovan är att det kan visa sig vara slöseri med tid, de marknadsförings-/demografiska personerna kan verkligen skada din produktutveckling (särskilt om vi pratar om marknadsföring av proto-personas).
Marknadsföringspersoner har fokus på demografi, försöker hitta roten till användarens beteenden och önskemål i den informationen.
Detta är den typ av personas som de flesta försvarare som ska göras reser sig mot, eftersom det inte finns någon verklig kausalitet mellan demografi, mål och beteenden. De identifierade mönstren är vanligtvis resultatet av fördomar och stereotyper.
Detta fjärde tillvägagångssätt, benämnt målorienterade/designpersoner, förskjuter personans bakgrundshistoria och demografi till en sekundär plan och fokuserar på mål och behov.
Dessa personor identifierar specifikt livsmål, erfarenhetsmål, och slutmål, såväl som behov, frustrationer och beteenden. Denna typ av persona kommer mycket nära de jobb som ska utföras metodik, samtidigt som vissa attribut bevaras som ger personas en del av sin makt, en som går utöver att skapa empati för att motivera teamet.
Om du vill veta mer om målorienterade personor rekommenderar jag dig att kolla Alan Coopers bok Om Face.
Tittar på Kritiker från Intercom, till exempel, en av de mest framstående rösterna för att försvara JTBD och mot personas, presenterar de oss följande användarhistoria baserad på en persona:
”Som en 35-årig man som heter Peter vill jag äta något gott när jag är hungrig, så jag känner mig inte hungrig längre”.
Även om vi inte kunde hålla mer med kritikern när hon påpekar att den första delen ”Som en 35 gammal man som heter Peter...” är irrelevant - eftersom det inte finns någon orsakssamband mellan dessa data och den sista delen av meningen - detta är ett exempel på persona metod som använder användarberättelser och inte användarresor.
Därför, som vi ser, Detta argument är endast tillämpligt på marknadsföringspersoner och inte på målorienterade/designpersonor.
Om det var en målinriktad person skulle historien vara annorlunda:
” Som en äldre kronikpatient som vill njuta av pension mest vill jag enkelt kunna kontakta min läkare när som helst, så att jag kan känna mig trygg med mitt hälsotillstånd”
Det skulle bara nämna demografi som skulle ha en kausalitetsrelation med personans mål och fokusera på önskat resultat, vilket gör det mycket likt det jobb som ska göras.
Fortfarande på Kritiker från Intercom, när motsvarande JTBD presenteras, ges följande exempel:
”När jag bara har två minuter på mig att avvärja hunger mellan mötena, vill jag ta något som kommer att gå snabbt och enkelt”.
Men vad är ”lätt”?
Saker som ”lätt” eller ”trevligt” är subjektiva attribut, de berör inte själva produkten utan användarens upplevelse av produkten, eftersom de är helt beroende av användarens attribut.
Det betyder att det är omöjligt att utvärdera dessa attribut utan att ha någon form av användarprofil. Specifikt, erfarenhetsmål, expertis, kunskap, intellektuella och motoriska färdigheter, till exempel.
Låt oss säga att JTBD är ”att ha en plats att spara mina filer på ett sätt som är lätt att hitta dem”. När det gäller design kan detta återspeglas i en hierarkisk och välorganiserad mappstruktur eller i en enkel förvaringsmapp med ett sökfält.
Detta leder oss till tre vanliga projektfallgropar som personer har potential att undvika, men JTBD gör det inte: den elastiska användaren, självreferentiell design och kantfodral.
Om vi inte förklarar termen ”användare” kommer det att vara besvärligt när det tillämpas på specifika designproblem. Alla i ett produktteam har sina egna uppfattningar när de fattar produktbeslut, och så blir denna ”användare” elastisk, bekvämt böjd och sträckt för att passa åsikter och antaganden från den som pratar.
När man fattar designbeslut kan en given produkt betraktas som ”lätt för användaren” och nästa, av samma komplexitet, ”för svår för användaren”.
Oundvikligen faller saker och ting i en självreferensprocess med antingen designers eller kunder, beroende på vem som har mer beslutsfattande i projektet, vilket slutar fatta beslut baserat på deras smak och preferenser.
På samma sätt, ”Lätt”, ”trevligt” och ”vackert” är subjektiva begrepp och så är ”viktigt”. När du börjar tänka på de flera jobb som ska göras för produkten kommer du förmodligen att sluta med en lista som du inte har tid eller budget att utveckla fullt ut.
Även om du har budgeten måste du veta var du ska börja. Information som hur ofta en person gör en viss åtgärd hjälper mycket när det gäller att prioritera funktioner.
Metoden jobb som ska göras visar sig vara mycket användbar för att avslöja ”vad” av en produkt, men det ger inte mycket insikt om ”hur”. Emellertid användarna är lika intresserade av att uppnå målet som med processen för att uppnå det.
Det är vad användarupplevelsedesign handlar om. JTBD: s rakhet är frestande men det faller tillbaka till det tekniska tankesättet om universalitet och objektivitet och det ignorerar att det för det första finns olika sätt att nå samma mål och att för det andra, användare är känslomässiga varelser som letar efter mer än uppnåendet av objektiva mål.
Är målorienterade personer svaret? Jag kan inte säga säkert. I vår praxis hittar vi fortfarande några problem med den metoden. Medan demografi och bakgrundshistorier förflyttas till andra planen, de är fortfarande närvarande, vilket orsakar några problem.
De är avsedda att vara ett kommunikationsverktyg mellan hela teamet, men personas hanteras av människor med olika bakgrund, från utvecklare till kunder, och det händer ofta att inte alla är inblandade i denna process för att dekonstruera demografins roll.
Med det sagt, dessa attribut visar sig ofta vara betydande distraktorer. Utvecklare befinner sig lite vilse i personas, assimilerar inte deras betydelse för implementeringsarbetet och har problem med att förstå dess relevanta information.
Dessutom har kunder ibland problem med att distansera sig från förutfattade uppfattningar om hur den ”ensamstående och blyga” demografin i personan relaterar till saker som produktens utseende och känsla.
Hänvisa till personan som en han, och du kommer att kämpa för att förklara varför lavendel fortfarande är den bästa färgen för ditt gränssnitt, eftersom personans upplevelsemål är att känna sig lugn, avslappnad och lyxig.
Genom att väga båda alternativen, hur skapar vi en karaktär som teammedlemmar kan relatera till, som ses som den person vars åsikt bör vara den viktigaste i beslutsprocessen och undvika stereotyper och fördomar relaterade till profilering?
En möjlig lösning är att slå samman både persona- och JTBD-metoden. Utveckla personas, men på ett sätt som är närmare jobb som ska göras:
Namnet ”jobb som ska göras” driver lätt människor att tänka på lösningar snarare än om önskade resultat ur användarens synvinkel. Detta är för tidigt vid denna tidpunkt i designtänkningsprocessen, när inga designlösningar ännu studerades och utarbetades.
För någon som inte är bekant med JTBD-metoden är det inte klart vad observation och situationsanalys handlar om, och vad är skillnaden mellan dem.
Det finns ingen perfekt metod och vi bör hålla en kritisk hållning inför alla metoder, erkänner att vissa projekt (eller vissa kunder och team) kan betjänas bättre med något närmare en metod och andra projekt/kunder/team, med en annan metod.
I slutändan, framför allt annat, bör metoder ställas inför ett flexibelt tänkesätt, ses mer som riktlinjer än som styva recept. Utrymmet för förbättringar bör alltid erkännas.
Enkelt uttryckt bör du inte vara rädd för att innovera på det sätt som bättre passar din produkt, team och professionella färdigheter.
Vid Imaginärt moln vi har ett team av experter på UI och UX design. Om du tror att du kan använda lite hjälp med design, skicka oss en rad här!
Hittade den här artikeln användbar? Du kanske gillar dessa också!
Med 10 års erfarenhet och bakgrund inom kognitiv vetenskap. Jag brinner för inkluderande design och lugn teknik.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
