När Hemnet byggde onlinevisningar på en vecka

I lördags förmiddag höll Elin Bjurevall från Skandiamäklarna den första livestreamade visningen på Hemnet någonsin. Ett gulligt rött hus med vita knutar utanför Tystberga visades för ca 40 spekulanter. När jag kollade streamen blev jag helt varm i kroppen av stolthet. För en dryg vecka tidigare fanns ingenting. Noll.

Det är förstås en speciell situation med coronavirus och mycket av energin bygger på en vilja att hjälpa till. Minska smittspridningen på öppna visningar och förhoppningsvis bidra till att bostadsmarknaden inte dyker under krisen. Och vi har jobbat i ett högt tempo, ohållbart på sikt. Men det är ändå kul att reflektera över vad som hände egentligen. Hur kunde vi vara så snabba? Finns det något vi kan ta med oss i hur vi jobbar med produktutveckling även när det inte är krisläge?

Den öppna Slack-kanalen #hemnet-live startades 13 mars och kommunikationen exploderade snabbt. Här kan man se aktiviteten på Slack i alla kanaler:

Vi har sedan 13 mars skickat dubbelt så många meddelanden som vanligt och en del av ökningen beror på att alla jobbar hemma på grund av viruset. Men #hemnet-live står för en stor del av ökningen. Det har postats 1844 meddelanden i kanalen på nio dagar vilket är mer än vad som postats någon annan kanal på en månad.

Några saker som har kännetecknat kommunikationen i #hemnet-live:

• Snabba svar. Ingen vill fördröja någon annans arbete genom väntetider. Det gäller också code review (som sker i Github), man har fått sin kod granskad snabbare än kvickt.
• Snabba beslut. I normalfall kan det bli utdragna diskussioner om olika vägval. Här föreslog någon något, andra tyckte det var good enough och så körde man på det direkt. En viktig förutsättning var att det var tydligt kommunicerat ”uppifrån” att vi som jobbade med tjänsten hade mandat att ta beslut själva.
• Transparens. Vi har vanligtvis en kultur av att visa upp och få feedback på det vi gör. I och med Hemnet Live boostades även den. Kanalen var öppen och vi var flitiga med att visa upp halvfärdiga fulskisser, få tidig feedback på copy, testa lösningar och dela idéer. Mycket av kommunikationen var visuell. Visualiserade flöden, skärmdumpar, skisser.
• Ständiga diskussioner om målet. Vårt mål var att komma ut med livestreamade visningar till visningshelgen vecka 12 men exakt vad som skulle finnas på plats visste ingen. Vad måste vara på plats för att vi ska kunna komma ut? Vad kan läggas till senare? Vad kan göras manuellt? Vårt mål var inte att ha en perfekt lösning ute från början, utan att komma ut snabbt så vi kunde lära oss vad som fungerar.

Det där sista, att bygga en halvfärdig men så bra lösning att den kan användas fullt ut, tror jag vi kan bli ännu bättre på i normalläge. Vi pratar ofta om att jobba med MVP (Minimum Viable Product) eller RAT (Riskiest Assumption Test) – men gör vi verkligen det? Kan vi fuska mer och lära oss snabbare?

Efter den här första visningshelgen har ca 50 mäklare livetreamat sina visningar. Vi har snappat upp mängder av frågetecken och problem från både mäklare och besökare. Vi har kunnat delta själva och fått en känsla för vad spekulanterna upplever.  Vi kan nu förklara för mäklare vad de bör tänka på för att göra en bra onlinevisning. Vem hade till exempel kunnat förutse att vissa mäklares skor med hård sula skapar ett ljud som tränger igenom allt prat?

Insikterna vi fått från riktig användning gör att vi nu, vecka två, kan fokusera på att fixa rätt saker istället för att bygga potentiellt onödiga saker eller lägga tid på att spekulera kring potentiella problem. Det är verkligen guld värt och något jag hoppas vi tar med oss framåt.

Med det sagt, otroligt imponerad av alla kollegor som gjorde detta möjligt. Ni är bäst!

Skilja på problem att lösa och features att bygga

Jag är ett fan av tvärfunktionella agila team och har tidigare skrivit om OKRs som ett sätt att jobba med mål i sådana team. Vi pratar om team som inte får ”beställningar” i form av lösningar eller krav, utan har en målsättning i form av ett önskat värde som man tar ansvar för från ax till limpa. Ett team jag jobbat i på Hemnet hade till exempel ansvar för målgruppen mäklare. Det betyder att vi göra allt vi kan för att utifrån Hemnets vision driva Hemnets affär framåt genom att förstå mäklare, hitta på lösningar och bygga lösningar för mäklare.

När vi jobbar så här, istället för det klassiska featureteamet som får lösningar att bygga ”uppifrån”, kan vi:

• Utnyttja all kreativitet och hjärnkraft hos teammedlemmarna
• Ta hänsyn till både affärs- användar- och teknikperspektiv när vi utforskar och bygger
• Skapa medarbetarengagemang

Det här låter väl jättebra? Det är det. Det är också rätt svårt att lyckas med. Det kräver till exempel att:

• Ledningen har förtroende för teamen och deras förmåga att självständigt ta rätt beslut, men också att ledningen ställer krav på teamens ansvarstagande
• Teamen tar sitt ansvar och intresserar sig för vad ledningen vill, vad användarna vill, vilken kunskap som finns hos andra team och andra avdelningar. Teamet behöver alltså inte bara vara tvärfunktionellt utan också ansvarstagande, utåtblickande, innovativt och nyfiket. För många personer är det här betydligt svårare än att få lösningar att bygga.

Mycket ovan handlar om kulturen i teamen och på hela bolaget, vilket tar tid att förändra och kräver aktivt ledarskap som Marty Cagan skriver om i den här bloggposten.

