In het eerste deel van dit artikel, gewijd aan de Design Sprint, heb ik de balans opgemaakt van zijn oorsprong, zijn bestaansredenen en zijn ontwikkeling, zowel theoretisch als praktisch. De implementatie ervan bij verschillende gelegenheden heeft me ook andere lessen opgeleverd, die je meestal niet leest in de (korte) artikelen die aan deze methode zijn gewijd, nog lang niet te veel gebruikt.

Wat is het niet...

Het is duidelijk dat deze benadering zijn risico's heeft, omdat hij verkeerd kan worden begrepen of zelfs verkeerd kan worden toegepast. Enerzijds kan er inderdaad een misverstand ontstaan ​​en een aanzienlijke kloof ontstaan ​​tussen de roeping van de sprint (zie deel 1 van het artikel) en klantverwachtingen. Aan de andere kant zal de sprint des te beter verlopen als de persoon die hem faciliteert goede ervaring heeft met het leiden van workshops in het algemeen en dit soort oefeningen in het bijzonder. Het is inderdaad nodig om zowel een zekere afstand te hebben om de overvloed aan energie in de kamer op te vangen en om het hoofd voor iedereen koel te houden, maar ook de stevigheid (altijd welwillend) om in te kaderen en opnieuw in te kaderen wanneer het nodig is .
In alle gevallen :

• Le design sprint is alles behalve een magische oplossing voor al je problemen... maar, zoals we hebben gezien, eerder een collectieve, actieve synergie, gericht op de ontwikkeling van een hypothetische oplossing voor een bepaald probleem, de beroemde MVP. Het zal dus geen kwestie zijn van het testen en valideren van alle functionele opties of de mogelijke paden om tot een globale oplossing te komen. Typisch is de design sprint niet geïndiceerd voor een herontwerp van een site of een business tool als geheel. Omgekeerd kan het handig zijn voor het ontwerpen van een "single-task"-app, het aanpakken van een bepaald reisprobleem, het testen of ontwerpen van een functie... Per definitie zal onze oplossing het doel en een van de problemen aanpakken die aan het begin van de sprinten, niets anders.
• Bij uitbreiding zal het nog minder de mogelijkheid zijn om de strategie of het imago van een organisatie / bedrijf te herzien in de hoop alles in 5 dagen te herzien.
• De sprint is geen doel op zich. Met andere woorden, als het het mogelijk maakt om een ​​oplossing te testen, zal deze zelden volwassen genoeg of compleet genoeg zijn om direct geïmplementeerd te worden. Het zal zeker aanpassingen, verbeteringen, zelfs meer tests vergen, kortom iteraties voordat het in productie gaat, met zijn eigen kant-en-klare bestanden stroomopwaarts (wat het sprintprototype niet hoort te zijn).
• Het is ook geen hackathon. waar we meerdere oplossingen tegelijk zullen bekijken. Zoals we hebben laten zien, is het nodig om in het midden van de cursus te convergeren naar een oplossing (of het nu een cursus of een scherm is). Dit is geen AB(CDEF...)-test. De sprint moet zijn eigen waardepropositie dragen.

Kortom, het verwar Design Sprint niet met sprint, oftewel snelheid en haast. De sprint kan niet alle problemen oplossen tegelijkertijd, misbruikt of door het niet respecteren van zijn formaat, zijn stadia en zijn doel, kan het contraproductief of zelfs destructief blijken te zijn omdat het uitputtend en bedrieglijk is.
 

Sprint uit het boek

Als de sprint ideaal is om “out of the box te denken” (denk out of the box), dan is dat ook zo soms nodig om het boek weg te leggen en niet al zijn voorschriften naar de letter volgen, met het risico geblokkeerd te blijven, hetzij voor een onoplosbaar probleem of in een bepaalde situatie op een bepaald moment.
De persoon die de sprint leidt, moet gebruik gezond verstand en meer of minder flexibiliteit, pragmatisme in ieder geval, om er een einde aan te maken, zo niet zijn doel. Als ze garant staat voor tijd en opeenvolgende stadia, zal ze haar spel vaak moeten aanpassen omdat ze met andere mensen wordt geconfronteerd. Welwillendheid moet soms prevaleren boven de “time timer” en het komt voor dat we de toegewezen tijd overlopen. Het zal ook nodig zijn om te weten hoe de vatbaarheid of verlegenheid van sommigen te beheersen, om anderen te temperen. Maar ook aanpassen aan de beperkingen van de deelnemers (kamer uitgangen voor een belangrijk telefoongesprek, vroegtijdige verdwijning/terugkomst, wanneer op het terrein van de klant). De geduld van de begeleider wordt daarom vaak op de proef gesteld. Vandaar het concept vanervaring, meer om het nodige perspectief en bevestiging te kunnen hebben, dan om de methode rigoureus uit het hoofd te kunnen uitrollen zoals we dat in het verleden hebben gedaan. Het zal dus nodig zijn om een ​​zeker evenwicht te vinden tussen al deze gegevens, want het belangrijkste is dat de klant tevreden is, en dat we een oplossing 'sorteren', zonder dat het iemands leven kost.

