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.

Annonser

Kvalitativa + kvantitativa metoder = sant

Jag gillar, liksom de flesta UX:are, kvalitativa metoder (där man träffar relativt få människor och försöker förstå dem). Kombinationen med kvantitativa metoder (där man tittar på data som visar vad en stor mängd människor gör) är dock oslagbar. På sistone har jag haft bättre möjligheter att jobba med den combon än tidigare. Det har fått mig att tänka på potentialen men också på att det är viktigt att använda rätt metod för rätt sak.

Kvalitativa metoder för att förstå

Intervjuer, användningstester, contextual inquiry, fokusgrupper und so weiter. Kvalitativa metoder är bra för att förstå människor. Hur de tänker, vad de gör, vad de vet, vilka mål och behov de har. Det spelar faktiskt ingen roll hur mycket data vi har. Om vi vill göra effektiva förbättringar i en tjänst som går utöver typ byta färg på knappen behöver vi förstå användarna. Annars kommer vi nästan garanterat bygga fel saker.

Kvalitativa metoder är också bra för att skapa empati hos folk. Vi är alla människor. Att se en annan människa kämpa med att hitta rätt i ett rörigt gränssnitt kan få vilken VD som helst att mjukna och skjuta till X miljoner utvecklingsbudget. Den typen av ögonöppnare är svårare att få till kvantitativt. Med det sagt kan kvantitativa analyser också bygga empati genom att åskådliggöra användningsmönster och behov.

Det krävs inte så mycket för att börja förstå. Lite metodkunskap, intervjuteknik och tillgång till människor som är representativa för gruppen som ska använda tjänsten. Sådana går nästan alltid att få tag på.

Mättnad och statistisk signifikans

En ”nackdel” (snarare egenhet) med kvalitativa metoder är att man är i kontakt med ett begränsat antal människor och drar slutsatser utifrån det. Fokus ligger på att hitta mönster, inte att säkerställa att något faktiskt gäller för en majoritet av användarna. Vilket inte betyder att kvalitativa metoder är värdelösa på något sätt.

Inom kvalitativt pratar man inte om statistisk signifikans utan om mättnad. Prata med X antal personer, analysera och hitta mönster. Prata med Y fler, se om vi hittar nya mönster. Om vi gör det, iterera. När vi inte kan hitta tillräckligt många nya mönster är vi nöjda och kan ta fram förbättrade lösningar utifrån mönstren vi sett. Och nej, det räcker inte att köra användningstest med fem personer som Nielsen skrev 2000 (vilket Jared Spool snackade om i senaste UX podcast – avsnitt 179). Testa så länge du blir förvånad. Eller så länge du har tid och råd.

Det är viktigt att tänka på att det är mönstren som är intressanta, inte vad någon enskild person säger eller gör. Jag tycker det är jättebra att ta med medlyssnare på sina intervjuer eller användningstester men de får aldrig bara lyssna på en intervju. Folk som inte är vana vid den här typen av metoder kan dra förhastade slutsatser vilket kan bli väldigt, väldigt fel.

Du eller dina användare kan inte förutspå framtida beteende

En annan sak som är viktig att tänka på är att kvalitativa (och kvantitativa, för den delen) analyser kan lära oss om hur människor tänker och gör idag. Men du kan inte fråga en människa om hur hen kommer agera i framtiden. Frågor som ”kommer du ladda hem appen X när den finns på Appstore?” eller ”hur mycket kommer du vilja betala?” är tyvärr omöjliga att få tillförlitliga svar på. Människor kan inte förutspå sitt framtida beteende. Det gäller istället att ta fram en tillräckligt bra version av tjänsten och testa. Snabbt som attan ta fram en enkel version av den där appen, lägga upp den på Appstore och se om folk köper.