På Hemnet har vi tvärfunktionella team och en kultur av att ta stort ansvar i teamen. Men teamen får också ibland agera featureteam och bygga saker som redan är definierade. Att blanda dessa två modeller funkar ibland bra men ibland leder det till att teamet:

• Får ett problem att lösa men inte tar tillräckligt ansvar för att förstå och lösa hela problemet. Det blir ett blame game där man förväntar sig att någon annan ska ta ansvar när ”någon annan” förväntade sig att teamet skulle ansvara. Vanlig kommentar: ”Hur ska det här funka egentligen? Och vad är planen på längre sikt? Det här verkar inte genomtänkt”
• Får en feature att bygga och blir sura för att någon annan redan bestämt vad som ska göras. Att vara ett team som kämpar för att ta ansvar för helheten men gång på gång får features att bygga är jobbigt. Vanlig kommentar: ”Vi får ju aldrig tänka själva, man borde lita på teamet”

Strunt är strunt och snus är snus, om ock i gyllne dosor

– Gustaf Fröding

Lösningen på det här tror jag är att uppmunta team som vill och kan ta ansvar samt vara tydligare med vilken roll teamet behöver ta i vilket läge:

1. Skilja på olika initiativ som kommer till teamet – är det här ett problem att lösa eller en feature att bygga? Och vara ärlig med det, inte försöka få en feature att bygga att se ut som ett intressant problem. Om vi är tydliga med vad som är vad kan team som vill ta mer ansvar också börja följa upp och utvärdera hur mycket tid man lägger på features att bygga.
2. Ställa krav på ”beställare” att antingen ta ansvar för (äga) lösning och uppföljning själva eller lämna det helt åt teamet. Vi vill inte hamna i ett mellanläge, det är då vi börjar skylla på ”någon annan”.
3. Ge team som vill ta ansvar möjlighet att göra det genom att få utrymme att jobba med vision och med innovation (utifrån bolagets mål).

Tips

Team Objectives – Empowerment – bloggpost av Marty Cagan

Escaping the Build Trap – talk med Melissa Perri

Outcomes vs. Outputs – talk med John Cutler

How to Break Free of the Feature Factory – talk med John Cutler

Outcome Based Roadmaps – blogginlägg av Jason Doherty

(Komma runt) problem med designers i tvärfunktionella team

På Hemnet organiserar vi oss i tvärfunktionella produktutvecklingsteam.

Tvärfunktionella betyder att teamen inte bara består av utvecklare utan också dedikerad Product manager och andra kompetenser som UX Designer, Digital analytiker, Konverteringsoptimerare eller User researcher. Vi har lite olika designkompetenser i olika team men gemensamt är att alla ska ha en Product manager, utvecklare och någon/några som kan driva processen för research, design och uppföljning.

Produktutvecklingsteam betyder för oss att varje team har ansvar för ett produktområde, vilket för oss oftast innebär att teamet även har helhetsansvar för en viss målgrupp. Teamet jag hör till jobbar exempel med målgruppen mäklares behov och drivkrafter för att bygga nya och förbättra befintliga mäklarprodukter.

Det finns en massa bra saker med att organisera sig på det här sättet:

• Alla kompetenser är med i hela processen. Det skapar förståelse och engagemang i teamet. Det minskar kommunikationsproblem och gör att vi kan ha både teknik-, affärs- och användarperspektiv på allt vi gör. Det suddar också ut gränserna mellan exempelvis UX designer och utvecklare – vi har mycket att lära av varandra.
• Teamet kan ta ansvar fullt ut för sin målgrupp och produkt. Vi kan jobba med visionen för vår målgrupp, optimera och prioritera det som är bäst för målgruppen. Teamet lär sig hela tiden, blir bättre och bättre på att förstå sin målgrupp och sina produkter.
• Teamet kan jobba med snabba experiment. Klassisk user research som djupintervjuer eller användningstester är bra sätt att förstå sina användare. Men de har sina begränsningar. Ett annat kraftfullt sätt är att experimentera med att släppa olika lösningar och följa upp resultaten (vilket jag skrivit om här). Om detta ska gå snabbt behöver vi hitta kreativa sätt att utforma/utveckla experiment och fejka saker när det går. Experimenterande kräver alltså ett tight samarbete mellan utvecklare och designers/analytiker.

Att organisera designers i tvärfunktionella team är bra. Men det finns också en del problem som man behöver ha koll på och jobba med. Några har synts på min arbetsplats, andra har jag tänkt på efter att läst boken Org Design for Design Orgs av Peter Merholz och Kristin Skinner (bra bok!).

Använda människor och kompetens på rätt sätt

Ett teams uppgifter varierar. I perioder har mitt team jobbat med teknisk infrastruktur som bara måste göras och jag har haft svårt att bidra. I andra perioder har det varit för mycket jobb på design/analysfronten för en person. Ibland har jag känt att jag är fel person, att en kollega från ett annat team skulle göra ett bättre jobb.

Man ska inte försöka optimera så alla har 100% att göra under 100% av tiden (flödesoptimering istället för resursoptimering, en grundpelare i Lean). Men att inte kunna bidra med sin kompetens under en längre tid är jobbigt och påverkar arbetsmoralen.

Några sätt att minska problemet

• Jobba med kompetensutveckling och kunskapsspridning – skapa möjligheter att bredda sig.
• Uppmuntra folk att göra saker som inte ingår i deras kärnkompetens.
• Ha sätt att ”låna ut” personer till andra team under perioder. Här krävs det förstås synkronisering mellan team så man både kan be om hjälp och säga till om någon komma ha alldeles för lite att göra.
• Kunna byta team. Det tar tid för ett team att hitta ett effektivt samarbete så man vill inte byta för ofta. Men om en person passar bättre i ett annat team eller vill utvecklas åt något håll ska det gå att byta utan att det är någon big deal.

Kontakt med andra designers

