Ambita / Design Sprint på én og en halv dag

Hvorfor kart og hvorfor Design Sprint?

Infoland er en butikk som selger eiendomsdata, inkludert kart til flere forskjellige kundegrupper. Vi vet at en del kunder sliter med å bestille kart, og ser at det kan være forvirrende å orientere seg i jungelen av produkter beregnet på både profesjonelle kartbrukere, og de som kanskje bare trenger et situasjonskart for å levere inn byggesøknad på en garasje til kommunen.

Vi ønsket å utforske disse problemstillingene knyttet til kart på en rask måte, samtidig som vi ønsket at utviklere, designere og produkteiere skulle få bedre kjennskap til løsningene og hvilke problemstillinger vi sto ovenfor. Da virket Google Venture sitt Designsprint-rammeverk som en god idé, og siden vi skulle ha en 1-2-dagers hackaton i Bergen denne uken, tenkte vi at dette var en fin anledning til å få prøvd det ut. Noen av oss hadde jobbet med designsprinter tidligere, men det hadde dødd litt ut under pandemien. For andre var dette helt nytt.

Designsprint-prosessen er basert på Design Thinking-metodikk, og kombinerer brukerinnsikt, strategi, innovasjon og forretningsforståelse. Det er en effektiv og energikrevende måte å jobbe på som gir mye verdifull læring underveis. Det var bare ett problem: En designsprint går originalt over fem dager. Vi hadde to korte dager. Vi utsatte derfor de to siste dagene som skal brukes til prototyping og brukertesting til senere, og komprimerte den første delen av sprinten til å passe inn i to korte dager.

Hvem var vi?

Vi var én moderator, én/to beslutningstakere, én designer og to utviklere, alle fra teamet som jobber med Infoland til daglig. Sprint-teamet har kastet seg igang med første oppgave i sprinten.

Dag én

Først forklarte vi problemstillingen og satte oss et sprintmål. Selv om det ikke er en del av den originale metodikken, valgte vi å knytte det til noen kpi-er for å vite om vi hadde nådd målet.

Vi skrev så ned spørsmål og bekymringer for sprinten, ting som kunne hindre oss i å nå målet. 

Deretter definerte vi hvem som var aktører i kundereisen og tegnet opp hva aktørene må gjøre for å komme til målet.

Så kom ekspertene på banen, mens de presenterte, skrev alle ned Hvordan-kan-vi-spørsmål mens de hørte på problemstillingene. Vi fikk høre erfaringer fra kundesenteret, bakgrunn for valg tatt fra utvikleren som laget den originale løsningen, hva som er rapportert inn på NPS fra designeren i sprintteamet og hva som er observert i brukertester fra moderatoren. 

Da vi hadde fått på plass all denne informasjonen fikk alle stemme på hvilke problemstillinger vi skulle fokusere på og disse ble knyttet til et steg i kundereisen. Beslutningstakerne fikk det siste ordet.

En velfortjent pustepause og feiring av hva vi hadde fått til så langt fulgte!

Dag to

Dag to. Vi manglet en beslutningstaker, men var likevel klare for å ta fatt på den kreative prosessen.

Vi begynte dagen med å vise hverandre løsninger fra andre aktører som har løst ting på måter som kunne være interessant for oss i denne sprinten.

Vi var nå klare for å gå rundt i rommet og ta notater av alt som vi tror vil være nyttig for å løse sprintmålet innenfor fokusområdet vi har satt oss. 

Så produserte vi så mange ideer vi greier i stillhet, men sammen. 

Etter å ha valgt ut én ide vi ville satse på hver, skisset vi crazy 8s. Dette er en øvelse der du får åtte minutter på å lage åtte versjoner av idéen din.

Så var det tid for å lage en skisse av valgt variant som var så selvforklarende at sprintteamet kunne skjønne det på egenhånd. Det var ingen enkel oppgave! 

Da vi var ferdige med dette, laget vi et heatmap der vi satte stemmer på alle deler av tegningene vi synes var interessante.

