Bli bättre på presentationer

Jag tycker det är läskigt att hålla presentationer, det är jag inte ensam om. Men det finns också få saker i jobbet som kan få en att känna sig kompetent och viktig som när man gör en bra presentation. Och så älskar jag hantverket, att bygga presentationer som får folk att förstå. Tyvärr har alldeles för många bara blivit liggande eftersom jag inte kommit över tröskeln att presentera.

I onsdags var jag på Mike Monteiros workshop Presenting Design Like Your Life Depends On It (Because It Will), i samband med From Business to Buttons. Vi fick öva på att presentera för varandra och lärde oss massor. Här kommer de viktigaste sakerna jag lärde mig:

Var ordentligt förberedd

Du som presenterar måste ha riktigt bra koll på materialet. Det kommer alltid hända oväntade saker under en presentation. Oväntade frågor kommer komma, oväntade personer dyker upp, någon vill att du hoppar över delar av materialet eller förklarar något på djupet. Ha inget manus, för då tvingas du kunna materialet riktigt bra och du får lättare att hantera det oväntade. Utan manus blir det också lättare att presentera på ett engagerande sätt.

Var öppen för att oväntade frågor och diskussioner kommer upp. Men försök se till att rätt frågor dyker upp genom att inleda presentationen med att berätta varför alla är här, vilken roll folk har och vilken typ av frågor du vill få.

Känn till folks drivkrafter

Alla som deltar har ett mål, ibland kan målet vara att bara komma därifrån. Ett sätt att både göra bättre presentationer och hantera oväntade situationer (som att någon håller en 20-minuters monolog om något du tycker är irrelevant) är att förstå de olika agendor folk har. Som presentatör eller workshopledare är det lätt att skaffa sig en drömbild av vilka diskussioner som kommer komma upp. Den drömbilden bygger på din agenda, ditt perspektiv, designperspektivet. Men om du presenterar för icke-designers kommer åhörarna naturligtvis ha andra perspektiv och andra agendor.

Använd användarcentrerade designmetoder. Analysera målgruppen, deras drivkrafter och designa presentationen för dem, inte för dig själv. Ibland krävs det att du intervjuar deltagarna inför en presentation.

Workshopen i onsdags fokuserade på att presentera design för beslutsfattare/kunder. I den situationen vill de som lyssnar känna sig trygga i att du har gjort ett bra jobb, att allt är genomtänkt och att din design kommer göra företaget framgångsrikt. Det handlar inte om att gå igenom varje liten designdetalj del för del. Det handlar om att sälja – både designen och dig själv som experten som har gjort ett fantastiskt jobb.

Ta kontroll över rummet

Kroppsspråk och röstläge spelar roll. Stå alltid upp när du presenterar. Visa att du är i fokus genom att gestikulera och tala tydligt. Men du behöver inte försöka vara någon annan. Var dig själv, men dig själv när du är som mest engagerad. Om du visar att du brinner för det du pratar om så smittar det av sig.

Det är svårt att bryta sådana här mönster. Jag tror det handlar mycket om att öva, och få feedback.

Be om feedback

Den viktigaste saken i en process är att den förbättras kontinuerligt. Det gäller också ditt sätt att presentera. Tyvärr är det sällan man får någon annan typ av feedback än en klapp på axeln. Riktig feedback kommer inte av sig självt, den måste du be om.

Sammanfattning

För att sammanfatta ska jag bli bättre på att:

  • Vara förberedd och skippa manus
  • Tänka på åhörarna och deras drivkrafter inför en presentation
  • Vara medveten om hur jag presenterar och öva oftare
  • Be om feedback

Tips

Mike Monteiros 13 Ways Designers Screw Up Client Presentations som artikel på medium, som video från From Business to Buttons

Mikes podcast Let’s Make Mistakes

 

Annonser

Fråga vad användarna tycker – det är okej

Det här är UX-världens kanske mest uttjatade citat (som antagligen inte ens stämmer):

If I had asked people what they wanted, they would have said faster horses.

– Henry Ford

Citatet används ofta för att poängtera att det inte handlar om vad användarna tycker. Man måste förstå användarnas behov för att kunna designa en bra lösning. För användarna är oftast inte designers, de har inte koll på vad som är möjligt att göra och utgår bara från sig själva. De kan inte designa lösningarna själva. Och man kan inte bara utgå från synpunkter och idéer från användare när man väljer lösning. Bra så.