Precis som utvecklare gärna vill jobba med andra utvecklare vill designers träffa andra designers. För att utvecklas, må bra och för att kunna lösa kluriga problem. Som designer får man ofta en rätt stor och svår roll vilket kräver en hel del stöd. Speciellt i början när man ska hitta sin roll i teamet.

Några lösningar

• Göra tid för att hjälpa varandra. Se till att alla prioriterar att hjälpa sina kollegor, även när det finns mycket att göra i det egna teamet.
• Träffas regelbundet i olika sammanhang för att prata ihop sig och lösa problem tillsammans.
• Ha regelbunden kontakt med designers från andra team genom till exempel mentorskap eller coachning.

Sammanhållen användarupplevelse och arbetssätt

Ett annat problem som Merholz och Skinner skriver om är att teamen designar på olika sätt. Även om teamet jobbar med lösningar för sin målgrupp så överlappar målgrupper.

På Hemnet har vi exempelvis målgruppen bostadsköpare som ofta samtidigt är (eller kommer bli) bostadssäljare. Vi vill att användare ska känna igen sig i tjänsten oavsett vilken målgrupp man för tillfället hör till.

Vi vill också ha gemensamma arbetssätt när det gäller vissa saker. Så teamen slipper uppfinna hjulet på nytt när de exempelvis vill rekrytera användare till intervjuer eller visualisera sin målgrupps kundresa.

Hur löser vi det här?

• Att ha gemensamma sätt att designa saker på är grundtanken med designsystem. Vissa har ett dedikerat designsystem-team som jobbar med gemensamma komponenter, mönster och riktlinjer. Andra delar upp ansvaret mellan team.
• Att vi träffas och löser problem tillsammans minskar inte bara ensamheten. Det gör också att vi kan hitta gemensamma designprinciper, gemensamma arbetssätt och värderingar.
• Att vi tänker utanför vårt eget team och satsar på kunskapsdelning. Hur kan det här nya verktyget jag hittat gynna andra team? Finns det någon annan som kan dra nytta av det här designmönstret?

Målgruppsteam – inte featureteam

Det är rätt vanligt att organisera team kring en specifik feature eller teknik, till exempel varukorgen. Men för att kunna skapa maximalt värde behöver vi förstå hela kundresan. Från att det dyker upp ett behov hos en potentiell köpare till att köparen använt och kanske sålt vidare eller återvunnit produkten. Om vi inte jobbar med hela kundresan och stirrar oss blinda på varukorgen kommer vi göra fel prioriteringar, suboptimera och viktiga förbättringar kommer falla mellan stolar.

För att kunna optimera behöver team organisera sig kring målgrupper, exempelvis köpare. Om det blir för stort att ha ansvar för en hel målgrupp kan man organisera sina team runt en del av kundresan, till exempel före köp, under köp och efter köp.

Centralized partnership-modellen

I större organisationer med många team blir det mer komplext och svårare att jobba med helheten om designers sitter dedikerat i team med ansvar för bara en liten del av kundresan. I boken presenteras en sorts hybridmodell som kallas Centralized Partnership. Den innebär att designers organiserar sig runt målgrupper (t.ex. köpardesignteamet) även om produktutvecklingsteamen inte gör det. Vissa i köpardesignteamet jobbar mer dedikerat med någon del i kundresan (och med ett produktutvecklingsteam) medan andra jobbar mer övergripande.

Centralised partnership-modellen från Org Design for Design Orgs (Merholz/Skinner 2016)

I stora organisationer kan något i den här stilen behövas. Men jag tror att man ska hålla sig borta från separata designteam när det är möjligt. Det finns som sagt en massa fördelar med att designers, utvecklare och andra jobbar tight tillsammans. Speciellt i experimenterande organisationer. Hur man än gör kommer man skapa barriärer och kommunikationsproblem om man har ”designteam” och ”utvecklingsteam”.

Hela kapitlet om Centralised Partnership finns att läsa här om man är nyfiken.

Vill du också jobba i tvärfunktionella produktutvecklingsteam?

Tänker du som jag? När jag skriver det här söker vi på Hemnet både utvecklare, UX designer och product manager. Här finns jobbannonserna.

Boktips: The Principles of Product Development Flow

Jag har ibland svårt att ta mig tid att läsa böcker.  Speciellt långa och svåra böcker. Men den här våren har jag läst en av de jobbigaste böckerna om produktutveckling, helt tack vare Hemnets bokklubb (och tack vare Marcus Kempe som startade den).

Den här jobbiga men briljanta boken heter The Principles of Product Development Flow och är skriven av Donald Reinertsen. Jobbig eftersom den är skriven av en ingenjör på ett ingenjörsmässigt sätt, innehåller formler och referenser till tunga saker som köteori. Briljant eftersom den känns helt komplett. Att följa principerna i boken, även om man bara följer några, kommer göra ens bolag eller team effektivt. Principer som att mäta rätt saker, inte ha för mycket igång samtidigt eller prioritera på ett rationellt sätt.

Min minst lika briljanta kollega Kristofer jämförde boken med en komplett referens till allt man behöver tänka på för att laga god mat. Om man ska baka en lax perfekt ska ugnen till exempel vara på 180 grader eftersom [lång förklaring]. Men den är rätt värdelös när barnen skriker av hunger och man snabbt behöver sno ihop något hyggligt krubb.

Jag har svårt för sådana här böcker, vill gärna ha inspirerande och konkreta exempel snarare än formler. Men kanske just därför har jag lärt mig en massa av att läsa boken. Just att den saknar det konkreta gör att man själv behöver fylla i en massa luckor, exemplifiera och konkretisera gör den till en perfekt bokklubbsbok. Sen skadar det inte alls att ha fantastiska kollegor att diskutera med.

Prioritera utifrån ekonomiskt värde över tid

Jag gillar att sätta mål, mäta och följa upp vad tjänster levererar. Man försöker alltid hitta mål och metrics som man känner är bra mått på att vi levererar nytta för användare och affär. Det blir lite gissningsarbete.

