Op deze pagina beantwoorden we de belangrijkste vragen in aanloop naar de design sprint. We gaan daarbij in op de voorbereiding van het vraagstuk en het team en stellen een belangrijke vraag vooraf: wanneer is een design sprint waardevol? Want het is weliswaar breed inzetbaar, maar niet in alle gevallen nodig of de beste manier.
Programma
Dag 1: Vraagstuk scherp krijgen en oplossingsrichtingen bedenken
Dag 2: Oplosssingsrichting kiezen en storyboard maken
Dag 3: Prototype ontwikkelen en gebruikerstest ontwerpen
Dag 4: Prototype testen en vervolg bepalen
Direct naar het antwoord op je vraag:
- Voor wie is dit programma?
- Meer weten over de design sprint & de voorbereiding?
- Wanneer is een design sprint waardevol?
- Wat is een voorbeeld van een goed vraagstuk voor een design sprint?
- Wat is een voorbeeld van een vraagstuk dat minder geschikt is voor een design sprint?
- Hoe formuleer ik een design sprint vraagstuk?
- Wat is een goed team voor een design sprint?
Voor wie is dit programma?
Dit programma is voor professionals in de publieke sector die praktisch aan de slag willen met een manier om de gebruiker meer centraal te zetten. Niet alleen bij dienstverlening voor inwoners, maar ook voor collega’s en samenwerkingspartners.
Het programma is zowel gemaakt voor mensen en teams die willen kennismaken met de elementen van design thinking als voor teams die willen werken aan de implementatie en integratie van de elementen in hun manier van werken. Omdat design thinking niet alleen geschikt is voor producten en diensten, maar ook kan worden ingezet voor o.a. strategievraagstukken, communicatie, en beleid is het bij uitstek geschikt voor teams die in die domeinen werkzaam zijn.
Meer weten over de design sprint & de voorbereiding?
De design sprint is in 2010 ontstaan bij Google Ventures als een aanpak met onderdelen uit onder andere design thinking, lean en de manier waarop Google in de jaren daarvoor productontwikkeling vormgaf. Het proces van een design sprint is gericht op het ondersteunen van teams bij het helder en scherp formuleren van doelen, het verkennen van oplossingsrichtingen en de keuzes die daarbij gemaakt moeten worden. Het eindigt met een gebruikerstest waarbij een prototype van de dienst aan gebruikers wordt voorgelegd. Er zijn in de loop der jaren veel manieren gevonden om het te omschrijven. Dit zijn de definities van Google zelf.
Wanneer is een design sprint waardevol?
Het format van de design sprint helpt je om te focussen op een specifiek vraagstuk. De eerste fase wordt gebruikt om het vraagstuk van de gebruiker te verkennen, begrijpen en scherp te definiëren. En omdat de tijd beperkt is, is het belangrijk om vooraf met je team voldoende informatie over de gebruikers en het vraagstuk te verzamelen om dat goed te kunnen doen. Die voorbereiding helpt je ook om de vragen hieronder goed te kunnen beantwoorden.
Vraag 1. Wat is de impact als het niet lukt?
Bij minimale impact is het zonde om 4 dagen te besteden aan iets wat ook getest of bedacht kan worden binnen je team. Als de impact potentieel groot is (tijdsinvestering, financiële investering, afhankelijkheden) dan is het een ideale manier om in korte tijd grote stappen vooruit te zetten.
Vraag 2. Heb je al een idee of oplossing?
In beide gevallen kan een design sprint helpen. Lees hieronder welke vervolgvragen je kan stellen om beter te bepalen of het een goede match is.
Wanneer je al een idee hebt: weet je al of gebruikers erop zitten te wachten? Als je weet hoe het moet werken en hoe je het moet maken, dan is een design sprint overbodig. Als je nog geen beeld hebt bij de behoefte, dan krijg je met een design sprint snelle antwoorden waardoor je geen onnodige dingen hoeft te maken.
Vraag 3. Hoe zeker ben je van het idee of de oplossing?
Als je onzeker bent over de (mogelijke) oplossing dan is een design sprint een goede manier om de mogelijkheden te verkennen en snel te testen. Ben je wel zeker? Dan is de kans klein dat je tijdens de design sprint nieuwe en waardevolle inzichten opdoet.
Vraag 4. Heb je nog geen idee of oplossing?
Dan is de eerste vraag: hoe bekend ben je met de mogelijkheden voor de oplossing? Ben je een expert op de inhoud en je hebt een beeld bij de mogelijkheden, dan is een design sprint minder waardevol. Het is dan niet de moeite waard om met een team 4 dagen lang na te denken en kun je beter snel iets maken en testen.
Heb je niet genoeg kennis van de mogelijkheden en de gebruikersbehoefte, dan is een design sprint een sterke manier om nieuwe diensten te ontwerpen en testen.
Vraag 5. Wat is de complexiteit van het vraagstuk?
Voor een “simpel” vraagstuk voelt een design sprint waarschijnlijk te zwaar. Een design sprint werkt goed om complexiteit te ontleden en tot een heldere, gezamenlijke oplossing te komen.
Wat is een voorbeeld van een goed vraagstuk voor een Design Sprint?
De context van het vraagstuk:
Het sprint vraagstuk is:
Ontwerp een nieuwe manier van toegang voor de zorg & ondersteuning die wij leveren, die zorgt voor meer vertrouwen en waardering onder ouderen & gezinnen (die begin 2021 geïmplementeerd kan worden).
Waarom is dit een sterk vraagstuk?
- In potentie vraagt de oplossing om een serieuze (tijds-)investering omdat de toegang tot de zorg weleens anders georganiseerd kan worden.
- De oplossingen zijn talrijk en zonder een goed beeld van de behoefte en de mogelijkheden is de keuze niet goed te maken en te onderbouwen.
- Bestaat er een risico dat management hier een mening over heeft? Zeker, het gaat in potentie om een vraagstuk op zowel strategisch als uitvoerend vlak.
- Zou het waardevol zijn om meerdere perspectieven aan tafel te hebben? 100%. Voor een vraagstuk als deze, met potentiële impact op veel teams en afdelingen, is het cruciaal om alle standpunten en opties te horen, inclusief die van de inwoner.
Wat is een voorbeeld van een vraagstuk dat minder geschikt is voor een design sprint?
Dit is geen sterk vraagstuk voor een design sprint om de volgende redenen:
- Is er een serieuze (tijds-)investering nodig? Het zou wat tijd en geld kunnen kosten, maar het zorgt waarschijnlijk niet voor een fundamentele verandering van de oplossing.
- Bestaat er een risico dat management hier een mening over heeft? Waarschijnlijk niet. Omdat de oplossing naar verwachting geen andere aspecten van de bedrijfsvoering gaat raken is het onwaarschijnlijk dat hier van hogerhand tijd voor vrij wordt gemaakt,
- Zou het waardevol zijn om meerdere perspectieven aan tafel te hebben? Niet echt. Het zou goed zijn om in detail te horen waar mensen tegenaan lopen. Als ze die informatie hebben opgehaald kunnen ze met collega’s de benodigde aanpassingen doorvoeren. Daar zijn bestaande processen voor en hoeft het wiel niet opnieuw uitgevonden te worden.
Hoe formuleer ik een design sprint vraagstuk?
Kort, maar krachtig. Inspirerend en uitdagend. En op zo’n manier dat je team op één lijn zit, zodat je met focus kunt werken. Niet makkelijk en tegelijk heel belangrijk. Door de formulering hieronder te gebruiken hopen we je op weg te helpen.
-
1. Kies een actiegerichte term
Wat is de focus van jullie sprint? Een actiegerichte term werkt niet alleen inspirerend, maar ook hoe gericht de week gaat worden. Bepalen en maken zijn 2 hele andere woorden. Kies je actiegerichte woord zorgvuldig.
- “Maak…”
- “Ontwerp…”
- “Creëer…
- “Bepaal…”
- “Vindt…. uit…”
-
2. Bepaal een hoog-over vorm van output
Een eerste richting in het resultaat dat eruit zou kunnen komen. Niet de oplossing zelf, want die ken je nog niet. En onthoud: hoe meer ruimte je laat, des te meer ruimte je hebt voor vernieuwing en creativiteit
- “Een manier om…”
- “Een oplossing die…”
- “Een proces om…”
- “Een systeem dat.…”
- “Een dienst die…”
- “Een mechanisme waardoor…”
- “Een product om…”
-
3. Bepaal een succesindicator (welke verandering en wanneer?)
Welke verandering hoop je te realiseren met de sprint? Dit is belangrijk omdat dit het resultaat moet zijn van de oplossing die je wilt valideren. Het kan kwalitatief zijn (verbetering van de waardering van dienstverlening bijvoorbeeld) of kwantitatief: het verhoogt de waardering met minstens x. Hier kom je vaak tijdens de week ook wel achter, maar het is belangrijk om te bepalen wat succes is in zowel de voorbereiding als de uitvoering.
- “Lost x op…”
- “Verbeterd…”
- Maakt… mogelijk…”
- 4. Timing
Wanneer wil je dit effect zien? Het maakt duidelijk met welke beperkingen en voorwaarden je eventueel rekening moet houden. En als het over technologie gaat dan helpt het om bijvoorbeeld programmeurs goed mee te nemen in verwachtingen.
- “…Om te testen over 6 maanden”
- “…Geïmplementeerd in het eerste kwartaal van 2021”
-
5. Bepaal het profiel van je gebruiker
Deze is optioneel maar waardevol. Voor wie ga je aan het werk? Hier kom je sowieso nog op terug op de eerste dag van de sprint. Maar als je al specifiek weet wat het profiel is van je gebruiker, dan wordt het sprintvraagstuk er scherper van.
- “…voor nieuwe inwoners”
- “…voor mensen die de taal niet goed spreken:
- “…voor jonge gezinnen”
- “…voor collega’s van afdeling x”
En dat is het: een goed sprintvraagstuk in een paar stappen.
Als je de definitieve versie (voor aanvang van de sprint hebt), raden we je aan die groot te printen of op te schrijven. Op die manier kan je altijd terug naar de focus die wilt op momenten dat het wat uitwaait.
Onthoud ook dat je het vraagstuk altijd kunt aanpassen tijdens de sprint naarmate je meer inzichten opdoet en discussieert. Maar starten vanuit een goede basis helpt je op weg en verbindt het team bij aanvang.
Zonder een goede omschrijving kost het vaak veel tijd om op gang te komen en met een goede omschrijving weet je dat je op dag 1 goed van start kunt gaan.
Wat is een goed team voor een design sprint?
Een design sprint vraagt naast een goed vraagstuk ook om een sterk team. Daarbij is het belangrijk om verschillende perspectieven en disciplines aan tafel te hebben.
Een goed team (bestaande uit 6 mensen) is in de basis een team met veel verschillende disciplines. Die helpen je namelijk om vanuit diverse perspectieven naar zowel het vraagstuk als de potentiële oplossing te kijken. Iedereen kan op die manier vanuit zijn of haar rol waardevolle input leveren in de verschillende fasen.
Balans is daarbij het sleutelwoord. Teveel inhoudelijke expertise zorgt soms voor tunnelvisie denken in beperkingen terwijl te weinig kan leiden tot onhaalbare of onrealistische oplossingen. Zoek naar een mix van mensen die een bredere groep vertegenwoordigen. Denk daarbij bijvoorbeeld aan beleid, data, ICT, management & dienstverlening.
Een ruimte vol met mensen die ongeveer hetzelfde weten biedt niet genoeg diversiteit in manieren van denken en werken. Daarnaast is het belangrijk om iemand te hebben die knopen doorhakt als dat nodig is, een beslisser. Tijdens de week worden vrijwel alle keuzes op een democratische manier gemaakt, maar als dat op bepaalde punten niets oplevert is het aan de beslisser om te kiezen. Allemaal om ervoor te zorgen dat je door kunt.
Denk eraan om de mensen die achteraf met de uitkomsten gaan werken goed vertegenwoordigd zijn.
LET OP:
Leg het eigenaarschap van de uit te voeren acties en resultaten goed vast. Als dat niet zo is dan kan het goed zo zijn dat de resultaten niet verwerkt worden in een eventueel vervolg.
Rollen multidisciplinair team:
Denk bij multidisciplinair aan onderstaande rollen. Dit is geen definitieve lijst, maar een richting en een uitnodiging om een sterk en divers team te vormen.
- Een beslisser
dat kan iemand van de inhoud zijn, maar ook een manager of bestuurder (die dan ook in het team moet zitten) - Een beleidsmaker
- Een expert uit de uitvoering
- Een (data)-analist
- Een kwaliteitsmedewerker
- Een technische expert of ontwikkelaar
- Een producteigenaar
- Een onderzoeker
Vorm een echt team en bereid de week ook voor vanuit dat vertrekpunt.