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:

 

Insikter om användare är en färskvara – leverera tidigare!

När man ska utveckla en tjänst gör man ofta tidigt researcharbete för att förstå användarnas behov och kunna designa tjänsten rätt. Det är bra. Men vad som är mindre bra är att det ofta går för lång tid från research till leverans och att användarbehoven ”glöms bort”.

Det räcker inte med en powerpoint för att förstå

Visserligen är det så att användares behov förändras över tid. Så kan det ju vara, framför allt om man jobbar med nya och innovativa tjänster som förändras. I min jobbvärld som handlar om bank och ekonomi så händer det dock inte jättemycket, och jag har sett många användargrupper där behoven är mer eller mindre statiska. I kontexten ekonomi vill användarna ha kontroll över sin ekonomi, uppleva ekonomisk trygghet och få en bättre ekonomi. De här sakerna är rätt lätta för folk som jobbar med banktjänster att förstå.

Men det är svårare att se och förstå detaljerna och nyanserna. Vad betyder kontroll för en användare? Vad ger en känsla av kontroll och trygghet? Hur står sig våra tjänster idag – på vilket sätt ger de kontroll och vad är det som gör att användaren inte känner sig trygg?

När man jobbar med att förstå användare lär man sig jättemycket. Men det är svårt att lämna över sin kunskap till någon annan som inte varit med. Vi UX:are är ofta bra på att skapa bra modeller och visualiseringar av användares behov men för att riktigt riktigt förstå de här detaljerna och nyanserna måste man vara med och göra jobbet. Alltså vara med och intervjua, lyssna på användare, analysera och hitta mönster.

Minimera tiden från research till leverans

Vad som händer om man först gör ett insiktsarbete och sedan låter det gå en viss tid innan man levererar en tjänst (eftersom man kanske är upptagen med att göra utredningar, skriva krav eller övertyga företaget om att göra en investering) är att:

  • De som var med i researcharbetet börjar glömma bort de här detaljerna och nyanserna som är så viktiga för att kunna designa en riktigt bra tjänst
  • Folk byter jobb, tar tjänsteledigt eller blir befodrade (oj vad ålderdomligt det låter att bli befodrad men tja, det heter väl så)

De här superbra insikterna försvinner alltså sakta, sakta bort ju längre tid man låter gå. Och till slut är det enda som återstår en stackars powerpoint i en bortglömd mapp i något gemensamt filsystem. Det spelar ingen roll hur bra researchleverabler vi gör (även om bra modeller och visualiseringar är jättebra för de hjälper andra att förstå!). Detaljkunskapen kommer till slut försvinna om vi inte tar oss i kragen och sätter igång att designa och implementera tjänsten.

Om vi dessutom levererar tjänsten tidigt så får vi andra finfina effekter. Tjänsten börjar användas och skapar nytta för användare och affär. Och vi kan utvärdera hur folk använder den på riktigt, så vi kan förstå deras behov ännu bättre.

Så hur gör man?

Vattenfallsprocesser lever tråkigt nog kvar i UX- och affärsutvecklingsvärlden i rätt hög utsträckning. Ibland under täcknamn som ”sprint 0” eller ”vi jobbar agilt, men först måste vi göra research”. Vi börjar med ett researcharbete, sedan kan vi utveckla. Utvecklarna får inte vara med i researchfasen, för i den fasen finns det inget tekniskt jobb att göra, sägs det.

Det är klart att användarresearch behöver göras innan vissa saker kan utvecklas. Men det finns alltid tekniskt jobb som inte är avhängt på att vi gjort en massa research. Vi vet oftast från början vilken typ av tjänst som ska utvecklas och en webbsajt eller en app behöver alltid uppsättning av infrastruktur och tekniska miljöer innan man kan börja utveckla features.

Det bästa är att jobba tillsammans från början och att hela teamet är involverat i både research och utveckling. Och att research görs löpande, parallellt med utveckling och leverans.

Men om man gör tjänstedesign då?

Om man gör ett tjänstedesignjobb så vet man inte från början vilken typ av tjänst jobbet kommer mynna ut i. Ska det bli en app, en webbsida, eller en fysisk butik kanske? Eller allt på samma gång? Här blir det svårare att minimera tiden från research till leverans och att involvera teamet som i slutändan ska realisera tjänsten.