Reinertsen menar att vi oftast använder fel metrics och har alldeles för dålig koll på vad vi faktiskt tjänar. Vi behöver koppla allt vi gör till ett enda mått; Life-cycle profit impact. Alltså hur mycket pengar en förbättring kommer inbringa under en produkts hela livscykel. Det här gäller allt från att ta fram nya produkter till hur vi till exempel jobbar med teknisk skuld eller hur vi sätter samman team.

Jag är tveksam till att mäta allt, och det tror jag inte Reinertsen menar heller. Men jag tror absolut vi alldeles för ofta prioriterar baserat på känsla snarare än på vad som är rationellt. Några exempel:

• Produktledare lutar ibland åt att prioritera nya produkter för högt. Snabba intäkter värderas högre än långsiktiga förbättringar även om de kan ge bättre ekonomi.
• Utvecklare lutar ibland åt att prioritera teknisk kvalitet för högt. Snygg och förvaltningsbar kod är ofta bra långsiktigt men mindre viktigt för ett experiment eller en tjänst som bara ska leva några månader.
• Designers lutar ibland åt att prioritera snygga detaljer för högt. Detaljer som transitioner och animeringar kan göra en del för helhetsupplevelsen. Men om de är dyra att implementera är värdet ibland tveksamt jämfört med annat som att förbättra texter, informationsstruktur eller tillgänglighet.

Ett steg i rätt riktning är att alltid fundera på hur saker kan mätas på ett rättvist sätt där vi kan lägga vår känsla åt sidan och fokusera på vad som ger effekt för affär och användare. På Hemnet jobbar vi med målstyrning enligt OKR vilket lett till en massa bra diskussioner kring mätning och mål.

Optimeringar är ofta u-formade

En annan grej jag tar med mig är att i valet mellan två extremer är det oftast optimalt att lägga sig någon stans mitt emellan.

Batch size, till exempel. Att minska scopet för en uppgift gör att man kan få feedback snabbare, minskar kötid (vi kan gå vidare till nästa uppgift snabbare), minskar risk, minskar overhead och minskar behovet av planering och synkning.

Att dela upp eller minska storleken på uppgiften leder ofta till minskade kostnader. Men vi kan inte göra uppgiften för liten, eftersom det också finns en ”transaktionskostnad” i att starta igång och avsluta uppgifter. Som att fördela uppgifter mellan personer eller deploya kod.

Det finns en massa andra exempel på U-formade optimeringar i boken. Hur många uppgifter ska man ha igång samtidigt om man vill maximera genomflöde? Inte en, inte oändligt många.

Hur ”belagda” bör teammedlemmar vara för att jobba så effektivt som möjligt? Jobbar alla 100% finns ingen tid att hjälpa andra med sina uppgifter eller styra om när förutsättningar ändras vilket leder till fördröjningar. Lite slack är bra. Men det är inte heller mest effektivt att alla jobbar 50%. Den optimala beläggningen ligger någonstans däremellan, runt 80%.

Man kan aldrig kan vara dogmatisk kring något. Sanningen finns alltid mitt emellan två extremer. Det tycker jag är en väldigt bra sak att ha med sig när det gäller typ allt.

Tack!

Jag skulle aldrig läst klart den här boken utan bokklubben (som minskade i storlek i takt med att folk tröttnade). Men jag rekommenderar den absolut. Dels till den som är processnörd, gillar ingenjörsmässiga beskrivningar, vill förstå varför agile/lean är bra och kunna tänka ut egna lösningar på processproblem. Dels till den som har en snäll kollega att diskutera med och få moraliskt stöd av.

Mob tuesday – testa att jobba hela teamet i en mobb

För några månader sedan startade mitt produktutvecklingsteam på Hemnet ett experiment. Flera i teamet var nyfikna på att jobba i en mobb. Alltså att jobba på samma problem samtidigt i samma rum på samma dator. Hela teamet, som består av utvecklare, product manager, ux designer och visuell designer. Fördelarna med detta är enligt mobbförespråkarna många. Gemensam förståelse för problemet vi löser, inga överlämningar eller ledtider, vi kan ta alla beslut direkt, tydligt fokus och bättre kvalité. Men hur funkar det i verkligheten?

Vi hade gjort några spontana försök med mobb tidigare men insåg att vi behövde avsätta tid för att mobben verkligen skulle hända. Vi jobbar i tvåveckorssprintar och måndag är planeringsdag. Det gör tisdag till en optimal mobbdag. Vi har sprintmålet färskt i huvudet och alla har ännu inte hunnit spridas ut och hugga tag i olika uppgifter. Måndagens planering innebär också ofta att vi har nya större problem att hugga tag i som kräver delad förståelse och där alla kompetenser i teamet behövs extra mycket.

Mobbregler

De första stapplande mobbsessionerna körde vi utan regler. Det funkade okej men alla var överens om att det blev för dåligt fokus. Flera datorer och telefoner jobbades på parallellt utan att man riktigt visste vad folk jobbade med. Uppgiften vi skulle lösa var otydligt definierad vilket gjorde att vi började lösa ett problem men efter ett tag grävde ner oss i ett hål och försökte lösa ett annat. Vi behövde regler.

Våra mobbregler revideras förstås varje gång men just nu ser de ut som följer:

• Tydligt mål med sessionen
  • Vilken uppgift ska vi lösa och när är vi klara?
• Om man är med i mobben så fokuserar man på det som händer i mobben
• Om man inte bidrar eller lär sig något är det helt okej att gå iväg och jobba ensam
  • Även okej att komma tillbaka. En person onboardar.
• Om man inte bidrar eller lär sig något är det helt okej att sitta kvar i rummet och jobba ensam
  • Meddela mobben tydligt att man inte deltar just nu
