Og mange ganger: så er vi fornøyde med det. Vi har jo levert en løsning som vi har tro på ut til brukerne, og det ligger mange andre problemer tilgjengelig som en kan ta tak i nå. Men har vi egentlig løst problemet? Eller har vi bare antatt at det vi laget faktisk løste problemet?

Vi har tatt en antagelse. Og antagelser er skumle - rett og slett fordi de kan være feil!

Jeg jobber som interaksjonsdesigner i et tverrfaglig team som utvikler digitale løsninger, og det siste året har vi jobbet hypotesedrevet. I dette innlegget skal jeg fortelle litt om hvordan vi har brukt testkort som utgangspunkt for gode diskusjoner og litt om hvor vanskelig det er å leve med at vi faktisk har antagelser.

For å bli mer bevisst våre antagelser så har vi jobbet med hypoteser gjennom såkalte «testkort», hentet fra Osterwalders Test card.

Målet med å få opp en hypotese er å kjøre et eksperiment der man prøver å bekrefte eller avkrefte hypotesen. For så å lære om hva som faktisk er riktig.

Vi har typisk jobbet med hypotesene i arbeidsmøter der alle fagfelt er med: design, utvikling og produkteier. Da har vi diskutert hvilke antagelser vi har om løsningen, hva vi vil finne ut av og hvordan vi kan finne ut av det.

Testkortet

1. Problemet vi ønsker å løse. Hva er «ståa nå»? Noen ganger er dette noe en antar, og noe ganger er dette noe en faktisk vet er et problem. Noen ganger har vi nok innsikt på problemet og da har vi bare strøket over og sagt «Vi vet at – det og det – er et problem for ...»
2. Løsningen: hva tenker vi å gjøre for å løse problemet. Kanskje er vi enige om hvordan vi tror vi bør løse det, kanskje trenger vi å jobbe lenge med å finne en løsning vi har tro på. Kanskje det skisseres mye. Kanskje det kjøres store workshop for å generere nye innovative løsninger. På lik linje med at problemet kan være et stort og fluffy problem eller et lite konkret problem, så kan også løsningen noen ganger være innovativ og kjempespennende, eller veldig konkret og lite tidkrevende.
3. Utfall: Hva vil løsningen føre til. Her kunne vi kanskje endret teksten til «Så tror vi at vi vil se ...». Det er gjerne her den største usikkerheten ligger. Det er dette utfallet vi prøver å teste og lære om er riktig eller ikke. I diskusjon med teamet så er det veldig tydelig at hvis vi ikke har et godt svar her, så må vi kanskje revurdere hele løsningen.

Måling: hvordan kan vi se at utfallet vi tror vil skje, faktisk skjer? Her tenker jeg på ordet «måle» i en bred forståelse: det kan være både kvalitative og kvantitative målinger. Her må en designe «et eksperiment» for å avkrefte eller bekrefte hypotesen, og det kan gjøres på så utrolig mange måter! Og det er dette som er det virkelig vanskelige. Kanskje er det å sette en liten løsning ut i prod, og kanskje er det å lese forskningsartikler eller gjøre en større test på folk?

Et eksempel på et utfylt testkort for en A/B-test

Læringskortet

Her oppsummeres det dere trodde (altså selve hypotesen) og hva dere lærte. Ble hypotesen bekreftet eller avkreftet? Og hvorfor?

Testkortene henger oppe på veggen og minner meg på i hverdagen hvor viktig det er å vite og ikke bare anta.

Er ikke disse testkortene et veldig strengt format? Nei. Dette er ikke en mal som skal følges til punkt og prikke. Jeg tror ikke det har noen verdi å bare fylle ut testkortet. Det bør være et grunnlag for å styre teamets diskusjoner. Hvis testkortet blir brukt som diskusjonsgrunnlag så har det hjulpet meg i arbeidsmøter med teamet til å fokusere på hvorfor lager vi det vi lager. Vi skal ikke snakke om «vi skal lage dette eller dette». Men at vi istedenfor ordlegger oss i formen «Vi tror at vi bør lage dette fordi det og det blir bedre».

Å forstå og skrive hypoteser er ikke vanskelig, og derfor noe alle i teamet kan samle seg rundt. I et autonomt team skal alle, både produkteier, designer og utvikler, ta ansvar for å vurdere om vi jobber med det som er riktig. Disse testkortene har hjulpet i arbeidsmøter til å styre diskusjonene inn på det som er viktig å snakke om. Det er så mye mindre viktig å snakke om hva jeg tror og hva du tror, i motsetning til å snakke om hvordan vi faktisk kan finne ut og vite.

Å sette av tid og få en rutine for å samle teamet til å analysere og snakke om hva vi FAKTISK lærte, har vært veldig spennende. Det skaper en felles forståelse i teamet og tydeliggjør hva veien videre blir. Å ta seg tid til læringskortet kan være skikkelig vanskelig, men jeg har erfart igjen og igjen at dette er veldig nyttig. Læringskortet er også fint for å enkelt dele lærdom med andre, for eksempel til ledelse eller andre team.

Gi deg selv en påminnelse om når du skal sjekke hypotesen. Har du for eksempel lansert noe til prod og satt på målinger, så er gjerne oppgaven satt til «done» i Jira/Trello, og da er det så lett å glemme å se på den igjen. Mitt triks ble da å lage en påminnelse i kalenderen som sier ifra hvilken hypotese jeg skal se på etter for eksempel to-tre uker.

Å endre mentaliteten rundt at vi ikke vet, men at vi tror, kan være vanskelig! Fordi plutselig så blir en mer bevisst på at en lever i en stor usikkerhet. Da prøver jeg å minne meg på at det er helt ok, fordi vi jobber jo med ting som skal lages i fremtiden og det er ikke noen andre som heller vet hva som er riktig. Husk på at det er helt ok å ikke vite, men da må en i hvert fall bruke tid og arbeidskraft på å utforske og lære! Og det har jeg erfart at hypoteser kan hjelpe å sette fokus på.