Wat is een goed (en slecht) vraagstuk voor een design sprint?

Een design sprint maakt design thinking praktisch, tastbaar, behapbaar en toegankelijk. De methode geeft je een duidelijke to-dolijst en een overzicht van hoe je in 5 dagen een vraagstuk kunt oplossen en toetsen. Hoe bepaal je het juiste vraagstuk? Dat leg ik uit in dit artikel.

Bij een design sprint is duidelijk wat je gaat doen, wat je krijgt, welke rollen en welk commitment nodig is. When done right kun je:

• tot nieuwe inzichten komen
• een genuanceerder beeld van de klant en het probleem krijgen
• goed geformuleerd krijgen wat het nou precies is dat je gaat oplossen
• en buiten de lijntjes mogen tekenen wat betreft oplossingsrichtingen.

En je krijgt ook nog eens first-hand reacties van je klanten op de laatste dag van de design sprint! Het is een briljante tool in de innovatietoolbox. Maar net als met echte tools werkt het goed voor specifieke taken, en slecht voor andere. Om het meeste uit design sprints te halen, moet je het wel een passend vraagstuk gebruiken.

1. Begin met het probleem, niet met de oplossing

Een goede vraag voor een design sprint gaat over het probleem, de vraag achter de vraag. Een minder goede vraag gaat over de oplossing. Dit is in mijn ervaring de meest vaak voorkomende fout bij het bedenken van de vraagstelling.

Deze vraagstukken zijn redelijk sturend, en gericht op een oplossing:

• We willen een app die mensen begeleidt bij het maken van gezonde voedingskeuzes
• Hoe kunnen we de wachtkamer een kalmerende uitstraling geven?
• Waar kunnen we conversational interface toepassen in onze dienstverlening?

Dit soort ‘vraagstukken’ worden bewust of onbewust gebruikt om een oplossing die de opdrachtgever al heeft bedacht te verantwoorden of te detailleren. Deze denkfout komt vaker voor dan alleen bij design sprints. Veel van de vragen die UX-designers krijgen zijn ook vaak al een (suggestie van een) oplossing.

De kunst is de vraag achter de vraag te achterhalen. In de ‘target’-fase van de eerste sprintdag ga je nog aan de slag met het aanscherpen van de sprintvraag. Maar zorg er wel voor dat er genoeg ruimte in de vraagstelling zit voor meerdere mogelijke antwoorden.

Deze vragen zijn minder sturend en wijzen naar het probleem:

• Hoe kunnen we de burgers van onze gemeente stimuleren om gezonder te eten?
• Hoe kunnen we de ervaring van het rijexamen minder stressvol maken?
• Hoe kunnen we het aantal klantenservice-telefoontjes over de aflevering van het pakket verminderen?

Zorg dat het management zich inzet

Het stellen van dit soort vragen betekent ook dat het management ervoor openstaat om met een design sprint te starten zonder te weten welke oplossing eruit komt. En ze moeten zich inzetten om deze oplossing daadwerkelijk een kans te geven. Als de opdrachtgever al een specifieke oplossing voor ogen heeft – hopelijk is die ook goed onderbouwd – dan is een design sprint niet van toegevoegde waarde.

Je kunt dan beter een ander soort workshop samenstellen om die specifieke vraag te beantwoorden. Sterker nog, het erdoorheen pushen van een design sprint kan in dit geval zelfs het vertrouwen van de opdrachtgever ondermijnen, omdat de sprintactiviteiten niet gaan helpen om de gestelde vraag te beantwoorden.

Een goede vraag zit in de ‘Goldilocks zone’: niet te breed, niet te specifiek, maar precies goed.

2. Zorg voor het juiste abstractieniveau

Het wisselgeld van een design sprint zijn conceptuele ideeën. Dat leent zich voor om gebruikt te worden aan de ‘voorkant’ van het productdesign-proces, bij het bepalen van de strategie, bedenken van nieuwe features en zoeken naar nieuwe oplossingen voor bestaande problemen.

Een goede vraag zit in de ‘Goldilocks zone’: niet te breed, niet te specifiek, maar precies goed.

• Iets te breed: hoe kunnen we de wachttijden verminderen in ons ziekenhuis?
• Iets de specifiek: de timeline op de pagina over behandeling X geeft niet duidelijk aan hoe het verloopt. Hoe kunnen we de timeline-weergave verbeteren zodat het wel duidelijk is?
• Ergens in het midden: het verloop van behandeling X is onduidelijk voor onze patiënten. Hoe kunnen we de nieuwe patiënten geruststellen en inzichtelijk maken wat ze te wachten staat?

Voor al deze vragen valt iets te zeggen. De wachttijden verminderen binnen een afdeling kan wel een goede vraag zijn als je goed inzichtelijk hebt wat de wachttijden allemaal beïnvloedt. Timeline-weergave kan op zich ook een goede sprintvraag zijn, als het over een hele sectie gaat die jouw behandeltraject inzichtelijk maakt, en niet over een componentje op de pagina. Toch zie je een gradatie in abstractieniveaus in deze drie voorbeelden.

Te breed

