Terug naar het origineel: de Google Design Sprint
Eerst even terug naar de basis. De Google Design Sprint is door Jake Knapp van Google Ventures bedacht om in 5 dagen de belangrijkste vragen van een nieuwe start-up, dienst of product te valideren. Bijvoorbeeld de vraag: willen hotelgasten überhaupt wel bediend worden door een robot? Of: hoe breng je het gevoel van een hippe koffiebar online? Essentiële vragen die je wilt beantwoorden vóórdat je veel tijd en geld steekt in het ontwikkelen van een robot of een online koffiebar. De Google Design Sprint helpt bij het vinden van de antwoorden, in 5 dagen:
Waar het kortweg op neerkomt: eerst bepaal je de belangrijkste vraag die je in de sprint wilt beantwoorden. Dan ga je daar zoveel mogelijk oplossingen voor verzinnen. De beste werk je vervolgens uit tot een prototype en leg je voor aan de (potentiële) eindgebruiker. Creatie én validatie dus.
De verbeterde Design Sprint 2.0
Appeltje eitje zou je zeggen. Maar al snel kwam de kritiek dat het erg lastig is om alle stakeholders voor 5 dagen vrij te krijgen. De sprint bleek nog effectiever te kunnen en zo ontstond Design Sprint 2.0: een design sprint in 4 dagen waarbij de stakeholders alleen op de cruciale momenten betrokken zijn. Handig voor agencies als de drukke CEO aan de klantzijde weinig tijd heeft. En dus gebruiken wij deze ook met onze design-zusjes Soda en Resoluut.
Mag het ietsje meer user-centered zijn?
Maar of de design sprint nu 4 of 5 dagen duurt, we merken dat gebruikers te weinig centraal staan. Ja, het concept wordt gevalideerd met eindgebruikers, maar waarom pas op de laatste dag? En ja, je kunt de stakeholders interviewen over hun kennis van de klant, maar waarom spreek je ze niet gewoon zelf? Eigenlijk ben je als team keihard aan het ontwerpen en prototypen op basis van aannames en tweedehands informatie. Dan is er een risico dat je op de laatste dag moet concluderen dat je een prachtige oplossing hebt ontworpen voor een probleem dat de gebruiker helemaal niet heeft. Zonde.
De oplossing: Design Research Sprint
Nog steeds effectief en leuk, maar nu met meer aandacht voor de gebruiker en zijn behoeftes: de Design Research Sprint. Dit is de bestaande Design Sprint 2.0, maar dan in 5 dagen. Zo is er ruimte om 2 dagdelen design-research-methodes toe te passen. Om je nog beter in het onderwerp te verdiepen en om de “pijn” van de gebruiker te voelen, vóórdat je je creativiteit loslaat op het bedenken van de beste oplossingen.
Hoe dat er dan uitziet? Nou, bijvoorbeeld zo:
De design sprint blijft hetzelfde, behalve op de maandagmiddag en dinsdagochtend.
Maandag: vind de gebruiksbehoeftes en bepaal de sprint focus
De eerste dag begint zoals altijd: in het probleem duiken en de sprintvraag opstellen. Maar door in de middag zogenoemde generative-research-methodes toe te passen, is er veel meer zekerheid of je de juiste gebruikersbehoefte te pakken hebt. Denk bijvoorbeeld eens aan 5 user interviews van een half uur. Of 2,5 uur de straat opgaan en potentiële gebruikers observeren en/of om hun mening vragen. Wil je bijvoorbeeld meer weten over het gebruik van korting-apps? Ga de winkelstraat in en vraag het de Kruidvat-klanten die net de winkel uitkomen. De gevonden gebruikersbehoeften vertaal je naar “How Might We”-vragen en die leg je naast je sprintvraag en journey map van de ochtend. Nu pas maak je je focus voor de sprint definitief.
Dinsdag: doe inspiratie op van je gebruiker en schets oplossingen
Op de dinsdag duik je dieper in op de uitdaging en ga je oplossingen schetsen. Maar dan net een beetje anders dan een normale design sprint. In de ochtend is het doel om een goed begrip te krijgen van de context waar je een oplossing voor bedenkt – explanatory onderzoek noemen we dat. Zoom verder in op het probleem, de mensen en de gedragingen. Wat is de gebruiker gewend? Hoe lost de gebruiker nu dit probleem op?
Is er al een app? Dan duik je bijvoorbeeld in de gebruiksdata om het gedrag van de gebruiker te doorgronden. Ontwerp je iets nieuws, bijvoorbeeld voor een zeer specifieke, kritische doelgroep (denk aan medisch specialisten), dan organiseer je een co-creatiesessie. Zo zie je wat voor afweging de eindgebruiker zélf maakt en kan je ook hun oplossingen meenemen in het ontwerpproces. Allemaal waardevolle input voor de middag: tijd om te schetsen.
De rest van het proces is hetzelfde als de Google Design Sprint: op woensdag kies je de beste oplossing en maak je een storyboard. Donderdag is prototype-dag en op vrijdag test je het prototype op de eindgebruiker.
Conclusie
Door in het begin van de sprint iets meer tijd te nemen voor de behoeftes van de gebruiker, voorkom je dat je een week aan de verkeerde vraag werkt, ga je beter de creatieve fase in én haal je meer concrete verbeterpunten uit de usertest op de laatste dag. Een no-brainer dus, als je het ons vraagt.