Fast i vissa lägen behöver du inte ens koda för att avgöra om en tjänst kommer användas. Det finns mängder av smarta exempel på hur en tjänst har ”fejkats” genom enkla verktyg och manuella rutiner. GroupOn, företaget som levererade digitala kuponger och var stort för några år sedan, började till exempel som en enkel blogg. Där lades kupongerna upp tillsammans köpknapp som triggade ett e-postmeddelande. Folk som var intresserade lades manuellt upp i ett dokument. På så sätt kunde man testa intresset och få folk att använda tjänsten utan att ha kodat en enda rad.

Kickstarter-kampanjer är ett annat bra exempel på hur marknaden kan testas utan att en produkt existerar ”på riktigt”.

Kvantitativa metoder för att validera med verkligheten

Data från affärssystem eller från webbanvändning är exempel på saker som kan analyseras kvantitativt. Intervjuer och labbtester i all ära, de är bra för att förstå. Men de kan inte visa på hur en större mängd människor faktiskt använder en tjänst på riktigt, i verkligheten. Det, och att vi kan säga hur stor del eller hur många är styrkan med kvantitativa metoder.

Men det allra bästa är att man med data kan jobba hypotesdrivet. En hypotes är i detta fall en idé om hur folk kommer använda tjänsten, baserat på vad vi vet om användarna (genom kvalitativa och kvantitativa analyser). Vi testar hypoteserna genom att släppa olika versioner (experiment) av tjänsten till riktiga människor med riktiga problem som sitter framför riktiga skärmar. Och analyserar data. Visst låter det grymt? Det är det!

Det här säkerställer ju att vi faktiskt inte bara gör förbättringar vi tror är rätt utan förbättringar som faktiskt ger nytta i verkligheten. Om en hypotes inte håller så slänger vi bara den versionen av tjänsten och tar fram en ny. Men det är förstås bra om vi förstår, eller i alla fall har en idé om varför en hypotes inte höll. Annars blir det svårt att pricka rätt nästa gång.

Den här typen av experimenterande arbetssätt kräver förstås att hela teamet jobbar med hypoteser och experiment. Att vi jobbar tvärfunktionellt. Och ibland att teamet och beslutsfattarna byter tankesätt. Ett experiment behöver (ska) inte bestå av perfekt kod eller design. Det ska bara vara tillräckligt bra för att kunna validera en hypotes. Och vi vet inte hur tjänsten kommer se ut i slutändan, men det är helt okej.

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.

Service blueprint – en inkörsport till tjänstedesign

På senaste tiden har jag jobbat med Service blueprint. En blueprint är kort och gott en visualisering av vad en användare/kund gör steg-för-steg (som en kundresa, alltså). Men man lägger också till vad organisationen gör för att stödja kunden i en och samma piffiga visualisering.

Här har jag gjort ett (säkert inte helt korrekt) exempel på hur en blueprint skulle kunna se ut för att skaffa ett nytt pass hos Polisen. Den utgår från kundens aktiviteter, sedan har jag lagt till vilka tjänster, system, personer och annat som användaren interagerar med. Både sådant som syns (på scenen) och sådant som inte syns (bakom scenen).

En inkörsport till tjänstedesign

Service blueprints har kallats ”a gateway drug to service design” eftersom folk som är lite mer tekniskt eller processorienterade snabbt kan förstå nyttan. Det här är något jag upplevt själv. Det tog inte lång tid innan vår blueprint fick spridning även hos folk som inte varit med i jobbet eller fått den presenterad. Jag blev extra glad när någon frågade om hen kunde få den i Visio-format för att kunna använda den som mall och göra en egen.

Gemensam förståelse

Jag älskar visualiseringar som kan hjälpa folk att förstå och lösa problem tillsammans. Blueprinten är en bra modell när de som ska samarbeta sitter i olika projekt eller avdelningar som borde prata mer med varandra.

Man kanske till exempel har ett gäng som jobbar med bokningen till passexpeditionen och ett annat som jobbar med att förbättra hur handläggarna jobbar. Det är bra om båda gängen har koll på hur de system och människor som möter kund hänger ihop, hur kunden beter sig och vilka problem kunder och handläggare har. Så de kan jobba mot samma mål och göra det som är bäst för användaren totalt, inte bara för sin lilla del i upplevelsen. Tjänstedesign, alltså.