Men det finns också fördelar med att fråga vad användarna tycker och be dem komma med egna idéer:

  • Alla användare är, som bekant, olika. Många är fantasirika och kreativa människor. Många har en grymt bra analysförmåga.
  • Användarna kan ha erfarenheter från webbplatser och system som jag som designer aldrig sett. Om det handlar om ett expertsystem som folk använder ofta så har vissa användare antagligen redan funderat mycket på hur det skulle kunna funka bättre.
  • I en intervju kan frågan Hur skulle du önska att det här skulle funka? dels vara en isbrytare, som får folk att prata. Dels kan den följas upp med frågan Varför skulle du vilja att det funkade så?.

I co-creation tar man det här ett steg längre. Det handlar om att engagera användarna i designprocessen. Istället för att först förstå målgrupper och behov, sedan göra ut en lösning och testa så låter man användarna vara med och designa lösningen. Man kombinerar alltså ”traditionell” research (djupintervju/observation) och konceptdesign till en aktivitet med syftet att förstå både användarnas behov och hur de ser på en lösning.

Sådana här workshops kräver förstås en del planering och tankearbete. Men det kan nog vara ett effektivt sätt att designa på, om det görs rätt. Jag tror ett första steg kan vara att ibland fråga vad folk tycker, och se vart det leder.

Lästips

Co-Creation: Designing With the User, For the User på UX Booth
The UX of Co-Design: Experience Principles for Successful Client Workshops på Adaptive Path
Myth #21: People can tell you what they want på UX Myths

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

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

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

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

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

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

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

Definiera omfattningen först

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

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

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

Använda användarbeteenden

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

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

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

Beskriva lösningar som egenskaper

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

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

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

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

Kursen i effektkartläggning

Facebook-gruppen Business Impact Mapping & Management

En kort beskrivning av effektstyrning på webbstrateg.nu

Effektkartan – mina bästa tips

Det absolut vanligaste sökordet folk använder för att komma till min blogg är ”effektkarta”. Eftersom jag gillar effektkartor och har använt dem i en massa projekt så tänkte jag dela med mig av några tips.

Inledande workshop med rätt personer

En workshop (eller flera) där man tillsammans bygger en effektkarta kan vara en bra start på ett projekt. Men för att workshopen ska bli effektiv är det viktigt att man samlar rätt personer utan att man är för många. Tre till fem personer tycker jag funkar bäst och man behöver:

  • Beslutsfattare. Någon eller några tunga beslutande personer och helst den som ”sponsrar” projektet, alltså sitter på pengarna och beslutar om projektets varande eller icke varande. Till exempel en VD, CIO, CTO eller avdelningschef. Denna person är viktig för att kunna definiera ett effektmål. Den är också superviktig att förankra hos.
  • Verksamhetsexperter. Någon eller några som har koll på hur verksamheten fungerar och vilka målgrupper som finns. Försök hitta en ”spindel i nätet” som har övergripande kunskap och inte bara kan en viss avdelning eller produkt. Kundtjänst och marknadsavdelning är bra ställen av börja leta på.
  • Teknisk expert. Om något ska implementeras är det bra att ha med någon eller några som kan tekniken och kommer ha en strategisk roll i implementation. Till exempel en senior utvecklare, systemarkitekt eller teknisk projektledare. I effektkartläggningen är det viktigt att hålla diskussionerna på en icke-teknisk och övergripande nivå, men det är väldigt skönt att ha någon som direkt kan svara på vad som är lätt och svårt. Dessutom är det viktigt att det nyttofokuserande och användarcentrerade arbetssättet förankras med någon på tekniksidan.

Håll effektkartan kort

Effektkartan kan användas som en arbetsmodell för att styra mot nytta, prioritera rätt och ”göra rätt saker”. Men den är också mycket användbar för förankring och kommunikation. Nya projektintressenter och projektmedlemmar kan snabbt följa och förstå hur åtgärder eller funktioner motiveras. Att man inte bara förstår vad som ska göras utan varför är viktigt för att människor ska kunna jobba effektivt och bidra med nya idéer.

När effektkartan fyller en viktig pedagogisk funktion är det bra om den inte är för omfattande. Det gör den också lättare att underhålla. Jag tror inte allt behöver finnas med i kartan, speciellt inte åtgärder och funktioner på låg nivå. Istället brukar jag begränsa mina effektkartor till koncept och principer på hög nivå.

Betrakta effektkartan som en samling hypoteser som ska valideras

De målgrupper och drivkrafter som identifieras i en inledande workshop är inget annat än kvalificerade gissningar som kan ligga långt från verkligheten. För att validera att hypoteserna stämmer kan vi gå två vägar.

