Skip to content
oktober 11, 2012 / Dan Kindeborg

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

About these ads

6 kommentarer

Lämna en kommentar
  1. Marcus Hammarberg / Jun 10 2013 15:29

    Detta är fantastiskt! Tack så mycket!

    Du borde skriva detta på engelska. Eller så gör jag det om det är ok?

Trackbacks

  1. Effektkartan – mina bästa tips « Helt Sonika
  2. Lean UX with effect map | Helt Sonika

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s

Följ

Få meddelanden om nya inlägg via e-post.

Gör sällskap med 35 andra följare

%d bloggers like this: