En design sprint presser måneder med frem-og-tilbake inn i fem dager. LEGO brukte den 150 ganger på ett enkelt år for å fikse en kreativ prosess som hadde stått stille i et tiår. Metoden i seg selv er enkel nok til å forklare på én side, selv om disiplinen til faktisk å gjennomføre en er vanskeligere. Hvis selskapet ditt prøver å teste en stor idé før dere bruker måneder på å bygge den, er dette verdt å forstå.
Historien bak den
For noen år siden hadde LEGOs interne kreative byrå kjørt på samme måte i omtrent et tiår – og det holdt ikke tritt. I stedet for å gli inn i endring, gjorde personen som ledet byrået noe drastisk: produksjonen stoppet i to måneder i 2017, fra april til juni, og en stor del av det interne byrået la vanlig arbeid til side for å kjøre design sprints i stedet, slik personen som ledet utrullingen senere beskrev det.
Den første uken hadde ti sprints som gikk parallelt. Innen slutten av den to måneder lange pausen hadde de kjørt rundt seksti. Innen ett år hadde de fullført over 150. LEGO bygde metoden permanent inn i hvordan det interne byrået jobbet, og brukte den til å restrukturere hvordan hele teamet opererte.
Det er en ekstrem versjon av metoden. De fleste selskaper trenger aldri å kjøre den i den skalaen. Men grunnen til at LEGO gikk så langt, er verdt å dvele ved: å teste en idé skikkelig, før du bygger den, er vanligvis raskere og billigere enn å finne ut at den ikke fungerer etter måneder med utvikling.
Hva en design sprint faktisk er
En design sprint er en måte å teste en ny idé i løpet av dager i stedet for måneder, ved å bruke et lite team og en strukturert prosess for å definere målet, skissere løsninger og teste dem med ekte mennesker før noen ekte utvikling starter. Metoden ble skapt av Jake Knapp under tiden hans hos Google, og senere publisert i boken "Sprint," skrevet sammen med to kolleger fra Google Ventures.
Poenget er ikke å bygge det faktiske produktet på fem dager. Det er å bygge akkurat nok av det – en klikkbar prototype, en mockup, en grov versjon – til å sette foran ekte mennesker og se hvordan de reagerer. Du finner ut om idéen fungerer før du har brukt tid og penger på å bygge den virkelige tingen.
Hvordan de fem dagene vanligvis brytes ned
Den eksakte strukturen varierer litt avhengig av hvem som kjører den, men kjerneformen ser slik ut:
Dag 1, forstå problemet. Teamet blir samstilt på hva de faktisk prøver å løse, og velger ett spesifikt stykke av det å fokusere på for uken.
Dag 2, skisser løsninger. Alle jobber alene først og skisserer sine egne idéer – i stedet for å hoppe rett inn i en gruppebrainstorm som har en tendens til å favorisere den som snakker høyest.
Dag 3, bestem. Teamet gjennomgår alle skissene og velger de sterkeste idéene å gå videre med, uten endeløs debatt.
Dag 4, bygg en prototype. Ikke ekte, fungerende programvare. Bare nok av en mockup til å se og føles ekte når noen prøver å bruke den. Dette er det samme prinsippet om rask prototyping bak mange gode produktbeslutninger: bygg den minste tingen som lar deg teste idéen, ikke hele tingen.
Dag 5, test den med ekte mennesker. Teamet ser på en håndfull faktiske brukere prøve prototypen og reagerer på det de ser – snarere enn det de håpet ville skje.
Innen fredagsettermiddagen vet du om idéen holder seg – før du har skrevet en eneste linje produksjonskode.
Når dette gir mening for et voksende selskap
En design sprint er verdt å kjøre når du er i ferd med å ta en beslutning som ville være dyr å ta feil. En ny funksjon som ville ta måneder å bygge. En ny produktretning du ikke er helt sikker på. En redesign som berører noe kunder allerede stoler på. I alle disse tilfellene er det billig forsikring mot måneder med å bygge feil ting å bruke fem dager på å finne ut om idéen faktisk fungerer.
Når det sannsynligvis er overkill
Ikke alle beslutninger trenger fem dager og et rom fullt av mennesker. Hvis fiksen er liten, eller teamet allerede kjenner svaret, tilfører det å kjøre en full sprint bare seremoni uten å tilføre mye innsikt. Det er heller ikke det riktige verktøyet hvis det virkelige problemet er at ingen ennå er enige om hva virksomheten faktisk prøver å oppnå. Det er en annen type samtale – en om mål og prioriteringer, ikke om å teste en spesifikk idé.
Design sprint vs. Discovery Workshop
De er ikke det samme, selv om logikken er lik. En design sprint svarer vanligvis på ett smalt spørsmål: vil denne spesifikke funksjonen eller flyten fungere, testet med en prototype og en håndfull brukere. Et Discovery Workshop svarer på et større: hva burde vi faktisk bygge, og i hvilken rekkefølge, før noe av det blir spesifisert. Tenk på en design sprint som å teste én murstein, og et Discovery Workshop som å finne ut hva du bygger med alle dem.
Hvor dette passer med måten vi jobber på
Begge eksisterer for å svare på det dyre spørsmålet før du har brukt pengene på å finne det ut på den harde måten. Hvis du har en idé du ikke er helt sikker på, og å bygge den direkte føles som en risiko du heller ikke vil ta i blinde, er et Discovery Workshop bygget for nøyaktig den samtalen.