Jag tror ändå man i många lägen från början kan gissa vilka personer som kommer vara med och realisera. Om det finns en digital tjänst och den inte funkar bra så bör det inte behövas månader av research för att inse att den behöver förbättras. Om man ändå inte kan det så bör man en bit in i tjänstedesignjobbet börja ana vilken kanal förbättringarna kommer göras i och i det läget fasa i rätt folk.

Idag jobbar tjänstedesignbyråer ibland vattenfalligt. Fokus är att leverera insikter snarare än att leverera tjänster och skapa nytta för användare och affär. Vilket kan bero på att de inte har kompetens att leverera själva, men också på att kunderna är dåliga beställare. Därför tror jag på att bygga kompetens och jobba med service design in-house. Eller hitta en byrå som inte bara är duktig på tjänstedesign utan även intresserad av leverans.

När projektformen inte funkar

Många digitala produkter slutar utvecklas och glöms bort alldeles för tidigt.

Så här går det enligt min erfarenhet ofta till: När projektet är klart, helst inom tid och budget, firar man (det är bra). Sedan går projektmedlemmarna åt olika håll, med undantag för några som blir kvar och ska jobba med förvaltning. Förvaltning innebär att man hanterar buggar. Ska det till något större behövs ett nytt projekt dras igång. Det leder till att man duckar för större förändringar.

Det finns ofta en övertro på vad som kan levereras inom projektets tid och budget. Klart man är alltid tvungen att prioritera bort saker, det är en sak. Men framför allt har man inte hunnit ta sig tid att lära sig om hur användarna faktiskt använder produkten som levereras, på riktigt.

Det går att göra hur mycket användningstester, djupintervjuer och fokusgrupper som helst under projekttiden. Det är ändå inte förrän när precis hela produkten är färdigimplementerad och har använts under en längre tid som man kan säga hur den används och uppfattas.

Det här är ett extra stort problem när man tar fram komplexa system som användarna jobbar intensivt med varje dag. En sådan situation är svår att användningstesta med en prototyp.

Det är också ett problem när man tar fram en ny och innovativ produkt, eller en social tjänst som bygger på att många använder den samtidigt. Det funkar inte att fråga användarna om de kommer köpa eller gilla produkten, hur ska de kunna veta det?

Resultatet när man inte vet tillräckligt om hur användarna kommer använda produkten blir självklart en dålig produkt med ”dålig UX”, alltså fel funktionalitet presenterad på fel sätt.

Leverera tidigare

Dels behöver man sätta produkten (den riktiga produkten, inte prototypen) i händerna på användarna tidigare. För att komma dit tror jag man måste slarva lite. Inte slarva så mycket med det användaren ser utan med strukturerna och koden bakom. Även om det känns fel måste man prioritera att få ut något snabbt istället för att bygga en perfekt systemarkitektur. Man kan slarva med saker som skalbarhet, dokumentation, driftsäkerhet och annat tekniskt som behövs men inte syns.

För att börja slarva på det sättet måste man prioritera upp kunskap om användandet och prioritera ned teknisk elegans. Alla som jobbar med projektet måste förstå varför.

Kontinuerlig förbättring istället för projekt

Dels tror jag man skulle behöva sluta driva projekt med start och slut. Man behöver se utvecklingen som en investering som börjar men aldrig tar slut. I början bränner man mer pengar, förstås. När det är läge minskar man på tempot gradvis. Kalla det inte förvaltning, utan kontinuerlig utveckling och förbättring i rätt tempo. Självklart kontinuerliga användarundersökningar, utvärderingar och redesign när man lär sig mer om hur produkten används. Inget är slaget i sten.

Det här är klart svårt eftersom beslutsfattare gillar budgetar och deadlines. Det handlar om en förändring i hur man tänker kring IT-satsningar och budgetar i stort.

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

Alternativ till den platta backloggen

I agila utvecklingsprojekt som jag varit med i har man jobbat med en backlog som består av User stories. En User story uttrycker vad en användare ska kunna göra med tjänsten som utvecklas, och tanken är att backloggen ska vara en samarbetsyta mellan utvecklarna (som har koll på vad som byggs) och produktägarna (som ska prioritera vad som byggs). User storyn följer formatet ”Som en … vill jag … för att …”, t.ex. ”Som en kund vill jag kunna lägga en vara i varukorgen för att kunna köpa plagget”. En bra user story kan innehålla mycket information. Här får vi reda på att det finns en, visserligen vag, målgrupp (kunden) som har en drivkraft (vill köpa plagget) vilken kan tillgodoses med en åtgärd (kunna lägga en vara i varukorgen).

Men det finns problem med user stories och det finns alternativ till den ”platta” backloggen.

User Story Map

Kunden i exemplet kommer inte nöja sig med att lägga varan i varukorgen för att få sin drivkraft tillgodosedd. Denna user story är en del av något större. Vi behöver kanske produktinformation, något sätt att fylla i sina uppgifter och betala. Det blir svårt att titta på denna user story och förstå var den hör hemma i ett större sammanhang utan någon sorts kontext. Och är det ens möjligt att prioritera storyn? Att kunna lägga en vara i varukorgen är ju superviktigt men det blir värdelöst utan produktinformation eller betalningsmöjlighet.

Jeff Patton beskriver ett alternativ till den platta backloggen, som kallas User Story Map. Det handlar om att abstrahera och gruppera stories i ”aktiviteter” som är stora saker folk gör, där flera steg ingår. Aktiviteten i exemplet skulle kunna vara ”Som en kund vill jag kunna köpa ett plagg på webbsidan för att slippa gå till butiken”, som består av flera sekventiellt ordnade ”uppgifter” där en skulle kunna vara ”Lägga vara i varukorgen”. Under varje uppgift finns uppgifter av lägre prioritet, t.ex. ”Få förslag på liknande varor”:

När sedan tjänsten ska utvecklas börjar man beta av stories uppifrån och arbetar sig nedåt. Ingen behöver inte fundera på vad som är mest prioriterat av ”Lägga i varukorg” och ”Visa produktinformation” – de är båda uppgifter på högsta nivån. Och eftersom man har abstraherat backloggen i aktiviteter med sekventiella uppgifter blir det lättare för alla inblandade att förstå hur tjänsten ska hänga ihop – inga fler kontextlösa stories.

Effektbackloggen

Jag är ett stort fan av effektkartan. Kort är effektkartan en modell som visar kopplingen mellan affärsmål (t.ex. ”Få folk att köpa mer klädesplagg”), potentiella målgrupper (t.ex. ”Kunder som köper i butik idag”), användningsmål (t.ex. ”Vill slippa gå till butiken”) och åtgärder (t.ex. ”Köpa plagg på webbsidan”). Effektkartan illustreras som ett träd och dess grenar skulle kunna bli basen för en backlog:

Tanken med effektkartan är att allt som utvecklas ska kunna kopplas till affärsmålet, via målgrupper och användningsmål. Den är ett stöd för att prioritera åtgärder, då prioriteringen kan lyftas till att handla om prioriterade målgrupper snarare än funktionalitet. Dessutom kan den erbjuda en bra översikt över vad man vet om målgrupperna och vad som ska utvecklas.

Idén att knyta user stories i en backlog till effektkartans användningsmål är inte dum, det blir liksom i en User Story Map lättare att förstå kontexten, fast på ett annat sätt. I effektkartan (eller effektbackloggen) är storyns kontext är inte hur aktiviteter utförs i sekvens utan snarare vilka användningsmål, målgrupper och vilket effektmål en User Story ska tillgodose. Effektkartan kan svara på frågor som ”Varför och för vem utvecklar vi varukorgen egentligen?” medan en User Story Map kan hjälpa oss med frågor som ”Hur hänger den här varukorgen ihop med de andra user stories vi utvecklar?”.

Mer läsning

The UX of User Stories av Anders Ramsay – om stories och story maps

The new user story backlog is a map av Jeff Patton – om story maps

Presentation om Agile product management with effect maps

The Effect Backlog av Martin Christensen

Vattenfallsträsket del 3 – Nya arbetssätt för agil UX

I del två skrev jag att för att vi interaktionsdesigners ska få vara med i det agila teamet och börja samarbeta måste flera saker till. Beslutsfattare, projektledare, interaktionsdesigners och utvecklare måste förstå fördelarna med att jobba agilt. Beslutsfattare måste sluta kräva noggranna estimat. Vi som jobbar i projekten måste förstå att de agila principerna även omfattar design och lära oss effektiva sätt att samarbeta på. Vi måste också förstå att jobba agilt inte är en process som betyder standup-möten eller Scrumboards utan samarbete, kontinuerlig förbättring och leverera nytta kontinuerligt.

