Effektkarta och User story map – två modeller för prioritering

Jag älskar modeller. En bra och tydlig modell kan göra kommunikationen i ett projekt så mycket lättare.

Effektkartan är en modell jag jobbat mycket med. Den har hjälpt mig (och andra) att kommunicera och nå delad förståelse. Den har också hjälpt mig i prioritering av lösningar. En annan modell som jag lärt mig på allvar på senare tid (genom att läsa den briljanta boken User Story Mapping av Jeff Patton) är User story map. En Story map kan också underlätta delad förståelse och prioritering. Men på lite andra sätt.

Delad förståelse

Hur håller vi reda på vad som ska utvecklas och ser samtidigt till att alla i teamet vet vad som ska göras? Att mommunicera via många och långa dokument fungerar inte, det vet vi. Teammedlemmarna måste prata med varandra. Men om tjänsten är komplex, vilket den ofta är, behövs det någon form av dokument att kommunicera kring. User stories är ett vanligt sätt, men en User story i en vanlig backlog har ett problem. Den saknar kontext. Hur passar den här storyn in i helheten? Alltså, vilka andra stories hänger den ihop med, och vilka användarbehov löser den? Effektkartor och Story maps är modeller som ger en bättre helhetsbild av vad som ska göras.

Det är viktigt att tänka på att varken Effektkartor eller Story maps (eller andra modeller för den delen) är kompletta kravdokument. De är stöd för konversationer mellan människor. Det innebär att de aldrig kommer innehålla alla detaljer. Du kommer aldrig kunna maila modellen till någon utomstående och förvänta dig att den ska fatta. Du, eller någon annan som varit med om att bygga modellen, måste förklara med hjälp av modellen. Jeff Patton liknar det vid ett semesterfoto. Om du ger någon en av dina foton från en resa kommer den aldrig förstå var bilden är tagen, vad som hände före och efter. Men det blir lättare för dig att förklara om du har ett foto att visa.

Prioritering

Att jobba mot en stor ”big bang”-release av sin tjänst är inget vidare. Tidiga releaser mot riktiga användare är bra på flera sätt. Dels kan vi lära oss om hur tjänsten den möter användarnas behov innan den är klar (vilket boken Lean UX av Jeff Gothelf handlar om). Dels tar pengarna ändå alltid slut innan man hunnit utveckla allt man vill, så det är lika bra att från början öva på att leverera något begränsat.

Men för att kunna släppa något innan hela tjänsten är helt klar måste man prioritera vad som ska släppas. Då krävs koll på helheten. Vilka användarbehov är viktigast? Hur hänger olika stories ihop? Vi vill ju släppa något som är tillräckligt komplett för att användarna ska kunna (och vilja) använda tjänsten.

Effektkartan

Grundidén med effektkartan är att åskådliggöra kopplingen mellan en lösning och verksamhetsnytta. Modellen har tre nivåer:
  • Effekt – vilken nytta ska tjänsten göra för verksamheten? Halvdåligt exempel från kattmatsbranschen: ”Fler som köper kattmat hemifrån”.
  • Användning (beteenden och användningsmål) – hur beter sig människor som påverkas av tjänsten, och vilka mål har de? Beteenden och användningsmål ska förstås bygga på vad man vet om användarna – inte bara vad man tror. Prioritering sker också på denna nivå. Vi kan till exempel göra lite user research och komma fram till att vi har en beteendegrupp ”Finsmakaren” som vill uppleva exklusivitet och gärna får detaljer som kattmatens smak och näringsinnehåll. En annan grupp ”Budgetkatten” vill bara betala så lite som möjligt. Vi väljer att prioritera ”Finsmakaren” eftersom vi tror den gruppen tilltalas mer av vår ganska dyra och fina kattmat.
  • Lösning – vad ska utvecklas för att stödja användningen? Lösningar formuleras på en från början hög nivå (till exempel ”tydligt hur näringsinnehåll skiljer sig mellan produkter” eller ”design som upplevs som exklusiv”) och kopplas till de användningsmål de tillgodoser. En fin princip är att lösningarna ska formuleras som egenskaper som går att mäta. Upplevs designen som exklusiv? Det kan vi ju ta reda på genom att fråga användarna. Om den gör det så kommer vi antagligen lyckas locka ”Finsmakaren” att köpa kattmat och – tada! – nytta för kattmatsbutiken som tjänar deg!