• En dator, en “driver” som lyssnar snarare än bestämmer
  • Roteras var 30:e minut
  • Alla erbjuds att vara driver men alla behöver inte vara driver
• Lyssna på alla och respektera allas åsikter
• Alltid utvärdera efteråt
  • Revidera dessa regler och göra det ännu bättre nästa gång

De regler som tillkommit sedan start är framför allt de som har med frivilligt deltagande att göra. Vi har försökt använda mobben för att lösa problem som alla kan bidra till, till exempel att detaljera ett flöde och skissa wireframes eller ta reda på vilken tredjepartslösning vi ska välja utifrån olika kriterier. Men vi vill inte att mobben bara ska bli en workshop utan att vi också ska kunna skriva kod.

Att alla i teamet inte kan koda behöver inte vara något problem egentligen, att koda är ju att lösa problem och det går att förstå problemet även om man inte kan tolka koden. Men när problemlösningen blir på en för tekniskt detaljerad nivå blir det svårt för icke-kodande mobbdeltagare att bidra eller känna engagemang. Därför tillåter vi att man slutar delta och jobbar med något annat men sitter kvar i rummet. På så sätt går det lätt att börja delta igen när mobben  börjar jobba med en uppgift där man kan bidra eller lära sig något.

Hur gick det då?

Mob tuesday har fått positiva effekter i teamet:

• Vi upplever att vi har blivit mer sammansvetsade som team och gör mer jobb tillsammans
• Vi har fått mersmak. Vi vill jobba mer i mobb och det jobbas mer i mobb eller par spontant
• Team happiness (en mätning där vi betygsätter vårt mående och gemensamma under varje sprint) har gått upp

…och säkert en massa andra saker som vi inte tänkt på. Experimentet upplevs positivt och verkar bli ett permanent inslag i våra sprintar.

Att testa och utvärdera nya arbetssätt är så himla kul tycker jag. Och enkelt. Att avsätta en dag av två veckor till något nytt kan alla team göra utan någon vidare risk. Just do it!

Lästips

100% av teamet i en mobb i 12 månader av Lea Kovac Beckman om SVT Sport-teamets mobb

Mob programming – a whole team approach av mobb-farfar Woody Zuill

Is Agile the Enemy (of Good Design)? av John Cutler om att jobba agilt med design

Jobba på Hemnet – vi söker bland annat utvecklare!

Experiment i produktutveckling – så funkar det

Det finns olika sätt att lära sig om hur en tjänst bör funka för att den ska passa människorna som påverkas av den. Djupintervjuer och användningstester är två favoritmetoder bland många designers. Intervjuer kan svara på hur människors behov ser ut och användningstester kan visa hur en tjänst fungerar att använda och svara på vilka delar som funkar dåligt och varför.

Men vad folk säger och hur de beter sig i ett användningstest är inte samma sak som vad folk gör när de sitter hemma framför skärmen med miljontals tjänster som pockar på deras uppmärksamhet. För att förstå hur folk verkligen använder en tjänst eller en förbättring behöver vi realisera en enkel version av den (kanske olika versioner), släppa till en testgrupp och observera data. Jag gillar att kalla det för experiment. Jag skulle kunna skriva om A/B-tester, MVP, Lean UX eller Lean experiments men de här buzzwordsen kommer med ett bagage. Och buzzwords har en förmåga att exkludera och få saker att låta svårare än vad de är.

Så: experiment. Oavsett vad man väljer att kalla det så är det awesome. Och inte speciellt svårt.

Experiment som ett verktyg av många

På sistone har jag läst boken Designing with Data. Tyvärr en lite för pratig bok som skulle kunna vara betydligt tunnare men den har en hel del fina poänger. En är att experiment ska användas som ett komplement till andra metoder och som en del av design thinking. Alltså, en process där man utifrån insamlad kunskap tar fram flera olika idéer, plockar ut de bästa, utvärderar och itererar.

Experiment kan svara på hur en idé presterar i verkligheten, vilket gör dem till ett grymt bra verktyg för designers och produktteam. Äntligen kan vi få reda på hur våra idéer presterar i verkligheten!

Men bara för att vi kan testa idéer i verkligheten ska vi förstås inte testa vilket skräp som helst. Här är saker andra verktyg som kvalitativ research, designmönster, kognition och kreativ idégenerering viktigt. När vi har en eller flera starka hypoteser om vad som kommer göra skillnad för människor och affär är det bra på förhand formulera varför vi tror på idéerna och vad som är ett lyckat test. Alltså, vilken skillnad kommer idén göra om den är lyckad? Här är ett (fiktivt) exempel på en hypotes:

Eftersom folk har svårt att hitta till sin tandläkare (vilket vi lärt oss från intervjuer med patienter som kommit för sent till sin tid) förutser vi att om vi skickar med en länk till Google Maps i påminnelse-SMS:et kommer fler hitta rätt, vilket minskar antalet försenade patienter

Hur hypotesen formuleras (eller inte formuleras) är inte så viktigt. Det viktiga är att vi vet varför vi tror på hypotesen, vilken effekt den kommer leda till och vilken observerbar mätpunkt vi tittar på för att se om vi lyckats.

Hypotesen ovan skulle vara omöjlig att testa i ett användningstest. Visst, vi kan lära oss om huruvida folk fattar vad länken är, eller om den är ser klickbar ut, eller om folk har svårt att navigera i Google Maps. Men vi kan aldrig veta om patienten skulle komma i tid.

En annan styrka med experiment är att vi kan jämföra vilken skillnad flera olika lösningar gör. Vad händer om vi skickar påminnelse-SMS:et tidigare? Eller senare? Eller skriver på ett annat sätt?

Vad som krävs för att experimentera

För att kunna experimentera tror jag man behöver jobba tvärfunktionellt och ha ett lärande mindset.