In feite we kunnen heel goed een sprint voor twee animeren. Inderdaad, zoals bij een koppel de een de zorg voor het kind overneemt omdat de ander even uitgeput is, kan het in een sprintsituatie behoorlijk belangrijk zijn om op een alter ego te kunnen vertrouwen. vol energie deelnemers. Of om zeker te zijn van een keuze of een oriëntatie.
Ik realiseerde me ook dat alle stappen niet blokkeren als ze niet worden uitgevoerd. Bijvoorbeeld direct naar schetsen gaan die een beetje geavanceerd zijn zonder door de Crazy8 te gaan, wat een nogal destabiliserende oefening is (en het moet gezegd worden dat het meer geschikt is voor ontwerpers), is heel goed mogelijk, vooral als je in de vorige stap achterop bent geraakt. Want ja, soms moet je in de loop van de tijd met een beetje elasticiteit omgaan en vergeet de "timer" als een stap niet voldoende gevorderd wordt geacht. Het belangrijkste is om donderdag het prototype af te hebben en vrijdag de tests te hebben georganiseerd, want het maakt niet uit of alles niet perfect is, het belangrijkste is om de maximale gebruikersfeedback te verzamelen (feedback).
Nog een oefening die mij niet altijd overtuigt: de zogenaamde notitietechniek "Hoe zouden wij" (We schrijven HMW linksboven op de post-its, en we schrijven in de vorm van vragen of kansen de problemen die tijdens de maandaginterviews met de experts naar voren zijn gekomen). Ten eerste wordt de instructie niet altijd goed begrepen en kan het resultaat eruitzien als een verzameling trefwoorden of lange opmerkingen. Dan komt het eerder overeen met een Angelsaksische mentaliteit. Inderdaad, de Fransen, die meestal kritisch en cartesiaans zijn, hebben misschien meer moeite om zich te projecteren op een interpretatie en een relatief open en positief perspectief. Trouwens, we konden verander "How Might We" in "How To Fail", een alternatieve oefening die bestaat uit het identificeren van de redenen waarom het project zou kunnen mislukken om de oplossingen te vinden die het succes ervan garanderen.
We kunnen ons ook heel goed voorstellen om andere workshops te integreren, die geschikter zijn en die de sprint kunnen dienen, zolang we het sequentiële aspect behouden dat essentieel is voor het goede verloop ervan (bijv. een of twee 6to1 - lees ons artikel – tijdens de schetsdag).
Je kunt ook bepaalde fasen vooruit- of overslaan. Als de sprint bijvoorbeeld goed vordert en als iedereen dezelfde visie deelt, is het niet verplicht om door te gaan met alle inter-workshop stemmen, dan kan een stemming aan het eind van de dag voldoende zijn. Evenzo wil de beslisser niet altijd zijn supervote gebruiken, waarom zou hij hem daartoe dwingen?
Kortom, nogmaals weten hoe je uit de nagels kunt komen is niet verboden, zelfs als we ons voorstellen dat J. Knapp misschien al alles heeft geprobeerd, is het belangrijk om door te gaan met experimenteren terwijl je probeert de klant en zijn project tevreden te stellen, waarbij je de sprint als een raamwerk neemt en niet als een tabel met opdrachten en gedeeltelijk inclusief, van tijd tot tijd tot tijd, typische UX-methoden.
 

De Design sprint binnen de UX Republic aanpak

Zoals we hierboven al zeiden, is de design sprint alleen niet genoeg. Vanaf het begin lijkt het ons absoluut noodzakelijk om het te "bewaken" en om op zijn minst een fase van te plannenstroomopwaartse onderdompeling (zie ons aanbod), als de opdrachtgever solide elementen heeft om de sprint te voeden, of indien nodig zelfs een onderzoeks- en/of auditfase in te plannen. Het is niet comfortabel en ook niet erg effectief om een ​​sprint van nul te beginnen, zonder een minimum aan informatie over hem, zijn sector, zijn concurrenten en vooral het begrip van zijn beroep en voor wat ons in de eerste plaats, zijn gebruikers betreft. 
Dan, aan het einde, zal de sprint zeker nog steeds nodig zijn een paar iteraties om de oplossing te verbeteren zodat deze zo goed mogelijk aansluit bij de behoeften van de gebruiker, zijn markt, zijn omgeving. Het kan ook de basis vormen voor toekomstig aanvullend werk. Het is bovendien een beetje zijn latente roeping, aangezien het gericht is op innovatie: de . zijn startpunt van de volgende toekomst van de sponsororganisatie. Wij adviseren dan ook een vervolg op de sprint om het concept af te kunnen ronden en goed in productie te kunnen nemen, en waarom niet op termijn de samenwerking aan te gaan met het oog oponze klant ondersteunen bij zijn transformatie.

Alexis CANGY | UX/UI-consultant | Ontwerp Sprint Master