Effektkartan kan hjälpa oss att konversera om nytta och prioritera de lösningar som leder till maximal nytta för verksamhet och användare. Att lösningarna är på en hög nivå gör att modellen går snabbt att förklara utan att gå in alltför mycket på detaljer. En bra modell att använda för att beskriva tjänsten för någon oinsatt eller intressenter utanför teamet (till exempel ledningsgruppen).

User story map

Story maps gör det lättare att jobba med User stories i projekt genom att strukturera upp dem istället för att bara lägga dem i en rad (klassisk ”platt” backlog, alltså).

Kartan beskriver vad användaren gör steg-för-steg. Om vi tar en e-handel för kattmat skulle stegen kunna vara ”Hitta kattmat”, ”Köpa”, ”Betala”, ”Få leverans”, ”Mata katt”. Under varje steg finns sedan saker som ska utvecklas (User stories) av olika prioritet.

För att tjänsten ska fungera för användaren måste varje steg fungera, det duger inte att släppa tjänsten utan att ha med steget ”Få leverans” – det skulle användarna aldrig acceptera. Men av de User stories som hör till varje steg är inte alla kritiska. Till exempel behövs SMS-avisering av leveranser inte i en första version av tjänsten. User storyn ”Få SMS-avisering inför leverans” kommer vara lägre prioriterad än t.ex. ”Få kvitto på leverans”. Det här hjälper oss att välja vad som behöver utvecklas för en tidig release av tjänsten som ändå upplevs som komplett.

En Story map ger en helhetsbild av hur tjänsten fungerar utifrån vad användaren gör steg-för-steg. Det gör det lättare att kommunicera då de User stories vi jobbar med i teamet får struktur och kontext på ett sätt som alla kan förstå. Det blir också mer fokus på användningen jämfört med en vanlig ”platt” backlog.

Effektkartor och User story maps i en härlig harmoni

Man kan förstås kombinera de här två modellerna eftersom de är bra på olika saker. Effektkartor är bra för konversationer om nytta och användning, inom teamet eller med intressenter utanför. Story maps är bra för konversationer om detaljer och i vilken ordning saker behöver levereras, inom teamet.

Nina Boljang höll ett bra blixttal om det här på senaste UX Open (2016). Nina pratade bland annat om att prioritering utifrån användares mål är det viktiga med effektkartan, men en Story map underlättar planering av releaser. Väger man in båda perspektiven får man en riktigt vettig total prioritering.

Lästips

Boken User Story Mapping borde vara obligatorisk läsning för alla som jobbar med digitala tjänster.

Handfast guide med exempel på User story map av Steve Rogalsky

Exempel på effektkarta från Huddinge kommun

Bra färsk artikelserie om Effektkartläggning av skaparen Ingrid Domingues:

 

Bygga en användarcentrerad designkultur

Under tiden jag filade på det här postade Christopher McCann på EPiServer den här texten på samma ämne. Jag tyckte den var bra, så läs gärna den också 🙂

Som UX designer brottas man ofta med att förändra en organisations designkultur till att bli mer användarcentrerad. Att ta med användarna mer i processen, basera beslut på vad man vet om användarna, öka kunskapen om användarnas behov och kommunicera utifrån ett användarperspektiv. Det kan vara svårt.

Process

Alla UX designers har nog en bild av hur den ultimata processen ser ut. Men alla som försökt jobba enligt sin ”drömprocess” vet att det är svårt. Vi är alltid begränsade till trista saker som budget och tid.

