Design sprint als methodiek: vragen en lessen uit de praktijk

Sinds Google Ventures een aantal jaren geleden de ‘design sprint’ als methodiek introduceerde, hebben een hoop bedrijven deze combinatie van ‘agile’, ‘lean’ en ‘design thinking’ overgenomen. Enkele belangrijke lessen uit de praktijk.

In een design sprint komen mensen met verschillende achtergronden samen om in hoog tempo nieuwe ideeën te ontwikkelen en te testen op echte gebruikers. Zo’n interdisciplinair team – bijvoorbeeld bestaande uit een product owner, marketeer, IT’er, designer en front-end developer – komt in vijf dagen tijd van uitdaging tot prototype en gebruikerstest. In plaats van eerst een MVP (Minimum Viable Product, minimaal product) te bouwen en dan pas na enkele maanden voor te leggen aan echte mensen, gebeurt dat nu binnen een week.

Dag 1: wat is de uitdaging?
Dag 2: verken de mogelijke oplossingen, genereer zoveel mogelijk ideeën
Dag 3: kies het beste idee en scherp dit aan
Dag 4: bouw een realistisch prototype
Dag 5: test onder echte gebruikers uit de doelgroep

De methode wordt toegepast op grote projecten, maar is net zo goed bruikbaar voor kleinere digitale ‘features’ of de bouw van een site. Zoals recent beschreven in ‘Efficiënt websites bouwen met design sprint’ kan de sprint in sommige situaties zelfs worden ingekort tot drie dagen.

Ideeën worden afgeschoten, de beperkte tijd zorgt wellicht voor extra druk: hoe inefficiënt dit wellicht ook voelt, juist omdat een design sprint in zo’n hoog tempo verloopt, is het belangrijk tijd en aandacht te besteden aan de communicatie in het team. InVision, een veelgebruikte app voor het maken van prototypes, deelt enkele belangrijke aandachtsgebieden.

Het succes van een design sprint staat of valt bij het gemeenschappelijke doel. Maak dit doel daarom concreet – bijvoorbeeld: het verbeteren van de conversie – en beschrijf de weg er naartoe. Ieder teamlid heeft zijn eigen achtergrond en denkt in zijn eigen uitdagingen. Het is goed dat iedereen zich dat bewust is. Een ontwikkelaar zal wellicht zijn zorgen uiten over de techniek, een marketeer over de promotie van een feature. Reserveer tijd om die onderliggende processen te benoemen. Vraag door en neem eventuele belemmeringen weg.

Het Italiaanse bureau Moze testte al User Story Mapping en Lean Service Design, maar koos uiteindelijk toch voor de design sprint. De beschreven ervaringen zijn gevat in enkele veelgestelde vragen.

Slechts vijf dagen?

Waarom zijn er slechts vijf dagen beschikbaar? Die vraag is vaak gesteld. Volgens de CTO is het precies genoeg om te verkennen en toch direct tot een eerste prototype te komen. In minder dagen krijg je onvoldoende begrip van het probleem dat je probeert op te lossen of om serieus te kijken naar andere opties. Trek je er meer dagen voor uit dan trap je mogelijk in de valkuil om te veel ideeën te mengen in één oplossing.

Overigens betekent dit niet dat teamleden niets anders meer kunnen doen. Bij dit bedrijf werkt men van tien uur ’s ochtends tot vijf uur in de avond in dit teamverband. De overige uren worden besteed aan urgente andere zaken. Zo houdt men het bedrijf draaiende. Enige valkuil is dat de focus hierdoor wellicht minder sterk is.

Eén dag om een prototype te maken?

Slechts één dag om een prototype te maken? Onbegonnen werk, zal menigeen denken. Het doel is echter niet om een goed functionerend prototype te bouwen, maar een ‘fake product’. Met tools als het eerder genoemde InVision zijn realistische layouts voor web en app te maken, inclusief animaties en interacties. In ieder geval ruim voldoende materiaal om echte gebruikers te tonen.

Waarom is testen nodig?

Wordt er niet getest dan bestaat het gevaar dat het team afgaat op de eigen aannames. Door te testen kun je als team nagaan of de specifiek gekozen oplossing daadwerkelijk een probleem oplost of vraag beantwoordt. Dit bureau leert met name veel van gebruikers als zij de vraag beantwoorden hoe zij het product zouden omschrijven aan een vriend. Het is verbazingwekkend om te zien hoe vaak mensen niet begrijpen wat een ontwikkelaar als vanzelfsprekend ziet. Tegelijkertijd schenken gebruikers geregeld minder aandacht aan dat wat een belangrijk detail leek.

Wat gebeurt er na die vijf dagen?

Blijkt uit de feedback dat het concept onvoldoende inspeelt op een vraag of probleem dan is een tweede ‘ronde’ een verstandige volgende stap. Met een – waarschijnlijk kleinere – design sprint is het concept aan te passen, het nieuwe prototype kan worden getest. Is het concept wel in orde dan is het tijd om de feedback te verwerken en het product te ontwikkelen.