Med tvärfunktionellt menar jag att teknikfolk, affärsfolk och designfolk behöver jobba tätt tillsammans. Ett storskaligt experiment kräver ofta programmering. Men inte alltid. Det går ibland att fejka lösningen genom att till exempel skicka ut påminnelse-SMS manuellt eller via något verktyg. Det finns också verktyg för att testa enklare förändringar på webben, till exempel Google Optimize.

Jämfört med traditionell produktutveckling där en lösning/förbättring väljs ut, kodas och lanseras vill vi snabbt ta fram lösningen (ofta flera olika varianter), lansera till en delmängd av användarna och utvärdera innan vi bestämmer oss. För att experimenten ska gå snabbt att ta fram behöver utvecklarna kunna ta genvägar, använda snabba tredjepartslösningar och ”fulkoda”. Då behövs engagemang kring och kunskap om både tekniska förutsättningar och lösningar/hypoteser hos alla i teamet.

Med lärande mindset menar jag att alla i teamet (plus intressenter utanför teamet) måste vara inställda på att allt som produceras, även kod, produceras för att lära sig mer om vad som funkar. Inget är ”klart” bara för att det finns ute på sajten eller i appen. Det är klart när vi vet att det gör saker bättre för människor och för vår affär. Idéer kan (och ska) kastas bort om de inte funkar.

Dra säkra slutsatser

Vi behöver förstås också ha användare att experimentera på, och tillräckligt många för att kunna dra säkra slutsatser. Det är lättare att experimentera om en sajt har en miljon besökare per dag jämfört med hundra. Om vi till exempel testar det nya påminnelse-SMS:et på bara 100 människor och antal förseningar minskar från 20 till 16 (-20%) jämfört med en kontrollgrupp kan skillnaden med hög sannolikhet bero på slumpen.

Statistisk signifikans är ett mått på sannolikheten att ett resultat inte beror på slumpen. Det är bra att på förhand vara säker på att man kommer kunna få statistiskt säkerställda resultat inom rimlig tid, så man inte göra en massa jobb med att ta fram ett experiment i onödan.

Hur statistiskt signifikant ett resultat är beror på två saker. Dels hur många som ser experimentet, dels hur stor skillnad som uppmäts. Det är lättare att få signifikans på en 40%-ig förbättring än på en 20%-ig. Man kan ofta i förväg ta reda på vilken den minsta observerbara skillnaden är (Minimum Detectable Effect, MDE) baserat på hur många man gissar kommer se experimentet. Här finns ett enkelt verktyg för att beräkna statistisk signifikans för skillnad i konvertering (funkar även för andra mått).

Mäta rätt saker på rätt sätt

Men något som är antagligen ännu viktigare än signifikans är vilken data man väljer att mäta och hur man tolkar resultaten.

• Välja rätt mål: Vad vill vi uppnå egentligen och hur kan vi mäta det? Att färre patienter kommer för sent? Gladare patienter? Gladare tandläkare? Här behövs kunskap om vad vi (affär/verksamhet) vill uppnå.
• Välja rätt hypoteser att testa: Finns det ens någon potential att minska antalet försenade patienter? De som kommer för sent kanske kommer fortsätta göra det oavsett lösning? Vi kanske skulle kunna anpassa tiderna istället, göra dem mer flexibla? Här behövs kunskap om målgruppen.
• Kvalitet på data: Har vi tillförlitlig data som vi kan använda? Det kan finnas tandläkarmottagningar som är dåliga på att registrera antal försenade patienter. Har vi data att jämföra med? Hur länge har man registrerat förseningar?
• Kan det finnas andra orsaker än påminnelse-SMS:et till att antal försenade patienter minskar? Säsongsvariationer kan spela in, det kan till exempel vara lättare att komma i tid på sommaren när trafiken rullar på bättre. Många typer av variationer kan lösas genom att ha en kontrollgrupp, där till exempel hälften får det ursprungliga SMS:et.

Sådana här utmaningar, och fler, skrev Daniel Hansson konkret om här.

En siffra är inte (den enda) sanningen

Measurement design is subjective. Someone decides what to measure, how to measure it and how to build the model. So all data is subject to human bias.

– Arianna McClain

Precis som i alla delar av designprocessen finns det bias i hypoteser, data och mätningar. Det betyder förstås inte att vi ska sluta experimentera, precis som vi inte ska sluta göra användningstester eller behovsanalyser. Men jag tror det är extra viktigt att vara medveten om när det gäller data. Folk (speciellt datahungriga chefer) har en tendens att se siffror som sanningen.

En siffra, hur signifikant den än är, representerar bara ett perspektiv och bakom den finns en grupp människor som valt ut och tolkat. Med sina fel och brister. Erika Hall pratade bra om detta på Webbdagarna.

Globala och lokala optimeringar

Experiment kan användas både för stora, konceptuella, idéer och för små, nästan omärkbara förändringar. Jag har undvikit begreppet A/B-tester eftersom jag (och kanske många andra?) associerar till små optimeringar. Som att ändra färg på en knapp eller ändra copy. Jag tror det finns en rejäl risk i att uteslutande jobba med den typen av mindre optimeringar (vilket min fördom är att området konverteringsoptimering handlar om).

Det viktigaste för användaren är förstås inte om knappen är röd eller blå, eller om det är två eller tre steg i köpflödet. Det viktigaste är om tjänsten uppfyller mina behov, gör mig glad/nöjd/inspirerad. Samtidigt som den uppfyller affärsmål, förstås. Det här är viktigt att tänka på i all produktutveckling men kanske extra mycket när man jobbar med experiment och kvantitativ data. Vi får aldrig glömma användarens (långsiktiga) mål eller de mjukare, känslomässiga aspekterna som är svårare att mäta. Per Axbom har pratat mycket om detta, här finns hans fina prat Problemet med sagolika användarupplevelser.

Tips