Jag tror man ska vara tuff, följa drömprocessen men banta ned den. Göra alla moment. Om det inte finns tid eller budget så kompromissa inte genom att ta bort moment. Gör momenten kortare, enklare, snabbare. En djupintervju med en kompis mamma är bättre än ingen alls. Ett användningstest med en kollega är bättre än inget alls. Om man gör alla moment så kommer folk runt omkring börja förstå processen, även om det kan kännas futtigt och löjligt ibland.

Inkludera andra i processen så mycket det bara går. Det är energikrävande och tar tid men folk som jobbar tillsammans förstår varandra så mycket bättre. Att ensam få till en förändring är snudd på omöjligt. Man måste skaffa sig allierade och då gäller det att få folk att förstå, på riktigt. Speciellt beslutsfattare vill man ha som allierade. Om en beslutsfattare högre upp fattar så kan det få riktigt bra ringar på vattnet.

Beslutsfattande

Beslut om vad som ska utvecklas och när sker oftast i flera nivåer. Någon i ledningsgruppen kanske beslutar om att en tjänst ens ska börja utvecklas. Mindre beslut kring utformning tas oftast längre led, t.ex. av en utvecklare eller UX designer.

Det är vanligt att designbeslut bygger på magkänsla eller personliga tyckanden. Eller i alldeles för hög grad utgår ifrån tekniska förutsättningar. För att besluten på alla nivåer ska bli mer användarcentrerade och leda till tjänster som folk faktiskt gillar måste man förstås jobba användarcentrerat på alla nivåer. För att det ska hända måste man sprida kunskapen om användarcenterad design i alla led. Och för att det i sin tur ska hända måste folk förstå värdet.

I en liten eller platt organisation tror jag helt enkelt olika kompetenser ska börja jobba tillsammans så man förstår varandra bättre. En utvecklare/arkitekt och en UX:are kanske ska vara aktiv i ledningsgruppen. Eller ledningen kanske ska besöka projekten regelbundet och vara med på användarundersökningar.

När detta inte går får man missionera. Att få utvecklare att förstå är oftast enkelt, speciellt om man jobbar agilt, eftersom man har ett tight samarbete. För beslutsfattare ”högre upp” kan man försöka dra paralleller mellan användarcentrerad design och nytta. Jag har ibland använt effektkartan, som jag skrivit en massa om. Den kan funka bra för att visa kopplingen mellan affärsnytta, kunskap om användare och designbeslut på ett tydligt sätt.

Konkreta goda exempel och framgångssagor kan också funka bra. Men det är viktigt att fokusera på varför man jobbar som man gör och hela tiden relatera till nyttan så den som lyssnar inte får känslan av att man bara gör en massa onödigt extrajobb.

Lästips

Boken Subject To Change av Merholz och Wilkens handlar om precis det här och är svinbra

Applied UX Strategy Part 1: Maturity Models på UXMatters handlar om UX-mognad i organisationer

Mapping Business Value to UX på UXMatters handlar om att mappa UX till affärsnytta

Saker jag lärde mig på kurs i effektkartläggning

Modellen effektkartan är lika enkel som briljant tycker jag. Den har hjälpt mig med problemlösning och med att alltid tänka både affär och användare i allt jag gör. Jag fick upp ögonen för effektkartläggning för första gången runt 2009 och i vintras gick jag inUse kurs i effektkartläggning.

Jag tänkte gå igenom några bra saker jag lärde mig under kursen som inte var självklara för mig. Jag kommer inte gå igenom metoden i grunden här, jag har ju redan skrivit en massa om effektstyrning.

Kombinera intervjuer och workshops för att hitta effektmål

UX handlar inte bara om vad användarna vill och behöver. Lika viktigt, eller viktigare är vilken affärsnytta en satsning ska leda till. Jag börjar alltid med att hitta affärssidan av myntet, det som kallas effektmål. Vilken nytta ska satsningen leda till? Om man tänker sig att vi sitter här om ett år när projektet har levererat, och det är superlyckat. Vilka förändringar har då skett?

