En designsprint er en tidsbegrænset proces, oprindeligt struktureret som fem dage, til at bevæge sig fra et problem til en testet prototype. Den blev udviklet hos Google Ventures og dokumenteret af Jake Knapp, og komprimerer aktiviteter, der ellers ville tage måneder, til en enkelt uge: at forstå problemet, generere løsninger, beslutte en retning, bygge en realistisk prototype og teste den med målgruppen.
Den oprindelige struktur tildeler én aktivitet pr. dag. Den første dag kortlægger problemet og vælger et mål. Den anden dag genererer løsninger individuelt i stedet for gennem gruppebrainstorming, ud fra den begrundelse, at individuelt arbejde producerer bedre og mere varierede ideer end åben diskussion, hvor den højeste stemme dominerer. Den tredje beslutter, hvilke koncepter der skal prototypes, gennem struktureret kritik og afstemning. Den fjerde bygger en prototype, der er realistisk nok til at teste, men ikke mere. Den femte tester med et lille antal målbrugere, typisk fem, og træffer en beslutning.
Dens værdi ligger mindre i den specifikke tidsplan end i de begrænsninger, den pålægger. At dedikere et tværfunktionelt team, inklusive en beslutningstager, til ét problem i en fast periode fjerner den koordineringsforsinkelse, der normalt strækker sådant arbejde over måneder. Kravet om en testet prototype til sidst fremtvinger konkretisering, da abstrakte diskussioner ikke kan overleve forpligtelsen til at vise noget til en kunde om fredagen. Og at have beslutningstageren til stede under hele processen forhindrer det fælles resultat, hvor en uges godt arbejde bliver annulleret af en fraværende leders senere indsigelse.
Formatet er ikke universelt anvendeligt, og det skaber skuffelse at behandle det som et generelt værktøj. Det passer til problemer, der er vigtige, tilstrækkeligt afgrænsede til at kunne løses på en uge, og reelt usikre, hvor teamet er uenige eller ikke kender svaret. Det passer dårligt til problemer, der allerede er forstået og blot skal udvikles, problemer, der kræver omfattende ny forskning for overhovedet at kunne formuleres, og problemer, hvis løsning afhænger af teknisk arbejde, der ikke kan prototypes overbevisende på en dag.
Praksis har afveget betydeligt fra det oprindelige femdagesformat, hvor firedages- og fjernvarianter nu er almindelige, og kortere versioner bruges til mere snævre spørgsmål. Tilpasningerne er rimelige, forudsat at de væsentlige elementer bevares: et klart problem, de rigtige deltagere, inklusive en person, der kan beslutte, individuel idéudvikling før gruppediskussion, en rigtig prototype og testning med faktiske brugere i stedet for med kolleger. Sprints, der dropper brugertestningen, bevarer workshoppen og mister pointen.
Udvælgelsen af deltagere er mere afgørende end tidsplanen og håndteres ofte skødesløst. En sprint med de forkerte personer resulterer i en velfaciliteret uge, der ikke ændrer noget: uden nogen, der kan beslutte, er resultatet en anbefaling, der går ind i den sædvanlige godkendelseskø; uden ingeniørrepræsentation tester prototypen en retning, der viser sig at være umulig; uden nogen, der har kundens bevismateriale, designer gruppen ud fra antagelser. Fem til syv personer, der dækker beslutningsmyndighed, design, ingeniørarbejde og kundeviden, er arbejdsgruppen, og at sikre deres reelle tilgængelighed i hele perioden, snarere end delvis fremmøde mellem andre forpligtelser, er normalt den sværeste del af at arrangere en sprint.
Den mest almindelige skuffelse er at behandle sprintet som en leverance snarere end som starten på arbejdet. Outputtet er en valideret eller ugyldiggjort retning og et sæt observationer, ikke et færdigt design, og værdien realiseres kun, hvis resultatet bidrager til den efterfølgende udvikling. I praksis betyder det at køre sprints inden for en løbende proces snarere end som isolerede begivenheder, hvor resultatet overføres til Produktdesign og leveringsarbejde i en produktstudie engagement, og med den testning, der udføres i henhold til standarderne for brugerundersøgelser snarere end som en uformel show-and-tell.