Det finns jättemycket mer att skriva om det här. Men den här bloggposten är redan för lång och andra har redan gjort bra jobb med att beskriva saker (med buzzwords!):

• Boken Designing with Data innehåller en massa bra tips för att experimentera på ett proffsigt sätt
• Sajten Experimentation Hub innehåller guider, tips och verktyg för att jobba med hypoteser och experimenterande.
• Melissa Perris bloggpost Finding the Truth Behind MVPs om (miss)uppfattningar om vad en MVP är.
• Validate or Die – bloggpost av Kunal Punjabi om att validera saker i flera led. Marknad, problem och lösning.
• The MVP is dead. Long live the RAT. – Rik Higham om att validera sina mest riskabla antaganden.

Jobba tvärfunktionellt och fokuserat

Förstå problem, ta fram lösningar och testa sig fram till vad som funkar bäst. Inte bara gissa utan använda en liiite mer vetenskaplig approach när man tar fram tjänster. Och göra det tillsammans med användare och olika kompetenser i tvärfunktionella team. Det här är ju liksom vad en bra designer gör.

Att få till ett (lagom) högt tempo i allt det här är inte alltid lätt. Teammedlemmar kan vara uppbokade i olika möten eller, gud förbjude, jobba i flera team parallellt. Viktiga människor utanför teamet, som olika beslutsfattare eller folk från andra team, kan vara extra svåra att få loss tid att samarbeta med.

Jobba fokuserat i längre pass

I ett team jag jobbade i nyligen var det här extra klurigt pga flera parallella projekt. Lösningen blev att vi långt i förväg bokade in heldagar där vi samarbetade fokuserat. Dagen började alltid med att vi började stort och brett med en recap. Vad var målet med vår tjänst nu igen? Vad vet vi om målgrupperna? Vi reviderade också de modeller vi hade. En effektkarta som beskrev mål och målgrupper. En User Story Map som beskrev användarens aktiviteter i och utanför tjänsten. Sedan gick vi igenom de senaste resultaten från våra utvärderingar (användningstester) och formulerade på post-its vilka förbättringar vi ville göra av designen. Till sist skissade vi tillsammans på en förbättrad version, först individuellt på papper och sedan tillsammans på en whiteboard.

Det här upplägget blev jäkligt bra (fast det underlättade i och för sig att människorna i teamet var awesome). Att vi satt fokuserat en hel dag gjorde oss effektivare jämfört med att jobba tillsammans lite då och då. Det gjorde också att vi inte glömde bort vårt mål eller att uppdatera vår effektkarta och story map. Om man bara jobbar på med olika detaljer i lösningen och träffas någon timme i taget finns det en risk att man glömmer att tänka ordentligt på de där övergripande sakerna.

Tips från boken Sprint

Design sprints är en metod där man under en vecka fokuserat tar sig an ett problem, tar fram en lösning och testar med användare. Min kompis Eric har beskrivit vad det handlar om på ett bra sätt så jag struntar i det. Men jag läste boken Sprint nyligen och tänkte lista några bra idéer och tips därifrån som man kan använda i tvärfunktionellt designarbete, oavsett om det sker i en veckosprint eller inte:

• Fokus och förberedelse. Bestäm dagar och tider. Ha som regel att inte använda telefoner och datorer för något annat är själva uppgiften ni ska lösa.
• Ha alltid en person som har mandat att fatta beslut. Det betyder inte en diktator, alla i teamet ska få säga sitt men när ni är oense ska det finnas någon som kan peka ut en riktning.
• Börja med att komma överens om ett långsiktigt mål och vilka frågor ni vill ha svar på.
• Ta fram en visualisering av vilka aktiviteter användarna gör. Det underlättar kommunikationen något enormt. Jag gillar User Story Maps.
• Formulera problem och möjligheter som ”How Might We…?”. Ett standardsätt att formulera sig på, helt enkelt. Vilket gör det enklare att jämföra och gruppera. Just den här formen är också positiv och progressiv. Formuleringen ”Hur kan vi få fler att förstå formuläret?” blir mer kreativ än ”Folk förstår inte formuläret”.
• Kolla runt efter hur andra företag löser liknande problem och dokumentera intressanta delar genom att göra små enkla skisser.
• När ni är överens om mål och har förstått problemet ur olika perspektiv, låt alla teammedlemmar skissa en lösning individuellt. Boken beskriver en steg-för-steg-skissning i fyra steg som jag inte går in på här, skulle gärna vilja testa den. När alla har skissat sin lösning sätts lösningarna upp på väggen anonymt och alla får diskutera för/nackdelar och markera vilka delar som är intressanta.
• Det mesta kan snabbt göras till en enkel prototyp med god organisation och lite underfundighet. Ge alla i teamet en tydlig och avgränsad roll. Rollerna i boken heter Maker (bygga/designa), Stitcher (hålla ihop allting), Writer (copy), Asset collector (hitta lämpliga ikoner, bilder m.m.) och Interviewer (håller intervju med användare, förbereder underlag).

Jag rekommenderar alla att läsa boken! Skönt att läsa en så konkret beskrivning av hur en designprocess kan se ut.

Principer för hur jag vill jobba

En grej som är häftig med att jobba med UX/tjänstedesign är att ens arbetssätt hela tiden förbättras. Böcker och artiklar i alla ära, man kan lära sig en hel del av att läsa om häftiga och moderna buzzwords som Agile, Lean och Design thinking. Men inget går upp mot att göra jobbet, gå på nitar och göra det lite bättre nästa gång.

Så här kommer mina ”principer” för hur jag vill jobba. Lite pretto kanske men det får man leva med. Och situation spelar faktiskt ingen roll. De här principerna tror jag på oavsett om jag ska göra en superstrategisk förstudie för en stor myndighet eller en snabb expertutvärdering för en liten startup.

Vara transparent