När jag tagit fram effektmål i mina projekt har jag kört workshops med intressenter som beslutsfattare, beställare och andra. Men workshops kanske inte är det bästa sättet. Precis som olika användare har olika behov kan olika intressenter vara ute efter olika effekter. Dessutom finns det problem med workshops som arbetsform. Folk blir lätt påverkade av varandra och det kan vara svårt att styra gruppen åt rätt håll.

Det rekommenderades under kursen att istället köra djupintervjuer med intressenter för att hitta förväntade effekter. När man har gjort det kan man samla intressenterna i en workshop för att gå igenom, sammanfatta och prioritera. Absolut något jag kommer anamma, framför allt när det finns intressenter med olika agendor.

Definiera omfattningen först

Innan man börjar jobba med att definiera effektmål är det bra att definiera satsningens omfattning. På kursen pratades det om att omfattningen kan vara en pryl (till exempel ”sl.se”) eller ett verksamhetsområde (till exempel ”SL:s kundtjänst”).

Som UX-konsult är omfattningen ofta tydlig. Man blir anlitad för att lösa en specifik uppgift, som att ta fram ett intranät. Men vad händer i bredare och friare sammanhang, där man får tänka in alla kanaler och verksamhetsområden? Det är ju där man kan skapa riktigt stora nyttor, för affär och användare. När man kan ignorera organisationens stuprör och göra tjänstedesign. Här blir det klurigare att definiera en omfattning. I sådana fall tänker jag att det blir effektmålet i sig som är omfattningen, till exempel ”En effektivare SL-reseupplevelse”.

Effekterna man vill åstadkomma ska vara starkt knutna till omfattningen. De ska vara effekter som prylen eller verksamhetsområdet kan ta ansvar för. Exempelvis kanske sl.se inte kan ta ansvar för att kundnöjdheten i stort ökar, men den kan ta ansvar för att fler är nöjda med webbplatsen.

Använda användarbeteenden

I effektkartan är en målgrupp är en samling drivkrafter. Men begreppet målgrupp är inte jättebra. Dels används målgrupp på andra sätt i andra sammanhang, ibland av marknadsavdelningen för att beskriva en grupp kunder där man ofta använder demografiska uppdelningar. Dels handlar det inte alltid om att beskriva en grupp människor utan oftare om att beskriva ett beteende som en människa kan ha, och en person kan röra sig mellan olika beteenden.

På sl.se skulle man till exempel kunna tänka sig beteendet Snabbresaren, den som snabbt vill ta sig till punkt B. Ett annat beteende skulle kunna vara Reseplaneraren som i god tid innan resan vill undersöka hur lång tid resan tar, vilka byten man ska göra o.s.v. Vilket av dessa beteenden en person har beror ofta på situation och man kan röra sig från ett beteende till ett annat.

Det här var i sig inget nytt. Tanken med att sätta namn på en samling beteenden är samma i Coopers Personas. Men jag tror man kan tjäna på att använda begreppet användarbeteenden snarare än målgrupper. Jag tror också det kan underlätta att fråga efter olika situationer som användare kan befinna sig i för att hitta olika användarbeteenden.

Beskriva lösningar som egenskaper

När man vet tillräckligt mycket om användarbeteenden och användningsmål så är det dags att beskriva lösningar. Lösningar kan beskrivas i flera nivåer och på den översta nivån bör lösningen beskrivas så generellt som möjligt och som en egenskap snarare än en funktion.

Om man till exempel har ett användningsmål ”Vill undvika trafikstopp på resan” i SL-exemplet så skulle lösningen kunna vara ”Hjälper användaren att enkelt få reda på när något hänt i trafiken”. Konkreta lösningar som ”Pushnotiser i mobilen” kommer in på en längre nivå. Man kan ställa frågan ”Hur ska tjänsten vara?” istället för ”Vad ska tjänsten innehålla?” för att hitta egenskaper.