Antingen gör vi en s.k. målgruppsanalys för at analysera de potentiella målgrupperna med hjälp av traditionella UX-metoder som djupintervjuer, observationer och dataanalys. Den andra vägen är att ta till olika typer av experiment för att validera, enligt Lean Startup-modellen. Effektkartan kan fungera som ett bra verktyg för att jobba strukturerat med hypoteser och validering, vilket jag har skrivit om förut och som Gojko Adzic skrivit en bra bok om, Impact Mapping.

Vad som fungerar bäst beror på situation men jag tror det bästa är en kombination av traditionell målgruppsanalys och experimenterande.

Oavsett vilken väg vi väljer är det viktigt att alla som kommer i kontakt med effektkartan förstår att den från början är mycket hypotetisk och behöver valideras och kompletteras på ett strukturerat sätt.

Effektkartan är aldrig klar

Vissa verkar tro att bara för att effektkartan är ett dokument som börjar produceras tidigt i processen så måste den bli klar och ”signas av” av någon beslutsfattare. Men om kartan signas av blir det svårt att senare få till förändringar. Om vi jobbar med interaktionsdesign parallellt med utveckling, enligt agila principer, måste kartan självklart få växa fram kontinuerligt. Insikter från diskussioner med projektintressenter, från användningstester och statistik måste få påverka kartan, oavsett om insikterna kommer i tidiga workshops eller strax innan lansering.

Vattenfalls-UX är ineffektivt, kostsamt och tråkigt. Vi borde lära oss samarbeta och anpassa hur vi jobbar med metoder som effektkartläggning för att tillåta förändring och kontinuerligt upptäckande, inte bara kontinuerlig leverans.

Tänk efter själv och ha kul!

Jag gillar verkligen idéerna bakom effektkartan och effektstyrning, men det finns inte ett rätt sätt att arbeta på. Kartan och tankarna bakom kan användas på olika sätt. Jag har t.ex. använt effektkartan som ett stöd vid kreativa workshops och för att hjälpa en startup hitta sina viktigaste affärskritiska hypoteser. Det finns säkerligen en massa kreativa sätt att använda den på i andra situationer.

Kartans struktur behöver inte heller vara slagen i sten. Adzics modell Impact Mapping täcker inte bara in målgrupper som bidrar till nyttan genom sin användning. Den inkluderar också aktörer som mer indirekt bidrar till nyttan, som beslutsfattare. Den här utökningen har nog både för- och nackdelar. Poängen är att om man förstår effektkartan och situationen kräver en förändring eller utökning så kör på!

Vidare läsning

Gojko Adzics e-bok Impact mapping kom ut November 2012, så den är purfärsk. Boken innehåller en massa om hur man jobbar med effektkartor kombinerat med moderna principer som Agil metodik, Lean UX, Lean Startups och Design thinking. Rekommenderas starkt för alla som jobbar med effektkartläggning, även om Gojkos Impact Map skiljer sig lite från Domingues och Balics effektkarta. Boken är dessutom både snygg, kort och billig.

Mikael Sköld höll presentationen Bättre effektkartor på UX Open, där finns också en del tips.

Att skissa för hand

I förra veckan besöktes HiQ-kontoret av interaktionsdesignern Mårten Angner som pratade skissteknik (tack Mårten!), vi fick bland annat lära oss rita raka linjer och cirklar. Men kursen handlade också om fördelarna med att skissa för att bli mer effektiv i sin kommunikation.

Delad förståelse

En grupp personer sitter i ett möte och diskuterar ett komplicerat problem. Trots att alla är superkompetenta så lyckas man inte komma överens. Men plötsligt händer något. En av personerna går fram till whiteboarden och börjar rita. Plötsligt inser man att man egentligen inte var oense, det handlade bara om att man hade olika bild av problemet. Många känner nog igen situationen.

En bild gör i många lägen ett bättre jobb än ord eller text för att få en grupp människor att nå samförstånd. En bild säger ibland mer än tusen ord. Om vi som jobbar med att kommunicera komplexa idéer har närmare till skissblocket och pennan blir vi helt enkelt mer effektiva på att kommunicera. Men de riktigt bra effekterna uppstår om vi även kan få andra runt omkring att börja kommunicera visuellt. Det handlar om att skapa en miljö där alla känner att de kan och vill skissa för hand.

Så hur får man folk att börja skissa? Det finns nog flera sätt. Man kan, som Mårten, utbilda och inspirera folk i hur man skissar snyggt och begripligt. Man kan också försöka skapa en miljö där det inte är så viktigt att det ser snyggt ut, det handlar inte om hur utan om att man över huvud taget kommunicerar visuellt.

Fånga visionen