Nya arbetssätt

Så hur gör man då? Det här med att sluta jobba isolerat i designfasen som man alltid gjort och börja samarbeta men samtidigt leverera design av samma kvalité, det kan väl inte vara helt enkelt?

Nej, det kräver en hel del av oss interaktionsdesigners. En av de agila principerna lyder:

The best architectures, requirements, and designs emerge from self-organizing teams.

Det här betyder inte att man ska slänga ihop en grupp människor, vilka som helst, och förvänta sig att de ska producera fantastiska resultat. Vad det betyder är att om man sätter ihop ett team bestående av duktiga människor från olika discipliner så kommer de själva komma fram till det bästa sättet att jobba på, man ska inte tvinga dem att följa en i förväg definierad process.

Det bästa och roligaste projekt jag jobbat i har innehållit några personer (utvecklare, UX:are, säljare) som dels förstått de agila principerna och dels haft med sig en verktygslåda med bra arbetssätt från tidigare projekt. Arbetssätt för hur utvecklare ska nå kvalité i agila miljöer finns det gott om, t.ex. parprogrammering, automatiska tester, refaktorering och design patterns. Här har jag skrivit om några av Anders Ramsays arbetssätt för agil UX. Ramsays metoder handlar mycket om samarbete med andra (icke-UX) kompetenser och målet är att uppnå gemensam förståelse för problemet och utnyttja det faktum att det i teamet finns olika personer med olika perspektiv.

Jag tror vi kan ta med oss mycket av våra gamla vanliga arbetssätt för UX-arbete in i den agila världen. Men vi behöver hitta sätt att göra våra användarundersökningar, vår interaktionsdesign och användningstester ofta och leverera små resultat istället för att jobba i en lång designfas med en stor slutleverans. Vi måste hitta sätt att förmedla kunskapen till resten av teamet utan att leverera tunga dokument. Det här kräver att vi anpassar våra existerande metoder och hittar nya som Ramsays. Det är vår uppgift som interaktionsdesigners och teammedlemmar men det här är, som tur är, inte alls raketforskning. Det är bara att köra igång efter bästa förmåga, experimentera och förbättra. Agila principerna igen:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Hur börjar man?

Som Ramsay skriver här kommer man tvingas anpassa sig om man börjar ha som ambition att leverera en fungerande produkt så tidigt som möligt. Det kan innebära att börja med att designa och implementera det absolut viktigaste, det som vi vet att produkten måste innehålla utan att behöva göra långa analyser. I många fall finns en kärnfunktionalitet som måste finnas, t.ex. en bokaffär på webben där man måste kunna köpa böckerna. I andra fall vet vi inte så mycket och måste göra lite användarundersökningar eller konkurrensanalyser för att komma fram till vad den minsta gångbara produkten är innan den kan börja utvecklas.

Siktar vi på att leverera en fungerande produkt så tidigt som möjligt blir vi tvugna att göra våra leverabler mindre, prioritera bort och begränsa. Då kan vi också kan börja leverera kontinuerligt, samarbeta, förbättras och ha kul!

Vidare läsning

Tre gubbar som skrivit mycket bra om metoder och utmaningar i agil UX: Jeff PattonJeff GothelfAnders Ramsay

Jeff Gothelfs bok Lean UX verkar rätt klar och ska komma ut i februari 2013.

Anders Ramsays bok Designing with Agile ska komma ut 2012. Inshallah.

Det funderas även en hel del här i Sverige. Senaste avsnittet av Per Axboms och James Royal-Lawsons UX podcast handlade om lean UX. Gästade gjorde Martin Christensen som arrangerar UX Open där det i våras pratades en hel del om samarbete. Förhoppningsvis blir det en repris väldigt snart.

Vattenfallsträsket del 2 – Jakten på korrekta estimat

I del ett skrev jag om varför vi UX designers/interaktionsdesigners måste sluta leverera designdokument och börja samarbeta med utvecklarna istället.

För att svara på hur vi åstadkommer denna förändring tror jag vi först måste fråga oss hur kommer det sig att vi hamnat här. Hur kommer det sig att vi fortsätter jobba isolerat och leverera våra designdokument när tekniska kompetenser som utvecklare, arkitekter och testare lärt sig samarbeta?