En fördel med att beskriva egenskaper först är förstås att man kan undvika att fokusera på specifika lösningar tidigt.

En annan fördel är att egenskaper kan göras mätbara. Vi låta kunderna använda tjänsten och fråga ”Upplever du att du får reda på när något händer i trafiken?” (ledande fråga ja, men ni fattar) för att ta reda på om egenskapen finns. Vi kan bestämma oss för att när 8 av 10 kunder svarar ja på frågan så har vi lyckats med egenskapen. På så sätt vet vi när vi jobbat tillräckligt mycket med en del av tjänsten för att kunna bocka av den och gå vidare till att realisera nästa egenskap. Rätt coolt, känns som att detta sätt att mäta och förbättra egenskaper passar väldigt väl in i Lean UX-tänket.

Kursen i effektkartläggning

Facebook-gruppen Business Impact Mapping & Management

En kort beskrivning av effektstyrning på webbstrateg.nu

Lean UX med effektkartan

Ett IT-projekt startar oftast med en idé om hur nytta kan skapas. Någon har kommit på ett nytt sätt att tjäna pengar på, eller ett sätt att effektivisera sin verksamhet för att spara pengar. Men IT-projekt är dyra, och ingen vet om idén kommer flyga. Den som kommit på idén tror sig veta att det finns en målgrupp som kommer använda den tänkta produkten. Det finns en stor risk i att spendera 10 miljoner på att realisera idén. Och hur ska idéerna realiseras? Ett nytt Intranät kan se ut och fungera på oändligt många olika sätt.

Omoderna, teknikdrivna, organisationer sätter igång och utvecklar direkt, utan att lägga speciellt mycket krut på att undersöka hur produkten ska utformas.

(Ett av många) problem med traditionellt användarcentrerat arbete

De som har kommit lite längre jobbar användarcentrerat på ett traditionellt sätt  (vattenfallsmodellen eller ”agilt” – men bara i utvecklingsfasen) och tycker att de därmed löser detta problem. Istället för att ”gissa” vilka målgrupperna är och vad de behöver ger vi oss ut och samlar information om hur det ligger till genom metoder som intervju, observation och dataanalys. När vi gjort detta tar vi fram designspecifikationer som vi testar på målgrupperna och sedan ger till utvecklarna som implementerar.

Så man har tagit fram design baserat på målgruppens behov. Bra. Men betyder det att vi vet att den här produkten som kostat 10 miljoner kommer skapa nytta? Knappast. De metoder vi UX Designers anammat är långt ifrån idiotsäkra. De fungerar bra för att svara på frågan Hur ska den här produkten utformas för att bli så bra [användbar] som möjligt? men har svårt att svara på frågan Kommer folk vilja använda/betala för produkten?.

Lean UX

Bygga mäta lära

The Lean Startup är en approach skapad av Eric Ries som bygger på att istället för att spendera de där 10 miljonerna på att leverera produkten om två år och hoppas att den skapar nytta, spendera en mindre summa på att bygga en minimal version av produkten (MVP) som vi kan leverera om en månad. Den minimala versionen används för att få insikter från målgruppen, insikter man använder för att förbättra och bygga nästa version.

Fördelarna med att jobba så här (jämfört med traditionellt användarcentrerat arbetssätt) är att man levererar nytta kontinuerligt och att man kan få insikter från målgrupperna som djupintervjuer har svårt att leverera:

  • Kommer målgrupperna frivilligt vilja använda/betala för produkten?
  • Hur anpassar målgrupperna sina liv efter produkten när de har använt den under flera månader?
  • Hur förändras användningen över tid? Lär sig målgrupperna hur produkten funkar?