Visa vad jag gör och uppmuntra andra att visa vad de gör. När saker (t.ex. design) blir synligt så uppstår informell kommunikation mellan människor, typ ”Aha! Ni jobbar också med den grejen, då borde vi ses och samarbeta”.

En annan sak som händer är att man blir granskad och ifrågasatt från nya håll. Man behöver ha stenkoll på designbeslut som tas för att kunna förklara för andra, och behöver kommunicera så alla (även folk utanför teamet) förstår. Man tvingas skärpa sig och bli lite proffsigare, helt enkelt.

Exempel

• Lägga upp saker man gjort på slack, confluence, intranät och andra platser där folk kan se
• Sätta upp visualiseringar på väggarna
• Bjuda in till öppna regelbundna demos
• Visa vad man planerar att jobba med, t.ex. lägga upp designaktiviteter i teamets backlog eller berätta på dagliga standups

Visualisera

Kommunikation är viktigt och visuella saker är lättare att ta till sig än text. UX- och UI-designers jobbar fortfarande mycket med wireframes. Sådana kan absolut vara bra men jag försöker ofta tänka ”hur kan jag kommunicera det här utan wireframes?”. Helt enkelt eftersom diskussionen jag vill ha sällan handlar om ”sidor”, ”vyer” eller ”komponenter”. Om jag använder olika sätt att visualisera blir det lättare för folk att förstå och det blir bättre diskussioner.

Exempel – några visualiseringssätt jag gillar

• Effektkarta – visualisera vad organisationen vill, vad användaren vill och hur lösningen ska vara
• User story map – visualisera hur en användare använder en tjänst steg-för-steg och vilka features som kan levereras steg-för-steg
• Service blueprint/kundresa – visualisera vad användaren gör och hur användaren interagerar med olika tjänster, kanaloberoende
• Spontanrita boxar och pilar på en whiteboard

Göra och förbättra, förbättra, förbättra

Det mest effektiva är oftast att sätta igång, ta fram något under hyfsat kort tid och förbättra det om och om igen. Det är annars lätt att hamna i analysis paralysis, speciellt för analytiska personer som jag själv.

Det gäller till exempel design. Tänka kommer alltid före göra. Vi behöver lägga tid på att förstå problemet och användarna innan vi kan göra design. Men vi får inte vara rädda för att släppa sargen, sluta analysera och börja trolla. Det blir lite skevt och lite fel till en början men det blir mer effektivt jämfört med om vi har en lång analysfas innan vi börjar ta fram något konkret. Det beror på flera saker. Vi tvingas involvera alla kompetenser, till exempel utvecklare, tidigt. Vi har något att visa upp för andra tidigt, vilket öppnar för tidig feedback från olika håll. Vi kan testa designen på användare tidigt via prototyper. Och vi kan till och med släppa en tidig version av tjänsten och få riktig feedback och data från riktig användning med riktiga användare. Det är oslagbart! Men det är förstås inte värt något om vi inte är öppna för att faktiskt göra (omfattande) förändringar när vi lär oss nya saker.

Exempel på saker att förbättra kontinuerligt

• Tjänster och produkter – via prototyper eller tidiga releaser kombinerat med användningstester, dataanalys, enkäter
• Kunskap om användare och kunders behov – via djupintervjuer, observationer
• Hur teamet jobbar – via team-retrospektiv
• Hur jag själv jobbar – via reflektion, skriva blogginlägg, bli coachad/coacha

Ha tydliga mål

Det är mycket svårt att göra rätt om man inte vet målet med det man gör. Det gäller det mesta, från möten till team eller produkter. Mötesdeltagare behöver veta målet med ett möte för att kunna bidra till det. Utvecklingsteam behöver tydliga effektmål för att kunna prioritera och bygga rätt saker, vilket jag skrivit om här.

Exempel

• Ta fram effektmål för projekt/tjänster/team tillsammans med beslutsfattare
• Ha mål med möten/workshops

Jobba tillsammans, tvärfunktionellt

Den typen av design jag oftast jobbar med är komplex och kräver olika människors input för att bli bra. Om olika kompetenser som designers, utvecklare, jurister, affärsutvecklare och andra jobbar tillsammans får alla en gemensam bild av problemen som ska lösas. Det är mer effektivt än att alla ska sitta vid sina respektive skrivbord och jobba med sina delar. Dessutom är det utvecklade. Utvecklare lär sig om designperspektivet, designers om juridik och så vidare. Alla ska inte vara generalister, men alla ska vara riktigt duktiga på något och kunna tillräckligt för att förstå alla andra perspektiv. Det brukar kallas T-formade team.

Exempel

• Skissworkshops med olika kompetenser representerade
• Låta olika personer var med och lyssna på användarintervjuer eller observera användningstester
• Analysera användarintervjuer genom att gå igenom anteckningar och göra affinity mapping tillsammans

Bidra till att skapa trygghet

I olika studier, till exempel hos Google, har man kommit fram till att trygghet är det viktigaste för att ett team ska bli effektivt. Människor som känner varandra, vågar säga vad de vill, göra vad de vill och vågar misslyckas jobbar bättre tillsammans.

Det tar tid att bygga upp trygghet i ett team. Därför bör man satsa på att inte splittra eller byta ut teamet för ofta. När jag spelar Dungeons and Dragons pratar vi ofta om att ”Never split the party”. Det slutar alltid med TPK.

Exempel på saker som bidrar till trygghet, mys och lära-känna

• Vara transparent med vad man jobbar med och hur man jobbar
• Berätta om sina misslyckanden
• Erkänna när man inte vet något
• Ge och ta emot feedback på ett snyggt sätt
• Ge beröm och peppa
• Lunchdejta folk

Tips

Det var nyttigt att skriva den här bloggposten! Jag tror alla skulle dra nytta av att formulera för sig själva hur de vill jobba.

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:

• The Birth of Impact Mapping
• The Evolution of Impact Mapping
• The many faces of Impact Mapping

 

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.