Lager på lager på lager

Mitt exempel har ”bara” tre lager. En fin grej med blueprinten är att man kan lägga på flera lager av information. Man kan lägga på hur många lager som helst!

I den blueprint jag jobbat med i verkligheten hade jag med kundens problem och möjligheter, plus anställdas problem och möjligheter. Man kan också dela upp interaktionerna i anställda och system. Man kan bryta ner system i sina beståndsdelar och visa vilken data som flödar hit och dit. Man kan visa vilka avdelningar som jobbar med vad. Man kan visualisera hur användaren mår i olika steg.

Men om man vill göra något som folk ska förstå (och det vill man!) får det förstås inte bli för mycket.

Det är inte raketforskning

Tjänstedesign ses ibland som något stort och tungt. Många intervjuer, långa analysfaser och mycket förankring. Jag tror det beror på att man ofta vill ta stora grepp, man vill att kundresor och blueprints ska användas för att styra total prioritering. Det är ju bra. Men det finns också värde i att använda tjänstedesignmetoder i det lilla, bara för att få folk att snacka lite mer med varandra och förstå lite bättre.

Blueprints ska, liksom andra modeller av hur användare beter sig, bygga på kunskap och inte bara gissningar. Men det betyder inte att det behöver ta lång tid eller vara svårt. Det finns ofta en massa kunskap (och olika perspektiv) hos kollegor. Och om man kan lite intervjuteknik och hittar smarta sätt att analysera anteckningar tar det inte mer än några dagar att intervjua några kunder och analysera.

Tack till grymma kollegorna Sanna, Peter och Eric som bidrog till det här!

Mer om Service blueprint

Adaptive Paths Guide to Service Blueprinting

Några tips för att söka jobb

För ett tag sedan bestämde jag mig för att bli konsult (igen) och sedan dess har jag träffat sex olika konsultbolag. Alla gånger jag skaffat nytt jobb tidigare har jag glidit in på något sorts bananskal och gått på känsla, har aldrig träffat i närheten av så här många eller tänkt så här rationellt. Det har förstås varit lärorikt som attan.

Skriva en lista

En grej jag gjorde bra var att skriva en lista med saker jag ville ha. Det var bra eftersom det är lätt att hamna i att man har en bra känsla eller personkemi med en person man träffar och glömma bort vad man ville ha hos en ny arbetsgivare. Ungefär så här såg min lista ut:

• Bra möjligheter till kompetensutveckling
• Många duktiga att dela erfarenhet med
• Bra förutsättningar för att jobba användarcentrerat
• Bra förutsättningar för att jobba agilt/i tvärfunktionella team
• Fokus på nytta (affärs-/samhällsnytta)
• Snäll chef som är intresserad av mig och min utveckling
• Småsaker som gör att man känner sig uppskattad (frukostar, fester, konferenser m.m.)

Inte söka när man har en jobbsvacka

Ibland känner jag mig på topp, att jag är superduktig och kan det mesta. Ibland mindre så. För mig beror det mycket på team och projekt jag jobbar i, är det bra stämning och man känner att man får gehör för sina idéer och sitter i förarsätet så mår man bra och tror på sig själv.

Jag tror man ska undvika att söka jobb när man känner att man är i en svacka. Då blir det mycket svårare att beskriva vad man är bra på och vad man vill på ett självklart sätt.

Ta det lugnt

Jag tror det är lätt att hamna i att vilja få jobbletandet avklarat snabbt. Det är ju rätt jobbigt att söka jobb. Och visst, ibland hittar man helt rätt direkt. Men idag när arbetsmarknaden för UX:are och annat IT-folk är så bra så behöver man verkligen inte ha bråttom.

Att träffa en massa olika bolag gör att man blir bättre på att förstå vad man tycker är viktigt. Dessutom träffar man ju en massa folk som man kan stöta på igen längre fram även om det inte klickar just nu.

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