Design Sprint

En designsprint er en tidsbegrenset prosess, opprinnelig strukturert som fem dager, for å gå fra et problem til en testet prototype. Utviklet hos Google Ventures og dokumentert av Jake Knapp, komprimerer den aktiviteter som ellers ville tatt måneder til én uke: å forstå problemet, generere løsninger, bestemme en retning, bygge en realistisk prototype og teste den med målbrukere.

Den opprinnelige strukturen setter av én aktivitet per dag. Den første dagen kartlegger problemet og velger et mål. Den andre dagen genererer løsninger individuelt i stedet for gjennom gruppeidémyldring, basert på begrunnelsen at individuelt arbeid produserer bedre og mer varierte ideer enn åpen diskusjon, der den høyeste stemmen dominerer. Den tredje bestemmer hvilke konsepter som skal prototypes gjennom strukturert kritikk og avstemning. Den fjerde bygger en prototype som er realistisk nok til å teste, men ikke mer. Den femte tester med et lite antall målbrukere, vanligvis fem, og produserer en beslutning.

Verdien ligger mindre i den spesifikke tidsplanen enn i begrensningene den pålegger. Å dedikere et tverrfaglig team, inkludert en beslutningstaker, til ett problem i en fast periode fjerner koordineringsforsinkelsen som vanligvis strekker slikt arbeid over måneder. Å kreve en testet prototype til slutt tvinger frem konkretisering, siden abstrakte diskusjoner ikke kan overleve forpliktelsen til å vise noe til en kunde på fredag. Og det at beslutningstakeren er til stede gjennom hele prosessen forhindrer det vanlige resultatet der en uke med godt arbeid blir ugjort av en fraværende leders senere innvending.

Formatet er ikke universelt anvendelig, og det å behandle det som et allsidig verktøy skaper skuffelse. Det passer til problemer som er viktige, tilstrekkelig avgrensede til å kunne adresseres på en uke, og genuint usikre, der teamet er uenig eller ikke vet svaret. Det passer dårlig til problemer som allerede er forstått og bare trenger å bygges, problemer som krever omfattende ny forskning for å kunne rammes inn i det hele tatt, og problemer der løsningen avhenger av teknisk arbeid som ikke kan prototypes overbevisende på en dag.

Praksisen har avviket betraktelig fra det opprinnelige femdagersformatet, med firedagers- og fjernvarianter nå vanlige, og kortere versjoner brukt for smalere spørsmål. Tilpasningene er rimelige, forutsatt at de essensielle elementene består: et klart problem, de riktige deltakerne inkludert noen som kan bestemme, individuell idéutvikling før gruppediskusjon, en ekte prototype og testing med faktiske brukere i stedet for med kolleger. Sprinter som dropper brukertestingen beholder workshopen og mister poenget.

Utvalget av deltakere er mer avgjørende enn tidsplanen og håndteres ofte uforsiktig. En sprint med feil folk gir en godt tilrettelagt uke som ikke endrer noe: uten noen som kan bestemme, er resultatet en anbefaling som går inn i den vanlige godkjenningskøen; uten ingeniørrepresentasjon tester prototypen en retning som viser seg å være umulig; uten noen som har kundebevis, designer gruppen ut fra antagelser. Fem til syv personer som dekker beslutningsmyndighet, design, prosjektering og kundekunnskap er arbeidsgruppen, og å sikre deres reelle tilgjengelighet for hele perioden, i stedet for delvis oppmøte mellom andre forpliktelser, er vanligvis den vanskeligste delen av å arrangere en.

Den vanligste skuffelsen er å behandle sprinten som en leveranse snarere enn som starten på arbeidet. Resultatet er en validert eller ugyldiggjort retning og et sett med observasjoner, ikke et ferdig design, og verdien realiseres bare hvis resultatet bidrar til senere utvikling. I praksis betyr dette å kjøre sprinter i en kontinuerlig prosess snarere enn som isolerte hendelser, med resultatet videreført til produktdesign og leveringsarbeid i en produktstudio engasjement, og med testingen utført i henhold til standardene til brukerforskning snarere enn som en uformell vis-og-fortell.