Wat is een goed (en slecht) vraagstuk voor een Design Sprint?

Deze blog is oorspronkelijk gepubliceerd op Frankwatching.nl

Design thinking is simple, but it isn’t easy. Een Design Sprint maakt design thinking praktisch, tastbaar, behapbaar en toegankelijk. Het geeft je een duidelijke to-do lijst en een overzicht van hoe je in 5 dagen een design vraagstuk kan oplossen en toetsen. Het is duidelijk wat je gaat doen, wat je krijgt, welke rollen en welk commitment nodig is. When done right (wel 5 dagen, en niet ‘een paar’; met degelijk vooronderzoek en een passende vraag) kan 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!

Design Sprint 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 de Design Sprint te halen, moet je het wel voor een passend vraagstuk gebruiken.

1. Begin met het probleem en niet met de oplossing

Een goede Design Sprint vraag gaat over het probleem, de vraag achter de vraag. Een minder goede gaat over de oplossing. Dit is in mijn ervaring de meest vaak voorkomende fout bij het bedenken van de sprint 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 examen 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 eigenlijk al een (suggestie van een) oplossing. De kunst is de vraag achter de vraag te achterhalen. Dat moet ook gebeuren voor een Design Sprint vraag. In de ‘target’ fase van de eerste dag 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?

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 zich inzet om deze oplossing daadwerkelijk een kans te geven. Als de opdrachtgever al een specifieke oplossing voor ogen heeft -hopelijk is die ook goed onderbouwd- is Design Sprint niet van toegevoegde waarde. Je kan dan beter een andere 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 sprint activiteiten niet gaan helpen om de gestelde vraag te beantwoorden.

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 product design proces, bij het bepalen van de strategie, bedenken van nieuwe features, zoeken naar nieuwe oplossingen voor bestaande problemen.

Een goede vraag zit in de ‘Goldilocks zone’: niet te breed, niet te specifiek, maar juist 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: De verloop van de behandeling X is onduidelijk voor onze patiënten. Hoe kunnen we de nieuwe patiënten geruststellen en het inzichtelijk voor hen 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 abstractieniveau’s 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 kan 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 dealen. Er bestaan genoeg andere methodes en modellen in het Systems Thinking ‘playbook’ om ingewikkelde vragen te exploreren. Een Design Sprint is echter niet de methode die geschikt is voor dit soort vragen. Een Design Sprint besteedt te weinig tijd aan het creëren van een gedeeld beeld van de werkelijkheid en 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 dat ideeën 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’. Kijkend naar het probleem dat je wilt oplossen (bijvoorbeeld ‘Onze patiënten geven aan dat de procedure van de behandeling onduidelijk is’) neem je precies een stap terug en kijk je ook 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 way of working van het ziekenhuis of de opzet van een specifieke pagina. De uitkomst van de sprint kan alsnog zijn dat de way of working 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 on the problem of the users, not one of the 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-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 conversie rate 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 niet dat je niets kan doen met een business probleem.

Er achterkomen wat de achterliggende reden van een probleem is, eist 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 okay 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. Een Design Sprint 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!

Over de auteur

Daryna Kruty is UX designer bij creative & digital agency One Shoe. Ze onderzoekt wat mensen beweegt en hoe hun motivaties zich naar gedrag vertalen. Die inzichten past ze toe in het ontwerp van succesvolle digitale producten. In haar dagelijks werk schakelt ze vaak tussen strategische en tactische aspecten van User Experience, en zorgt ze dat de abstracte high-level visies handen en voeten krijgen in haar designs. Ze krijgt energie uit projecten met inhoudelijke en functionele complexiteit, en houdt van een goede uitdaging waarin de business doelen en de behoeften van de eindgebruikers bij elkaar moeten komen. Daryna heeft voor verschillende klanten zoals Rabobank, KLM, Thuisarts en Studiekeuze123 gewerkt.