Vi träffades en kväll i Crisps lokaler på Sveavägen ett gäng intresserade agila UXare, coacher och utvecklare för att prata om något som vi alla tycker är spännande, vill dela med oss av och lära av varandra – hur man kan arbeta med att upptäcka och utforska produkter och tjänster i ett agilt team – Product Discovery. Ett Product Discovery-team innehåller oftast tre roller, där ingår en person med fokus och stenkoll på de affärsmässiga förutsättningarna och målen (PO), en person med användbarhets och upplevelse-kompetens (UX) och en person som kan avgöra hur enkelt eller svårt det är att implementera (Utvecklare/Arkitekt).
Vi pratade om vilka metoder man kan använda för att utforska och lära sig mer om målgrupper och behov och hur detta kan kopplas mot effektmål och visualiseras. Men också om hur man skulle kunna gifta i hop Discovery och Delivery-processen till en helhet utan överlämningar och vi och dom känsla. Vilket vi kallade “Continuos Discovery” – kanske myntade vi ett nytt begrepp?
Vår facilitator Hans Brattberg började med att visa en ett par slides från Jeff Pattons PO-utbildning som handlar om hur man traditionellt har sett på produktutvecklingen som en “Output” där man utvecklar en produkt, men att vi nu vill se på helheten och titta på vad produkten åstadkommer för användarna, “Outcome”. Det är den förändrade helhetsbilden som gör att man skapar livsdugliga produkter som skapar mervärden för användarna. Det är där Product Discovery processen kommer in genom att titta på hur produkten kan uppfylla användarmål som kopplat till effektmål som sedan ligger till grund för utvecklingen.
Om vi alla alltid ställer oss de här 3 frågorna oberoende av vart och när och till vem vi måste ställa dom:
- Vem ska använda det här?
- Vad vill dom göra?
- Varför vill dom göra det?
Då tror vi att vi kommer att leverera mycket bättre resultat och ha en ökad förståelse för användarna, deras mål och därför skapa mycket bättre lösningar.
Diskussioner om metoder och exempel från verkligheten
Vi pratade om olika metoder som vi som jobbar med UX i agila projekt använder oss av. Bland annat pratade vi om och visade exempel på effektkartor – visar på kopplingar mellan effektmål i organisationen och målgruppernas behov, åtgärder samt mätpunkter. Vi pratade också om vikten av att koppla detta till verkligheten och sätta en tidsaspekt på det i en Road Map där man kan titta på NÄR effekterna ska uppnås. Samt på hur man planera utvecklingen genom Story Mapping (läs mer om det i ett annat blogginlägg jag har skrivit) i enlighet med Jeff Pattons metod för att få fram storys och tasks kopplat till personas och mål och skapa en MVP / MGP (Minimum Viable Product – Minsta Gångbara Produkten).
Vi pratade självklart en hel del om hur och när man kan testa och få feedback så snart som möjligt och från vem man vill ha feedback av. För oss som jobbar med UX är det kanske en självklarhet att man kan testa många gånger innan man ens har börjat utveckla. Man kan självklart testa prototyper, på papper, klickbara wireframes eller kodade. Men man kan också testa strukturer och modulera begrepp – eller som Martin berättade att han just nu testade en vision, ett par meningar – uppfyller den här visionen dina användarmål? Man kan även testa på befintliga produkter genom tex A/B tester för att se vilka förändringar som ger bäst resultat i form av tex intäkter eller downloads, bara man har en hypotes som grund för testerna så att man kan utvärdera resultatet annars är det lätt att hamna i conversion rate-fällan och tro att allt bara blir bättre fast man kanske tittar på fel mål.
Martin berättade om hur han i ett test hade bjudit in en användargrupp och gått igenom de olika stegen i produkten för att få direkt feedback på vad som var bra och dåligt i de olika stegen. Vilket gav honom en bra grund för hans förändringsarbete på produkten.
Anette visade olika exempel på Experience Mapping och vi pratade om olika sätt att visualisera och sätta sig in i användarupplevelsen genom tex workshops, intervjuer och den mer extrema varianten – Body Storming. Alla sätt är bra, bara man frågar användarna och tänker utifrån deras motivation så har man kommit en lång bit på vägen mot en bättre upplevelse och en bättre produkt.
Hasse citerade någon annan smart agil person som ska ha sagt ungefär “Ett lyckat projekt har aldrig ett lyckligt team. Och ett lyckat team har aldrig en lyckad produkt”. För visst är det så, man kan sitta på sin kammare och tycka att man har gjort en superprodukt – men sen blir det en flopp för att den inte uppfyllde något behov, eller ingen var villig att betala för den. Eller så skapar man värsta dundersuccén, men teamet är ändå missnöjt för man tänker på allt man kunde har gjort lite bättre. Vi har nog alla erfarenhet av båda fallen.
Konsten att utveckla en produkt man vill ha
Vi pratade om Kano-modellen som visualiserar hur behovet hos användaren måste uppfyllas för att nå en positiv upplevelse – men också vad som händer om man gör mer än att bara uppfylla de basala behoven. Om hur man måste tänka på vilka grundbehoven (basic) i en produkt/tjänst som måste finnas för att vi inte ska använda den i huvud taget och vad man tycker är “ju mer desto bättre” (performance) och det som kommer ovanpå och skapar “vill ha” effekten (excitement).
Design Studio-metoden
Hasse visade en film där ett gäng industridesigners jobbar enligt Design Studio-metoden för att upptäcka och hitta bättre designlösningar och produkter tillsammans i grupp genom olika workshops. När man jobbar enligt Design Studio-formatet så workshopar man, undersöker, skissar och utvärderar tillsammans de idéer som kommer fram. Det kan man göra på vilken produkt eller tjänst som helst och det kan ta allt från ett par dagar till ett par timmar.
Detta ingår i en Design Studio:
- Sätta gränser för workshopen (hur lång tid, vad ska uppnås?)
- Skissa
- Presentera
- Kritisera
- Iterera
Tvärfunktionella team – inte tvärfunktionella individer
Vi gled in lite på tvärfunktionella team och hur det i bland uppfattas som att en individ ska kunna utföra alla uppgifter som behövs i ett team (en sån person har fortfarande inte setts till). Det kan i bland vara så att man i vissa organisationer inte tycker att en UXare passar in i utvecklingsteamet (Product Delivery) bara för att UXaren inte kan koda. Hasse visade modellen för Lean utveckling och värdeströmmar. Där det tvärfunktionella teamet ska kunna lösa allt som finns inom projektet. Teamet bör då innehålla T-formade personer med en spetskompetens som kompletterar de andras, men också med en bred kompetens inom flera närliggande områden så att man kan hjälpa till med lite annat också. Det går nämligen inte att ha bara experter i ett tvärfunktionellt team, inte heller kan man ha bara generalister. Vi bör alla alltså vara intresserade av vad teamet som helhet kan uppnå och hugga i där det behövs. En UX-are i ett Product Delivery-team kan kanske till exempel skapa interaktionsdesign, grafisk design, testa och vara Scrum Master och kan därigenom hjälpa teamet att uppnå målet att skapa en användbar produkt. Vi var alla överens om att ett tvärfunktionellt team PÅ RIKTIGT är den bästa förutsättningen för ett lyckat resultat.
Om en månad ses vi igen och fortsätter genom att testa på olika workshopmetoder och utvärdera dessa tillsammans. Kanske finner vi receptet på den perfekta Product Discovery processen 🙂
