Design Sprint

En designsprint är en tidsbestämd process, ursprungligen strukturerad som fem dagar, för att gå från ett problem till en testad prototyp. Utvecklad på Google Ventures och dokumenterad av Jake Knapp, komprimerar den aktiviteter som annars skulle ta månader till en enda vecka: att förstå problemet, generera lösningar, bestämma en riktning, bygga en realistisk prototyp och testa den med målanvändare.

Den ursprungliga strukturen tilldelar en aktivitet per dag. Den första dagen kartlägger problemet och väljer ett mål. Den andra genererar lösningar individuellt snarare än genom gruppbrainstorming, utifrån resonemanget att individuellt arbete producerar bättre och mer varierade idéer än öppen diskussion, där den högsta rösten dominerar. Den tredje bestämmer vilka koncept som ska prototypas genom strukturerad kritik och omröstning. Den fjärde bygger en prototyp som är tillräckligt realistisk för att testa men inte mer. Den femte testar med ett litet antal målanvändare, vanligtvis fem, och tar fram ett beslut.

Dess värde ligger mindre i det specifika schemat än i de begränsningar det medför. Att dedikera ett tvärfunktionellt team, inklusive en beslutsfattare, till ett problem under en bestämd period eliminerar den samordningsförsening som normalt sträcker ut sådant arbete över månader. Att kräva en testad prototyp i slutet tvingar fram konkretisering, eftersom abstrakta diskussioner inte kan överleva skyldigheten att visa något för en kund på fredag. Och att ha beslutsfattaren närvarande hela tiden förhindrar det vanliga resultatet där en veckas bra arbete ogiltigförklaras av en frånvarande chefs senare invändning.

Formatet är inte universellt tillämpligt, och att behandla det som ett allmänt användbart verktyg skapar besvikelse. Det passar problem som är viktiga, tillräckligt avgränsade för att åtgärdas på en vecka, och genuint osäkra, där teamet är oense eller inte vet svaret. Det passar dåligt för problem som redan är förstådda och bara behöver byggas upp, problem som kräver omfattande ny forskning för att överhuvudtaget kunna utformas, och problem vars lösning är beroende av tekniskt arbete som inte kan prototypiseras övertygande på en dag.

Praxis har avvikit avsevärt från det ursprungliga femdagarsformatet, där fyradagars- och distansvarianter nu är vanliga, och kortare versioner används för snävare frågor. Anpassningarna är rimliga, förutsatt att de väsentliga elementen består: ett tydligt problem, rätt deltagare inklusive någon som kan besluta, individuell idégenerering före gruppdiskussion, en riktig prototyp och testning med faktiska användare snarare än med kollegor. Sprintar som slopar användartestningen behåller workshopen och förlorar poängen.

Deltagarurvalet är mer betydelsefullt än schemat och hanteras ofta slarvigt. En sprint med fel personer ger en väl faciliterad vecka som inte förändrar någonting: utan någon som kan bestämma blir resultatet en rekommendation som hamnar i den vanliga godkännandekön; utan ingenjörsrepresentation testar prototypen en riktning som visar sig vara ogenomförbar; utan någon som har kundbevis designar gruppen utifrån antaganden. Fem till sju personer som täcker beslutsbehörighet, design, teknik och kundkännedom är arbetsgruppen, och att säkra deras genuina tillgänglighet under hela perioden, snarare än delvis närvaro mellan andra åtaganden, är vanligtvis den svåraste delen av att arrangera en sprint.

Den vanligaste besvikelsen är att behandla sprinten som en leverans snarare än som början på arbetet. Resultatet är en validerad eller ogiltigförklarad riktning och en uppsättning observationer, inte en färdig design, och värdet realiseras endast om resultatet matas in i efterföljande utveckling. I praktiken innebär detta att köra sprintar inom en kontinuerlig process snarare än som isolerade händelser, där resultatet förs vidare till produktdesign och leveransarbete i en produktstudio engagemang, och med testningen som utförs enligt standarderna för användarundersökning snarare än som en informell visa-och-berätta.