Développé par Google Venture, le Design Sprint est l’une des toutes dernières méthodologies agiles de gestion de projet. Contrairement à ses consœurs, le Scrum, le Design Thinking ou bien encore le Lean Startup, elle vise à résoudre une problématique utilisateur en testant une solution-prototype en 5 jours. Cela veut dire que pendant ce laps de temps très court, vous devrez mobiliser les compétences adéquates. Rassurez-vous, ce n’est pas dogmatique pour autant 😉 En revanche, sur ce schéma, elle présente l’avantage d’être totalement immersive. Allez, je n’en dis pas plus ! Il est temps de plonger dedans. Voyons, premièrement, comment ce qu’est le Design Sprint. Puis, nous verrons comment cela fonctionne. Enfin nous regarderons les périmètres de projet auxquels il peut s’appliquer.
Design Sprint : un mix condensé de Design Thinking, de Lean Startup et de Scrum.
Les méthodologies agiles de gestion de projet sont aujourd’hui de plus en plus utilisées dans les entreprises. Avec l’apparition de nouveaux usages centrés sur l’immédiateté, l’ultra-connectivité et la multiplication des plateformes internet, les gestionnaires/managers de projets se sont tournés vers des cycles de gestion plus courts et plus réactifs. Le design-thinking, le lean-startup et le scrum figurent parmi les méthodologies agiles les plus connues et utilisées en entreprise. Dernière née du mouvement, le design sprint est un mix des 3. La différence principale réside dans le nombre réduit de cycles (itérations) en un temps minimal alloué.
En effet, l’objectif est de valider auprès d’utilisateurs une idée en 5 jours avant de se lancer dans le développement. Ces signifie que chaque jour une étape sera réalisée. Il y a donc 5 étapes que l’on peut résumer par ce croquis ci-dessous.
Fonctionnement du Design Sprint
Le concept consiste à rassembler sur une semaine une ou des équipes pluridisciplinaires. On prendra ainsi des salariés de tout bord comme des experts métier, des ingénieurs IT, des designers et si possible un décisionnaire (pour valider in fine le développement du projet). Les missions de cette équipe seront les suivantes:
– Jour 1 : Comprendre le problème à résoudre
présentation de l’existant, tour de la concurrence, personas, parcours utilisateur, définition des KPIs, échange de savoir, données en tout genre à analyser
– Jour 2 : Challenger les idées de solutions
dresser un mur d’idées, réaliser des maquettages, écrire des storybaording, faire des présentations individuelles des storyboards
– Jour 3 : Décider de la solution
confronter les solutions, tester les hypothèses, voter, dessiner le storyboard final qui servira de spécification / de brief
– Jour 4 : Prototyper la solution
dessiner les mockups, les rendre les plus réalistes possible (i.e texte réel) sans tomber dans le perfectionnisme pour autant, demander à une personne extérieure au projet son avis sur la solution afin d’éviter d’aller se perdre dans des réflexions inutiles
– Jour 5 : Tester le prototype en situation réelle
lister vos questions-clés avant le test, aller sur le terrain, interroger de vrais utilisateurs, s’assurer que tous les personnes de l’équipe soient présentes et prennent des notes lors de la démo, rassembler toutes les notes prises et les analyser, dresser les constats des analyses et les classer en « choses qui fonctionnent » et « problèmes à résoudre »
Quand peut-on l’utiliser ? Pour quel type de projets est-elle le mieux adaptée ?
Les retours d’expérience sont légion lorsque l’on parle de la méthodologie du Design Sprint. En revanche, il en existe peu quant aux périmètres des projets que l’on peut aborder via cette méthodologie. Je vais donc tenter de vous livrer le mien.
Lorsque j’ai utilisé la première fois la Design Sprint j’étais assez sceptique. Connaissant déjà le Lean-startup, le Design thinking et le Scrum, je m’interrogeais réellement sur la plus-value délivrée. Après avoir participé à deux projets, je suis convaincu de l’effet de levier que cela peut apporter. A condition de remplir au moins deux prérequis :
- Avoir des participants ouverts et motivés par le jeu et l’enjeu
- Être prêt à « jeter » le prototype si le test utilisateur n’est pas concluant
Voici une liste non-exhaustive de sujets qui se prêtent ou pas à la méthodologie DS.
Quand faire du Design Sprint?
- Vérifier une nouvelle fonctionnalité d’un produit/ d’un service
- Lancer un nouveau concept
- Optimiser un parcours utilisateur spécifique
- Pour résumer, tout projet avec un périmètre clair et restreint
Quand ne pas faire du Design Sprint?
- lancer une application complète
- Optimiser un parcours utilisateur complexe
- Pour résumer, tout projet avec un périmètre complexe et vaste
Enfin, en guise de conclusion, je vous propose cette vidéo de 90 secondes qui résume très bien le process de Design Sprint. N’hésitez pas à interagir suite à cette lecture.
Digitalement vôtre,
Sources :