Als je de scope van je sprintvraag te breed maakt, verzuip je in de details van het vraagstuk en blijf je maar puzzelen. Het wordt een zogenaamd ‘wicked problem’, een probleem met te veel factoren en afhankelijkheden. Daarnaast kun je niet makkelijk de gevolgen van je oplossing of interventie in een wicked problem (over)zien en in een dag toetsen, terwijl de design sprint daar juist om vraagt.

Jake Knapp (auteur van het boek Sprint: How to solve big problems and test new ideas in just five days) zegt: ‘No problem is too large for a sprint’. De nuance hierbij is dat sommige vragen te veel variabelen hebben die niet binnen een sprint te overzien zijn, en die je niet snel aan een team kan uitleggen.

Dat betekent niet dat het niet mogelijk of nodig is om daarmee te om te gaan. Er bestaan genoeg andere methodes en modellen in het Systems Thinking ‘playbook’ om ingewikkelde vragen te onderzoeken. Maar een design sprint als methode niet geschikt voor dit soort vragen. Het besteedt namelijk te weinig tijd aan het creëren van een gedeeld beeld van de werkelijkheid, en om dat goed te modelleren en in kaart te brengen.

Te specifiek

Een te kleine scope zorgt ervoor dat het team steeds dezelfde argumenten ter tafel brengt. En de ideeën blijven voornamelijk op het niveau zitten van ‘welke tekst/kleur/volgorde moet dit zijn’? Zo maak je geen gebruik van de multidisciplinaire inzichten van het team. De groep werkt dan gezamenlijk aan het verbeteren van een schermpje in plaats van een oplossing te bedenken voor het klantprobleem.

Voor dit soort vragen is het efficiënter als een UX-designer, digitale designer en een developer een paar uurtjes samen brainstormen en een oplossing uitwerken.

Ergens in het midden

De juiste scope heeft een goed ‘abstractieniveau’. Kijk naar het probleem dat je wil oplossen. Bijvoorbeeld: ‘Onze patiënten geven aan dat de procedure van de behandeling onduidelijk is’. Neem dan precies een stap terug en kijk naar de context waarin dit probleem ontstaat.

Als een stoel oncomfortabel is, kijk je ook naar de kamer waarin die zich bevindt, maar niet naar het hele gebouw, of alleen de rugleuning. Als het verloop van de behandeling onduidelijk is, kijk je in de design sprint naar de punten in de customer journey waar de klant inzicht nodig heeft in hoe het verloopt. Maar niet naar de werkwijze van het ziekenhuis of de opzet van een specifieke pagina. De uitkomst van de sprint kan alsnog zijn dat de werkwijze van het ziekenhuis veranderd moet worden, maar dat is geen goede sprintvraag om mee te starten.

De goede scope van de sprintvraag kijkt dus iets breder dan het probleem zelf, en staat verschillende oplossingsrichtingen toe.

3. Focus op het probleem van de gebruikers, niet van de business

De formulering van het vraagstuk moet een probleem van de gebruiker bevatten. Het moet geen probleem van de business zijn.

• Probleem van de business: we ervaren te weinig groei in nieuwe aanmeldingen in de laatste maanden. Hoe kunnen we meer klanten aantrekken?
• Probleem van de gebruikers: het is bekend dat in de huidige economische situatie jonge mensen beter moeten nadenken over hun financiële toekomst, maar dat gebeurt nu niet genoeg. Hoe kunnen we onze financiële planner relevanter en aantrekkelijker maken voor de doelgroep van 20- tot 30-jarigen?

Waarom moet het geen probleem van de business zijn? Business-problemen gaan uit van een KPI of een prestatie van een specifieke afdeling of een product. En daar wil het management natuurlijk iets aan doen.

Uitgaand van een KPI-vraagstelling ben je 5 dagen lang met het team aan het gokken (‘Waarom zou de conversieratio gedaald kunnen zijn?’), en oplossingen voor verschillende ‘misschien-oorzaken’ aan het bedenken.

Er zit altijd iets achter de cijfers, de reden waarom ze zo goed of slecht zijn. Meestal ligt het aan het gedrag of de opinie van de klanten. Juist die punten moeten de kern van de sprintvraag zijn, en niet de cijfers.

Dit betekent trouwens niet dat je niets kan doen met een business-probleem. Erachter komen wat de achterliggende reden van een probleem is, vereist wat vooronderzoek. Ga op zoek naar informatie – vraag de analytics-logs op, bekijk de statistieken, spreek de gebruikers en ga vissen naar inzichten bij de klantenservice. Zo kun je het business-probleem herformuleren naar een probleem van de klant.

Wat betekent dit allemaal?

De design sprint is een geweldige methode, maar het is niet voor alle vraagstukken goed toe te passen. Het is gewoon oké om een andere soort sessie of een workshop te organiseren als een design sprint niet werkt voor jouw vraag of doel.

Voor een succesvolle design sprint is een goede vraagstelling belangrijk. Die is moeilijk te formuleren, maar het is de moeite waard. Deze methode is namelijk beter geschikt voor de wat meer ‘hoog over’-vragen dan de ‘scherm uitwerken’-vragen, en staat meerdere oplossingsrichtingen toe. Een goede vraag gaat uit van een probleem van de klant, en suggereert niet een specifieke oplossing.

Houd hier rekening mee als je een design sprint aan het plannen bent, deze overwegingen maken jouw sprint veel impactvoller. Happy sprinting!