Ett IT-projekt börjar ofta med en idé eller vision om hur nytta kan skapas. Ofta är det någon eller några i ledningen som sitter på visionen, kanske en VD, marknadschef eller teknisk chef. Visionen ligger ofta på en hög nivå som ”vi måste ha ett nytt intranät” eller ”vi behöver en mobilanpassad webb” men det finns alltid också förväntningar och föreställningar om hur slutresultatet kommer bli, även om de inte är artikulerade.

Som interaktionsdesigner vill jag förstås vara den som gör jobbet och konkretiserar visionen till något som ger organisationen affärsnytta. Men det är också viktigt att det jag jobbar fram inte skiljer sig för mycket från beställarens förväntningar. Då kommer det bli svårt att förankra och jag kanske missar att tänka på någon viktig aspekt som gör slutprodukten nyttig. Mitt jobb blir alltså lättare om jag från början förstår förväntningarna.

Jag tror skissworkshops kan vara ett bra sätt att fånga visionen och förväntningarna. Samla ihop de från organisationen som känner starkast för projektet och som fattar besluten, desto bättre ju fler olika perspektiv som finns representerade. Låt alla rita hur de tror att resultatet kommer se ut, visa upp för resten av gruppen och diskutera hur olika skisser skiljer sig från varandra och varför.

Rita wireframes för hand eller digitalt

Som interaktionsdesigner tar man fram wireframes för att kommunicera hur ett gränssnitt ska fungera, se ut och kännas. Efter skisskursen har vi i HiQ:s UX-grupp pratat en del om att rita wireframes för hand kontra i ett digitalt verktyg som Balsamiq, Omnigraffle eller Axure.

Handritade wireframes kan vara lättare att få feedback på eftersom de inte ser lika slipade ut, även om man också kan få digitala wireframes att se handritade ut. Papper och penna är flexibelt, man begränsar sig inte till ett komponentbibliotek, och de uppmuntrar till samarbete, man behöver ju inte ha något visst program installerat på datorn för att kunna bidra till skissen.

Men digitalt producerade wireframes och prototyper har också fördelar. De är lättare att uppdatera, det går ofta t.ex. att ändra på hur sidfoten ser ut på alla sidor. De är lättare att sprida till folk som inte sitter på samma plats. Det är lättare att få en känsla för hur t.ex. en webbplats hänger ihop och fungerar när man kan klicka sig igenom en interaktiv prototyp. Användningstester blir också lättare att utföra och mer realistiska när den som testar faktiskt kan klicka på knapparna, inte bara säga var man skulle klicka.

Vad är bäst då? Självklart beror det på. Det absolut viktigaste att tänka på är syftet med de leverabler man tar fram. Hur ska de användas, för att kommunicera, samarbeta eller testa på användare? Vem är mottagaren? Hur ser arbetsprocessen ut? Kommunikationsvägarna? Vilka andra dokument kommer tas fram? Framför allt: Vad är det minsta möjliga jag kan producera för att nå syftet just nu? Vad blir mest effektivt?

Om man inte funderar på syftet med leverablerna eller hur man mest effektivt når dit, utan bara slentrianmässigt kör på i sitt favoritverktyg, blir det lätt att man lägger för mycket tid på att producera onödiga dokument som ingen kommer läsa. Det gäller så klart oavsett om man ritar skisser för hand eller tar fram avancerade digitala prototyper.

Vidare läsning

The messy art of UX sketching på Smashing mag

Introduction to Design Studio på UX Magazine

Design Studios: The good, the bad and the science på UX Booth

Design Studio and agile UX på UX Magazine

The big think: Breaking the deliverables habit på Samshing mag

Lean UX med effektkartan

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

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

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

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

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

Lean UX

Bygga mäta lära

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

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

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

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

Vad är en MVP?

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

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

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

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

Definiera en MVP med effektkartan

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

Idén – hemmafixartjänsten!

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

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

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

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

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

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

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

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

Effektmål – vad vill vi uppnå?

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

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

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

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

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

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

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

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

effektkarta

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

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

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

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

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

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

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

Hypotesen på generell form:

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

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

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

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

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

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

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

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

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

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

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

Det bästa av två världar

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

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

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

Vidare läsning

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

The UX of MVP:s av Anders Ramsay

Experiments 101 av Simon Cast

Lean Startup is Great UX Packaging av Tomer Sharon

Continous Discovery av Martin Christensen

Lean UX is not just for lean startups av Jeff Gothelf

Agile UX vs Lean UX av Anders Ramsay

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

Värdet av tidig feedback