Eftersom ”bygga” kan betyda att implementera lika gärna som att bygga en klickbar prototyp behöver UX Designers och utvecklare jobba parallellt för att man ska kunna jobba så här – vilket får en massa fantastiska konsekvenser och kallas Lean UX. Lean UX är att Bygga-Mäta-Lära i tvärfunktionella team där utvecklare och UX-designers samarbetar och uppnår delad förståelse istället för att  producera och läsa designspecifikationer. Jag har skrivit om detta förut, t.ex. i min artikelserie vattenfallsträsket.

Vad är en MVP?

Vi ska snart komma till hur det här kan funka praktiskt men först lite mer flum, det är nämligen viktigt att definiera vad en MVP (Minimum Viable Product) är i Lean UX-sammanhang. Det är nämligen inte helt lätt.

Jag tycker det är användbart att beskriva en MVP som ett experiment i syfte att validera en hypotes. Hypotesen skulle t.ex. kunna vara ”jag tror att fler kommer besöka vårt Intranät om det finns bilder på anställda”. För att validera hypotesen behöver jag ett experiment. Det traditionella UCD-experimentet skulle t.ex. kunna vara att skicka ut en enkät till användare och be de svara på om de tror att de skulle besöka Intranätet mer om det fanns bilder. Ett säkrare experiment kan vara att faktiskt bygga in funktionaliteten i Intranätet och mäta om användningen gå upp.

Hypotesen är något vi tror kommer skapa nytta. Experimentet är det minsta vi kan göra för att validera att hypotesen är korrekt.

Tidigt i ett projekt vill vi hitta hypotesen som skapar maximal nytta – och där kommer effektkartan in.

Definiera en MVP med effektkartan

Eftersom jag nyligen har jobbat med att definiera en MVP med hjälp av min gamla favoritmodell effektkartan tänkte jag dela med mig av hur jag jobbade genom att beskriva ett exempel.

Idén – hemmafixartjänsten!

En IT-satsning börjar som sagt oftast med att någon har en idé, bra eller dålig, om hur man kan spara/tjäna pengar. Vi tänker oss att jag är en entrepenör och det här är min idé:

Folk renoverar sina hus och lägenheter för glatta livet. Men det finns ingen riktigt bra tjänst för instruktioner för hur man gör för att installera en tvättmaskin eller lägga in ett parkettgolv. Jag vill skapa en tjänst där man kan få enkel tillgång till sådana instruktioner.

1. Bygga initial effektkarta – en hypotes för hela satsningen

Idéer och visioner i all ära, de är ofta intressanta men inte alltid helt gen0mtänkta.

Jag börjar nästan alltid (oavsett om jag jobbar lean eller traditionellt) ett projekt med att jag tillsammans med ett antal intressenter (de som sitter på pengarna, idéerna och verksamhetskunskapen) bygger en effektkarta under en eller flera workshops. Effektkartan täcker in affärsnyttan (eller effektmålet) med satsningen, vilka målgrupper vi tänker oss kommer bidra till nyttan, deras behov/drivkrafter och hur vi tillgodoser drivkrafterna.

Det finns flera poänger med att bygga en effektkarta tillsammans med intressenter istället för att prata funktionalitet direkt:

  • Man resonerar strukturerat utifrån affärsmål och målgrupper (användarcentrerat) istället för att folk sitter och ”tycker” olika saker utan att kunna säga varför.
  • Gruppen skapar en gemensam förståelse kring satsningen – som sammanfattas i en tydlig modell som alla kan förstå.
  • När man pratar om funktionalitet direkt blir det lätt att man suboptimerar genom att man glömmer någon målgrupp eller drivkraft.
  • Det blir tydligt hur väl man känner sina målgrupper och var man behöver inhämta mer information genom användarundersökningar.

Effektkartan vi skapar initialt bygger på gissningar om vilka målgrupper vi har, vilka drivkrafter de har och vad vi bör göra för att tillgodose drivkrafterna. Den kommer alltså utgöra en sorts bashypotes för hela satsningen.