Jag tror det handlar om flera saker.

Jakten på korrekta estimat

Ett IT-projekt börjar ofta med någon sorts vision om hur något ska bli bättre. Man vill uppnå ett mål, kanske sälja mer prylar via webben eller spara pengar på att personalen kan jobba mer effektivt. Men för att beslutsfattare ska kunna besluta om projektets start vill de veta hur mycket projektet kommer kosta så de kan avgöra om det är värt att lägga pengar på.

För att kunna bedöma hur mycket projektet ska kosta gör man en förstudie där man uppskattar (estimerar) utvecklingstiden. Problemet är att för att få ett så bra estimat som möjligt sätter man igång med att utforma produkten redan i förstudien. Här kommer vi interaktionsdesigners in. Vi är ju experter på utformning av digitala produkter. För att resultatet ska bli bra ska vi vara med och bestämma vad produkten ska innehålla, baserat på våra användarundersökningar, vår erfarenhet och vår kunskap.

Så man löser det hela genom att göra förstudien längre och kallar den designfas eller konceptfas. För att estimaten ska bli riktigt, riktigt bra ser vi till att klara av all utformning i designfasen, inklusive grafisk formgivning. Och vips så har vi ett riktigt maffigt designdokument att leverera till utvecklarna.

Allt det här på grund av att beslutsfattaren ville ha en kostnad på sitt mål. Men den här beräknade kostnaden ligger fortfarande långt ifrån den verkliga kostnaden för utveckling. Det är nämligen mycket svårt att beräkna utvecklingstiden på det som kommer levereras i slutändan, även om man gjort en lång förstudie (hur mycket kostade den, förresten?).

Jobbar man enligt den agila filosofin levererar teamet värde kontinuerligt istället, vilket gör att man ungefär när som helst kan avbryta projektet och fortfarande ha lyckats leverera värde (i teorin). På så sätt tar man en mycket lägre risk än ett traditionellt projekt. Men det blir å andra sidan svårt att tidigt säga hur mycket det kommer kosta att nå målet.

Agila avtal

För att kunna jobba agilt fullt ut måste beslutsfattare förstå och gilla den agila filosofin så de kan besluta om ett projekts start på vagare grunder än idag. Istället för att sätta igång med en kostsam och lång förstudie kör man igång själva utvecklingen direkt och följer kontinuerligt upp om projektet verkar närma sig målet i rimlig takt. Verkar det gå trögt kan man alltid avbryta och investera i något annat. Förhoppningsvis kommer ändå nytta ha levererats innan man bestämmer sig för att avbryta, till skillnad från en misslyckad förstudie som bara slängs i soptunnan.

Det här är inte en enkel förändring att göra och svårare blir det om beslutsfattare och de som ska utveckla kommer från olika företag, så det blir en avtalsfråga. Jag jobbar inte med att utforma avtal men misstänker att det blir svårare att utforma avtal där man inte har någon uppskattad kostnad på slutleveransen.

Historia och kunskap

Det agila manifestet och de agila principerna är skrivet av utvecklare och nämner inga andra teamkompetenser än utvecklare, därför har det också först anammats av utvecklare. Men egentligen går principerna om samarbete och kontinuerlig leverans att applicera även på oss interaktionsdesigners som en del av teamet. Vi behöver bara komma fram till hur detta samarbete med andra kompetenser ska gå till, och det är precis vad som håller på att hända i området som kallas Agil UX eller Lean UX (här försöker Anders Ramsay reda ut begreppsförvirringen).

Många beslutsfattare  och projektledare jobbar trots den agila filosofin som de alltid gjort. En lång designfas följs av en korrekt estimerad utvecklingsfas men med den lilla skillnaden att man kallar utvecklingsfasen för ”agil utveckling”, har standup-möten på morgonen och levererar kontinuerligt.

Vidare läsning

Min kollega Magnus Gudhén körde en presentation om agila avtal på HiQ:s kunskapsbar förra året. Hittade även den här presentationen av Carin Meurlinger.

På engelska finns det mycket skrivet. Här finns utdrag ur boken Scaling Lean & Agile Development. Här finns en artikel på InfoQ av Allan Kelly.