De två sista veckorna som har gått har jag haft möjligheten att få jobba med hängivna och duktiga utvecklare och en ny product owner i ett nytt spännande utvecklingsprojekt. Jag har dessutom passat på att använda mig av en av mina favoritmetoder, story mapping (läs mer på skaparen Jeff Pattons webb).
Som grund för story mappingen började jag med att visa och beskriva vilka målgrupperna för vår produkt är, som personas med behov, användarmål och problem, och till det effektmålen som vi vill uppnå kopplat till affärsmål och dessa målgrupper. Under två intensiva dagar lyckades vi sedan skapa en story mapping över användarnas alla aktiviteter och delaktiviteter i produkten, från början till slut. Som vi sedan tillsammans med PO prioriterade för release 1 och 2, gjorde user storys av och sedan efter mycket trixande (tyvärr) lyckades få in i Jira (inte mitt favoritverktyg… men har man ett team i Sverige och ett utomlands så måste man i bland). Det betyder att alla som är med i projektet från PO, projektledare, UX, design, backend- och frontendutvecklare tillsammans har målat upp en ganska exakt målbild för produkten där alla vet exakt vem av målgrupperna som vill spara ett event till sin kalender, eller hur sökningen skulle fungera med förslag när man skriver text och vilka filtreringar som ska finnas för att användaren ska hitta det de är ute efter på bästa sätt.
Det här var för mig en riktig WOW-känsla. Nu känns det så himla bra för mig som “ansvarig” för användarupplevelsen att veta att det är faktiskt inte bara jag som har förståelse för varför den här informationen bör finns på just den här sidan eller varför ett visst typ av innehåll inte behöver vara prioriterat i menyn. Det betyder också i förlängningen att alla i projektet kommer att kunna fatta initierade beslut om detaljer i användarupplevelsen utan att behöva känna att de inte vågar. För sådana tillfällen kommer hela tiden, scenarios man inte har tänkt på, eller nya situationer eller funktioner som kommer in och måste fungera. Då ställer man sig bara frågan för VEM ska vi göra den här, VAD ska de uppnå för användarmål och VARFÖR vill de använda den? Finns inte svaret så ska den troligtvis inte vara med och då kan alla förstå det. Det kanske inte alltid blir rätt ändå, men det gör inget, då kan de själva upptäcka och antagligen rätta till det. Då kan vi lösa många av frågorna som dyker upp tillsammans på ett mycket bättre sätt än om man bara skulle få en funktionslista under näsan och försöka förstå anledningen till funktionerna (dom flesta är inte tankeläsare så vitt jag vet).
Att driva ett projekt på det här sättet är inget nytt, men det är ändå förvånansvärt sällan det blir av. Ofta arbetar man i silos, förstudie, koncept, design och interaktionsarbete sker separat från utvecklingen. Ofta arbetar man också i vattenfallsprojekt genom hela idé och konceptfasen, trots att man arbetar agilt i utvecklingsfasen. För mig är det en självklarhet att man kan arbeta agilt även med koncept. Man planerar tillsammans vilka aktiviteter som ska göras, får en gemensam förståelse, ett gemensamt mål och ett gemensamt uppdrag. Man utforskar produkten genom användarna tillsammans. Man skapar en backlogg på vad som ska göras, tidsestimerar, prioriterar, har daily standups framför tavlan och berättar vad man har gjort, vad man ska göra i dag och om man har problem. Det fungerar hur bra som helst även när man arbetar med koncept, och är mycket roligare när man jobbar ihop och man kan dela med sig av sina erfarenheter och problem. Man lär sig dessutom från gång till gång vad som fungerade bra och inte – och man får en transparens som inte finns annars.
Om man då så snart som möjligt kan arbeta ihop med olika kompetenser för att skapa sig en förståelse för – och ta fram förslag på vad man ska bygga, för vem och vad som går att göra rent tekniskt så har man enorma möjligheter att verkligen göra en produkt som man kan tjäna pengar på, som folk vill ha – och som går att bygga inom tidsram och budget. Hinner man inte utveckla allt så kan man då mycket lättare prioritera bort det minst viktiga för användaren – och ändå få en produkt som uppfyller användarmålen och går att sälja och tjäna pengar på.
Som avslutning på den här kreativa planerings- och uppstartsvecka höll vi ett kort men bra retro, där det visade sig att många tyckte att de hade fått en väldigt bra bild av konceptet, målgrupperna och för HELA produkten – tack vare story mappingen. Jag kommer definitivt att propsa på få med det även i mitt nästa projekt 🙂
För att återkomma till nuet, efter den här lilla WOW-upplevelsen jag hade – och kanske även uppfyllelsen av min egna vision, alla ska vara med och förstå tillsammans, så kom nästa WOW grej i dag när jag satt och skapade en klickbar prototyp inför användartester jag ska hålla i morgon. Den perfekta fortsättningen på det här upplägget är ju förstås att ALLA i projektet (och jag menar ALLA) får hålla användbarhetstester genom hela utvecklingen. Vilken fantastisk sak! Alla har då möjlighet att testa det vi har skapat tillsammans, att få förståelse för hur användaren resonerar och reagerar på det de själva har designat, kodat eller gett förslag på. Det tror jag skulle få alla att växa en meter minst av stolthet när de ser hur användaren gillar små smarta funktioner, eller hur de upptäcker att de faktiskt kan lösa de problem som användaren stöter på. Det är ju det som är så fantastiskt kul med att göra en produkt – att den att gillas, används och löser problem för riktiga människor!
Jag föreslår därför att det här tas med i DOD (definition of done) för hela projektgruppen – finns det ingen sån så skapar vi en sån, med ett rullande användbarhets-testschema precis som utvecklingsteam oftast har för att testa koden löpande. Fast då utifrån de userstorys som är till grund för det man har byggt, som även är kopplade till användarscenarios. Nu när alla kan produkten från aktivitet och ner till minsta funktion så kommer det att gå galant. Då behöver inte jag längre ha den lite småtrista rollen som “användarexperten” som ska komma och granska och testa och sen refusera och försöka få in ändringar i nästa, eller näst-nästa sprint. Det blir då i stället ett gemensamt ansvar och ett naturligt lärande inom hela teamet där alla är engagerade och alla lär sig mer och mer om produkten och användarna – och hur man kan ta fram smartare lösningar framöver för användaren.
Jag håller gärna en liten 5 min kurs i hur man håller användbarhetstester och ger er mallen för testet… det är inte svårt, alla som vill kan!
För er som vill lära er hur man gör story mapping och andra bra produktutvecklingsmetoder från mästaren Jeff Patton själv så håller han Produkt Owner-kurser genom Crisp – som passar för alla som vill vara med och bygga bra produkter. Han återkommer i vår för nästa kurs.
Jag håller även en kurs i UX-metoder med just Story Mapping som en av delmomenten. Välkommen!