Effektmål – vad vill vi uppnå?

Första steget när man bygger en effektkarta är att formulera ett effektmål. Vad vill vi uppnå eller hur ska vi tjäna/spara pengar på den här idén?

Vi vill få folk att betala för en tjänst innehållande instruktioner för hemmafixare.

Målgrupper – vilka kommer bidra till effektmålet?

Vilka kommer bidra till att vi kan sälja hemmafix-instruktioner? Ja, dels har vi de som kommer betala för instruktionerna. Vi tror att både hemmafixare och yrkesmän kan tänk sig betala, och vi tror att dessa två grupper skiljer sig mycket från varandra. Det finns också redaktörer, någon måste ju skriva instruktionerna.

Drivkrafter – vad behöver och vill målgrupperna?

Vad behöver och vill målgrupperna – vilka drivkrafter har de som kommer få de att vilja bidra till effektmålet? Vi tror t.ex. att hemmafixarna vill ha hjälp var de än är, till och med när de står böjda över en tvättmaskin med skruvmejseln i ena handen.

Åtgärder – vad kan vi göra för att tillgodose drivkrafterna?

Det är först nu vi börjar diskutera funktionalitet, information och annat som kommer göra våra målgrupper nöjda och glada. Hela min exempelkarta ser ut så här:

effektkarta

2. Ringa in prioriterade målgrupper, drivkrafter och åtgärder – vad är viktigast?

I nästa steg gäller det att använda den här effektkartehypotesen för att prioritera. Vilken målgrupp, vilka drivkrafter och vilka åtgärder är absolut kritiska för att vi ska lyckas? Vi vill helst av allt bryta ut en aspekt av vår tjänst som vi tror kommer vara nyckeln till att tjäna eller spara pengar, och som kommer testas i vår MVP. Men det är inte sällan flera aspekter som samverkar för att en tjänst eller produkt ska bli säljbar.

I vårt exempel tror vi att Hemmafixare är den absolut viktigaste målgruppen. Min idé var ju en tjänst som vänder sig till amatörer, hemmafixarna där ute är många och det är de som kommer betala för tjänsten.

Vi tror att den viktigaste drivkraften i exemplet är Behöver hjälp med hemmafix och den viktigaste åtgärden att det finns grafiska beskrivningar av hur man går till väga för att fixa något i hemmet.

3. Formulera en hypotes – vad är vårt prioriterade antagande?

För att sätt rätt fokus när vi bygger vår MVP (experimentet som validerar hypotesen) behöver vi formulera vad som ska testas (vad som är prioriterat) i form av en hypotes. När vi gör det blir det också tydligt att effektkartan vi byggt inte är något annat än en samling antaganden som måste valideras. Vår hypotes:

Vi tror att om hemmafixare behöver hjälp med hemmafix och kommer betala för hemmafix-instruktioner om de får grafiska beskrivningar för hur man fixar saker i hemmet.

Hypotesen på generell form:

Vi tror att [målgrupp] [drivkraft] och kommer [effektmål]  om de får [åtgärd]

Sådär! Nu har vi sammanfattat den här satsningens kärna som en hypotes. Hypotesen är kraftfull eftersom den är kort och koncis men också för att den inkluderar både effektmålet, målgruppen, drivkraften och åtgärden.

4. Definiera en MVP – vad är det minsta vi kan bygga för att validera hypotesen?

I det sista steget definierar vi själva MVP:n (eller experimentet) för att i nästa steg kunna börja bygga. Det kan man göra på olika sätt och i olika nivåer. Frågan är vad är det minsta vi kan bygga för att validera hypotesen? I exemplet med hemmafix-tjänsten kan man tänka sig en mängd olika typer av experiment. Vi skulle kunna bygga en gammal hederlig interaktiv prototyp som vi testar på målgruppen, men då levererar vi inte nytta kontinuerligt och frågan är om det verkligen skulle räcka för att validera hypotesen? Vi satsar istället på att faktiskt implementera en första version av tjänsten som låter amatörer betala för grafiska hemmafix-instruktioner.