Man har suttit och jobbat stenhårt på ett designkoncept som man tycker känns helt rätt. Men när det sedan ska presenteras för dem som bestämmer (i konsultfallet, kunden) så kommer det bara negativa kommentarer och man blir tvungen att börja om från början. Det här är riktigt jobbigt. Det sänker ens självförtroende, sinkar projektet och kostar pengar. Och det handlar, enligt min erfarenhet, sällan om att designen verkligen är så dålig utan snarare om brist på kommunikation och förankring.

Lösningen på många problem som man hamnar i som interaktionsdesigner heter tidig feedback, korta feedbackloopar och samarbete. Vi behöver tidig feedback både från kunden, från användarna och från våra kollegor.

Tidig feedback i användarundersökningar

När vi tar reda på vilka användarna är och hur deras behov och egenskaper ser ut är folk som jobbar i organisationen en källa till information. Deras bild av användarna stämmer i vissa avseenden med verkligheten, men är i andra avseenden är helt fel. En organisation som säljer mycket kan t.ex. ha koll på vilka köpbeteenden folk har men inte veta varför kunderna köper just deras produkt. När vi tar reda på vad som ligger bakom är det viktigt att vi får feedback från olika delar av organisationen tidigt.

Dels kan vi ha förstått något fel. Det kan finnas information som vi missat eller misstolkat som andra i organisationen kan hjälpa oss med. Dels blir det lättare för folk att acceptera resultatet av undersökningen (som ibland kan vara kontroversiellt) om vi presenterar det stegvis istället för i ett långt, tråkigt dokument. Dels kan vi om vi tar hjälp av personer från organisationen för att analysera resultatet lyckas få dem att se saker på vårt sätt, ur slutkundens perspektiv. På så sätt kan undersökningen göra nytta långsiktigt genom att bygga en kundorienterad kultur hos organisationen, vilket beskrivs i boken Subject to Change.

Tidig feedback i designprocessen

Alla kan tycka saker om design och oavsett hur mycket användarundersökningar vi har som kan motivera våra designval kommer folk alltid tycka saker om vår design. Ett sätt att reducera tyckandet är att låta tyckarna ge feedback och delta i designprocessen, gärna tidigt. Det blir ju som sagt lättare att acceptera ett resultat när man varit med och fått påverka det under framtagandet. Man behöver inte begränsa sig till feedback utan kan till och med låta tyckarna vara med och designa, t.ex. i en design studio-workshop.

Med hjälp av användningstester kan vi få feedback på designen från de vi designar för; användarna. Användningstester kan också göras riktigt tidigt, när det bara finns en idé om hur tjänsten ska utformas eller en grovskiss på papper. Det behövs inte interaktiva prototyper och det behöver inte ta speciellt lång tid.

Det kan också vara guld värt att få tidig feedback från kollegor. Andra interaktionsdesigners kan hitta designproblem som vi inte tänkt på. Utvecklare och arkitekter kan påpeka tekniska problem som vi måste ta hänsyn till. Vi ska göra det som är bäst för användarna och vill i en perfekt värld inte låta teknik styra design alls men i realiteten behöver vi nästan alltid kompromissa eftersom någon detalj kommer vara alldeles för dyr att implementera.

Rädslan för tidig feedback

Jag tror det finns ett rädsla för att ta emot feedback tidigt och jag tror det beror på någon sorts naiv stolthet. Man vill träffa rätt från början, förstå allt och ta fram rätt design direkt för att känna sig duktig. Vi måste alla inse att det här inte funkar. Interaktionsdesign är alldeles för svårt för att vara ett enmansjobb.

Det finns nog också en övertro på att resultatet av en användarundersökning eller ett designförslag ska tas emot bättre om den presenteras i ett snyggt format. Men vill vi ha feedback tidigt är det bättre om det inte alls ser färdigt ut. Det är lättare att vara kritisk till något som ser enkelt ut att ändra på, som en snabbskiss på ett papper. En avancerad interaktiv prototyp kan till och med tolkas som det färdiga slutresultatet.

Vidare läsning

Tidig feedback, korta feedbackloopar och samarbete är kärnan i det superspännande område som kallas Lean UX eller Agil UX.

Lean UX: Getting Out of the Deliverables Business – om att sluta vara besatt av leverabler och jobba iterativt

Agile UX and the One Change That Changes Everything – om att börja jobba agilt genom korta feedbackloopar

Boken Rocket Surgery Made Easy – om enkla, snabba och billiga användningstester

Boken Subject to Change – om hur förankring och samarbete kan skapa långsiktig nytta

Boken The Lean Startup – om korta feedbackloopar i produktutveckling