Okay da, litt dramatisk tittel – men jeg lover at dette er positivt! For hvis du vet hva roten til et problem er, så er det jo ofte lettere å finne riktig løsning? Bli med på en tankerekke. Vi skal se nærmere på: Hvorfor bygger vi komplekse løsninger som ingen bruker? Hva sier teorien om god produktutvikling, og hvorfor fungerer den ikke alltid i praksis? I tillegg inkluderer denne løsningen to kule norske selskaper: Unleash og UX Signals. Om du er typen som liker videoformat bedre så snakket jeg om tema på Kodemakers åpne fagdag.
Jeg tror alle som leser denne bloggen er enige om at teknisk arbeid er både krevende og viktig. Likevel – det som ofte er vanskeligere, og enda mer avgjørende for suksess, er en god brukeropplevelse: å lage noe folk faktisk vil ha og bruker.
Jeg heter Marina og er det nyeste tilskuddet i Kodemaker. I tillegg til å digge koding, elsker jeg god produktutvikling. Jeg startet nemlig karrieren min på forretningsiden i DNB som forretningsutvikler og leder for eksperimentering. Før vi dykker inn i materien, vil jeg dele noen situasjoner jeg har opplevd. Kanskje du kjenner deg igjen i noen av dem?
¶Hva har disse situasjonene til felles?
En utvikler som ivrig foreslår å legge til en funksjon fordi det ville vært gøy å lære.
En Tech Lead som ikke ser verdien av produktfolk, men gjerne vil ha med animasjoner fordi de er kule.
En intern "stakeholder", uten beslutningspåvirkning, som stadig har nye ideer til hva som kunne vært kult å ha.
En produktleder som ikke aner hvordan den nye funksjonen ble mottatt, og hopper videre til neste i backloggen.
En sjef, også kjent som HIPPO, "Highest Paid Person's Opinion". Innsikt peker på alternativ A som beste løsning, men HIPPO har en magefølelse for alternativ B. "Så da gjør vi det, dere!"
Det er jo til å bli gal av – er det ikke? Hva har alle disse situasjonene til felles?
Ingen av situasjonene reduserer risikoen for at man bygger feil løsning.
Bit deg merke i ordet risiko. Risiko er ofte forbundet med noe kjedelig, som en omvei. I produktutvikling derimot er det paradoksalt nok en snarvei.
I bunn og grunn viser disse situasjonene hvor lett vi lar personlige meninger styre produktutviklingen. Uavhengig av stillingstittel, er dette nettopp det de er – meninger. Personlige meninger kan være fine de, de kan til og med være riktige, men oftest er de antagelser sagt på en selvsikker måte – og de mest risikable antagelsene burde valideres med innsikt. Her kan en aldri så liten prioriteringsmatrise for antagelser gjøre underverker. Ved å plassere antagelser i en 2x2-matrise basert på usikkerhet og konsekvens, får produktteamet en strukturert måte å redusere risiko på. Etter gjennomført kartlegging har jeg selv opplevd en deilig følelse av å ha oversikt over alt vi vet, alt vi ikke vet og se krystallklart hvilke antagelser det er mest kritisk at vi tester (derav snarvei). Det finnes til og med maler som kan brukes for å komme raskt i gang.
Raskt i gang vil vi. For hvis ikke, fører mylderet av personlige meninger til at omfang og kompleksitet vokser, og vi glemmer det opprinnelige problemet vi prøvde å løse. Før vi vet ordet av det befinner vi oss i en klassisk UX-felle. Illustrert under med 2 fjernkontroller.
Hvilken foretrekker du? En overlesset fjernkontroll med knapper, les funksjoner, ingen bruker? Eller den som gir deg akkurat det du trenger uten forvirring?
Vi burde spørre oss selv oftere: Bygger vi riktig ting – eller bare flere ting? Av og til lønner det seg faktisk å være litt mer dum og følge designprinsippet KISS – “Keep it simple, stupid!” Jo mer komplekst et produkt blir, desto vanskeligere blir det å bruke. Og hvis noe er vanskelig å bruke, bruker folk det rett og slett ikke. Scott Belsky sier det slik:
Users flock to simple product.
Product adds features, evolves, and takes users for granted.
Users flock to simple product.
Med andre ord: Vi bygger og bygger basert på personlige meninger og antagelser om hva brukerne vil ha, helt til produktet blir for komplisert at brukerne flykter til noe enklere som faktisk tar høyde for deres behov.
¶Hva sier teorien om hvordan bygge de rette produktene?
Tankerekken fortsetter i full fart og nå er spørsmålet: Hvordan unngår vi å bygge kompliserte fjernkontroller? Hva sier teorien om hvordan bygge de rette produktene? La oss slå opp i bibelen for produktutvikling: “Inspired - How to create tech products customers love” skrevet av Marty Cagan. Hvis du driver med produktutvikling, uavhengig av rolle, bør du lese denne. Det synes også denne særdeles begeistrede bokanmelderen som kommer fra utviklerverden og er Engineering Manager. Ifølge Cagan gjør de beste produktteamene 3 ting riktig. Husker du risiko? Det blir relevant nå.
1 De håndterer risiko før de bygger løsningen
De beste produktteamene håndterer risiko før de bygger løsningen. Risiko deles opp i fire forskjellige typer:
- “Desirability risk” - at løsningen gir verdi og er ønsket av noen.
- “Usability risk” - at løsningen er brukervennlig og enkel å forstå.
- “Feasibility risk” - at løsningen er teknisk gjennomførbar.
- “Business viability risk” - at løsningen er bærekraftig eller lønnsom for selskapet.
“Desirability risk” er ofte det viktigste å teste først – hvis ingen vil ha funksjonen eller produktet, spiller de andre risikoene ingen rolle.
2 Utformer produktet på tvers av fagrettninger
Den andre tingen de beste produktteamene gjør er å utforme produktet sammen på tvers av fagområder. Design, tech & produkt - jobber tett sammen og kommuniserer godt. En fin effekt av dette er at du slipper masse dokumentasjon og kravspesifisering når alle har vært innblandet i utformingen og bidratt med sin komplementære kompetanse.
3 Løser underliggende problemer og skaper resultater
Sist, men ikke minst – kanskje til og med størst: De beste produktteamene løser de underliggende problemene og skaper resultater for virksomheten, ikke bare funksjoner. Kompliserte fjernkontroller oppstår når vi bare fokuserer på funksjoner og løsninger. Funksjonen som bygges skal jo føre til noe, som økt salg eller kundeengasjement. Det burde måles.
Utforskning før utførelse: En suksessoppskrift i produktutvikling
Produktutvikling involverer to nøkkelfaser: utforskning (Discovery) og levering (Delivery).
- Utforskning (Discovery): Denne fasen handler om læring og validering. Målet er å raskt teste og forbedre løsninger, med fokus på de mest risikable antagelsene. Verktøy som prototyper og brukerintervjuer er avgjørende for å samle inn tilbakemeldinger og ta informerte beslutninger. I eksempelet under ser du 5 iterasjoner fra et skateboard til personbil. For hver iterasjon reduserer du risikoen for at du feiler på de fire risikoene og heller ender opp med et produkt noen faktisk vil ha og bruker.
- Levering (Delivery): I stedet for å levere først antatt personbil, bygger vi (basert på læringen), i stedet en pickup. Fokuset i leveransefasen er å bygge et produkt av kvalitet. Ting vi tenker på i denne fasen er skalerbarhet, pålitelighet, god ytelse og at produktet skal være enkelt å vedlikeholde.
Innsikt fra den utforskende fasen drypper kontinuerlig ned til leveransefasen, noe som gjør det til en iterativ prosess, ikke fossefall. Kort sagt, utforskning handler om å finne ut hva og hvordan vi skal bygge, og leveransefasen handler om å eksekvere og bygge det godt.
Som utvikler kan jeg bygge ekstremt raskt i leveransefasen hvis vi har validert ting godt på forhånd og fjernet risiko. I et tidligere prosjekt var mitt team helt ferdig med en ny funksjon og vi var klare til å levere til produksjon, men vi ble stoppet rett før målstreken fordi vi hadde en avhengighet til et annet team som ikke var klare før om flere måneder. Her feilet vi altså på “Feasibility”, også kjent som gjennomførbarhet. Det kunne lett vært avklart i den utforskende billige fasen, i stedet for etter mange måneder med dyr bygging i leveransefasen. Høres det kjent ut? Dessverre er mange selskaper dårlig på den utforskende fasen, men spørsmålet er hvorfor? Tankerekken fortsetter.
¶Hvorfor fungerer ikke alltid teorien i praksis?
Det er mye jeg kan nevne her, men jeg ser hovedsakelig et stort problem.
Dette er meg i mitt forrige liv, i den utforskende fasen for å redusere risikoen for at vi bygget feil løsning. Her analyserer jeg notater fra brukerintervjuer – og jeg kan skrive under på at den utforskende fasen er mye jobb! Vet dere hva en av de største utfordringene var? Rekruttering til brukerintervjuer. Det stjal enormt mye tid. Denne prosessen tok mange uker og involverte mange forskjellige folk. Jeg skal ikke gå inn på alt, for da blir dette blogginnlegget veldig langt. Men vi måtte gjøre alt fra: å jobbe med CRM for å få en relevant kundeliste – til å vente på at kunder agerte på e-postene vi sendte ut.
Med en slik prosess er det klart man sjeldent snakker med kunden og det er ikke så rart at den utforskende fasen blir nedprioritert. Cagans modell viser oss hvor avgjørende raske, hyppige og rimelige iterasjoner er. Er vi da dømt til å bygge produkter kun basert på personlige meninger?
Heldigvis ikke.
Da jeg jobbet i DNB, utviklet vi en løsning som:
- Reduserte bookingtiden for kundeintervjuer fra uker til timer.
- Gjorde det mulig å endre bookingskjemaet på sekunder – uten ny kodeutrulling.
- Kuttet den direkte kostnaden per intervju med over 84 % sammenlignet med en undersøkelse fra Norstat.
Kostnadsbesparelsene blir enda bedre når du tenker på alle de som var involvert i flere uker med den gamle prosessen. Høres for godt ut til å være sant, eller hva? Vel, det er fullt mulig når løsningen bygger på de to kule norske selskapene jeg nevner innledningsvis.
¶Løsningen: En intervjubookingswidget
Widgeten er bygget med UX Signals – styrt gjennom Unleash. Denne lille rakkeren førte til ukentlige kundesamtaler. Plutselig er det mulig å validere de mest risikable antagelsene raskt og billig! Over ser dere hvor glad noen på forretning blir når vi får fylt opp alle intervjutidene på bare 3 timer.
Det fine er at du kan legge widgeten hvor enn du måtte ønske. Vi kledde den i DNB/Sbanken-drakt og integrerte den direkte i DNBs nettbank. Widgeten forenklet bookingprosessen betydelig: den deaktiveres automatisk når alle tider er booket, aktiveres igjen ved en kansellering, og håndterer alt fra kalenderinvitasjoner til påminnelser og sletting av persondata. Dette sparte oss for mye manuelt arbeid. Takk, UX Signals!
I tillegg brukte vi Unleash, en norsk open source-plattform for feature management. Med Unleash kunne vi enkelt styre hvilken widget som vises og hvordan, ved hjelp av feature-flags og varianter. For eksempel kunne vi sette opp et påmeldingsskjema i demo-modus med begrenset eksponering, eller konfigurere at widgeten bare vises for brukere med en spesifikk URL-parameter. Endringer ble reflektert umiddelbart uten behov for ny kodeutrulling. Deilig, ikke sant?
Vi begynner å nærme oss slutten av denne tankerekken. Hvis du kjenner deg igjen i mylderet av personlige meninger og vil unngå å bygge en overkomplisert fjernkontroll, vet du nå at det finnes gode alternativer. To kule norske selskaper hjelper deg å gå fra gjetting til data-drevet utvikling. En interviewbooking-widget som den vi bygget i DNB, gjør rask og billig læring i den utforskende fasen mulig. På den måten slipper du få dyre overraskelser i leveransefasen og du øker sannsynligheten for at noen faktisk vil ha og bruker tjenesten du har bygget. Det mine damer og herrer, er roten til alt vondt i produktutvikling. Har du en annen oppfatning? Jeg hører gjerne refleksjoner eller tilbakemelding!