Så fulgte en sesjon der moderatoren drar gruppa gjennom slik hen forstår en skisse, etterfulgt av at de andre kan poengtere hva som er stemt på, komme med bekymringer og problemstillinger og hva som er bra. Til slutt står den som har laget skissen frem og forteller hva som var tenkt.

Vi stemte så på hvilken løsning vi ville fokusere på, og beslutningstakeren fikk siste ord. Da sto vi igjen med to ting vi skulle gå videre med: én lavthengende frukt og én mer omfattende løsning.

Vi var endelig klar for å storyboarde, en øvelse der vi lager en tegneseriestripe av de forskjellige stegene brukeren vår skal ta. Vi rakk bare en veldig grov variant før det var på tide å vise de andre hva vi hadde jobbet med i denne hackatonen.

Hvordan tar vi det videre?

Vi ser helt klart nytten av å kunne storyboarde løsningen mer i detalj før vi prototyper den, så dette er noe vi må prøve å få til så fort som mulig. Når vi er klare til å prototype, vil vi trolig gjøre dette i Figma, siden det først og fremst er flyter og navigasjon vi skal takle. Så vil vi brukerteste de to løsningene med fem kunder. Da kan det hende vi må gjøre justeringer før vi tester igjen. Eller kanskje vi finner ut at ideene våre ikke funker i praksis? Det er jo halve poenget med en slik sprint: feile fort, før man har svidd av utallige timer og penger på løsningene.

Om vi ender opp med et par løsninger som vi mener er liv laga etter brukertestingen, blir det opp til det kryssfunksjonelle Infolandteamet og våre to beslutningstakere i sprinten; produkteierene, når dette skal prioriteres inn i roadmapen. Det er mange ting som skal tas hensyn til, som OKR-ene våre, og hvor stor påvirkning vi mener dette vil ha på kundene våre. Det viktigste nå, er at vi jobber videre med hva vi fant ut, og ikke lar dette dø, som lett kan skje i en hektisk hverdag.

Hva lærte vi?

• Vi er glade for at vi ikke prøvde å dytte inn alle aktivitetene på to dager. Selv om prototyping og testing er en svært viktig del av sprinten, ga det mening å gjøre dette i en ny blokk, siden vi hadde så dårlig tid.
• Critique-sesjonen er vanskelig, det var vanskelig å gjøre seg forstått med skisser uten å kunne forklare før helt til slutt av sesjonen. Dette krever nok noe øvelse. Det kan også hende vi skal mikse opp denne øvelsen litt sammenlignet med hva rammeverket sier, og heller lage heatmapen og critique etter at den som har laget skissen har presentert. Dette er heller ikke perfekt, siden vi da kommer til å være farget av hvem som har laget løsningen når vi stemmer.
• Det var praktisk med beslutningstakere som er de som fakstisk skal prioritere dette videre.
• Det var veldig nyttig å ha inn kundeservice som eksperter.
• Neste gang bør vi gå enda grundigere gjennom løsningen først for de som ikke kjenner den så godt. Vi bør også henge opp skjermdumper av løsningen vi jobber med i sprintrommet slik at vi hele tiden kan gå bort og se på dem. Dette er spesielt viktig for dem som ikke kjenner løsningen like godt.
• Pauser er viktig og pass på god luft i møterommet.
• Vi var glade for at vi hadde skaffet materiale på forhånd fra NPS og brukertester.
• Vi kommer nok til å bruke designsprint mer aktivt fremover, siden vi så hvor mye vi fikk gjort på så kort tid. Den største utfordringen ligger nok i å få folk til å sette av tid, blokkere ut kalenderne sine og ikke la seg distrahere av andre ting under sprinten. Dette gikk veldig bra denne gangen, men det var nok også litt fordi vi hadde satt av disse datoene i god tid i forveien.
  
  

Hvilke erfaringer har dere med designsprint der du jobber?

Vi vil veldig gjerne høre fra dere lesere hvilke erfaringer dere har gjort dere med designsprint om dere har jobbet slik. Har dere tips og triks å dele med andre når man jobber slik? Eller kanskje du lurer på noe. Legg inn en kommentar på LinkedIn under hashtaggen #kartdesignsprint!