Hur man definierar hur MVP:n ska funka beror på situation. Jag gillar att utgå från ett antal scenarios som tjänsten ska stödja (steg-för-steg: hur gör hemmafixaren för att komma åt instruktionerna?), rita skisser på hur tjänsten ska fungera utifrån dem. Jeff Pattons story maps är ett utmärkt sätt att koppla ihop användarscenarios med User Stories och prioritera. Exempelscenario:

  • Hemmafixaren laddar hem och betalar för hemmafix-appen
  • Nästa dag ska hemmafixaren koppla in sin nyinköpta tvättmaskin
  • Tar upp sin mobil och öppnar hemmafix-appen
  • Söker efter ”tvättmaskin”, får upp en lista på tvättmaskinsinstruktioner.
  • Väljer instruktionen ”Koppla in tvättmaskin”
  • Läser instruktionen
  • Åker till byggvaruhuset för att köpa in material
  • Öppnar upp appen igen för att dubbelkolla vilka rördelar som behövs
  • Åker hem igen, kopplar in maskinen

När vi har scenarios och User Stories på plats kan de i teamet med teknisk kompetens börja titta på hur tjänsten ska implementeras och med lite utvecklarmagi har vi snart en fungerande hemmafix-app. Denna app är inte komplett utan som sagt bara till för att validera hypotesen och börja leverera lite nytta.

Nästa steg – mäta, lära och förbättra

När en första MVP har byggts kan vi börja mäta användningen men också kombinera med traditionella metoder som djupintervjuer och observationer. Nu kan vi ju faktiskt ta kontakt med och intervjua de som använder vår tjänst, på riktigt, och inte bara potentiella/tänkta användare. Och om vi inte har några användare, ja då kan vi antingen gå tillbaka till effektkartan och förändra grundhypotesen eller avbryta projektet.

Varje ny sak vi lär oss om målgruppen för vi in i effektkartan. När vi planerar nästa bygg-iteration av tjänsten går vi tillbaka till kartan och plockar ut en ny hypotes. Nästa steg kanske är att ta reda på om vi kan göra tjänsten attraktiv för yrkesmän, eller så fortsätter vi jobba med vår prioriterade målgrupp. Allt beror på var vi ser mest nytta.

Den nya hypotesen används för att förbättra vår produkt, så produkten blir i nästa iteration ett experiment som är till för att validera flera hypoteser. När man har slut på hypoteser att validera, eller någon säger stopp av budgetskäl, är man klar och har en garanterat nyttig produkt som användarna gillar!

Det bästa av två världar

Det finns en stor poäng i att istället för att utgå från ett traditionellt arbetssätt, istället jobba med att leverera nytta tidigt, förbättra kontinuerligt och samarbeta i tvärfunktionella team. Men det finns inget som säger att det här arbetssättet inte kan kombineras med traditionella UX-metoder och modeller som intervjuer, observationer, användarundersökningar, bygga prototyper o.s.v.

När vi har en hypotes klar och innan vi börjar bygga kan vi t.ex. köra en snabb användarundersökning, för att göra en första check på huruvida målgruppen och drivkraften stämmer.

Så plocka gärna russinen ur kakan och anpassa don till situation. Det gör jag.

Vidare läsning

Det finns så mycket mer att skriva om det här sättet att jobba på. Som tur är finns det fler än jag som har gjort det:

The UX of MVP:s av Anders Ramsay

Experiments 101 av Simon Cast

Lean Startup is Great UX Packaging av Tomer Sharon

Continous Discovery av Martin Christensen

Lean UX is not just for lean startups av Jeff Gothelf

Agile UX vs Lean UX av Anders Ramsay

Lean UX: Getting out of the deliverables business av Jeff Gothelf