Finis les cahiers des charges : faites un design sprint !
Le cahier des charges traditionnel n’est plus adapté à l’exploitation d’une idée. Entre l’idée et le lancement d’un projet, il peut s’écouler des mois et à l’échelle digitale, c’est une éternité. Une tribune de Brice Kieffer, Consultant Expert chez SQLI Consulting.
Les directions informatiques contraignent, en général, les entités métiers à cet exercice fastidieux : pas de cahier des charges, pas de projet ! Elles continuent, en effet, à appliquer les anciennes méthodes de gestion de projet inadaptées à la rapidité et souplesse exigées par les projets digitaux.
De plus, une fois le cahier des charges rédigé, on en connaît les limites : les exigences implicites ne sont pas intégrées et suscitent des frustrations en mode projet, l’expérience utilisateur (User eXperience) est rarement abordée et surtout, l’attention portée aux détails conduit à perdre de vue le problème à résoudre.
Le digital a besoin d'un mode d’émergence rapide et efficace des projets ! La démarche “Design Sprint” répond à ce besoin car elle allie l’innovation et sa mise en œuvre rapide (une idée, c’est une maquette), la collaboration (une équipe pluridisciplinaire) et le respect d’un délai très court (une semaine).
Qu’est-ce le “Design Sprint” ?
Le “Design Sprint” est inspiré du Design Thinking[1] et de l’approche agile. Il s’agit de concentrer sur une semaine les différentes phases du Design Thinking : inspiration, conceptualisation et réalisation.
Le meilleur moyen pour valider une idée, c’est de la matérialiser. Il s’agit donc de partir d’une idée et de produire une maquette ou un Proof Of Concept (POC) sous la forme d’un story-board (scénario) des écrans principaux de la solution et ce, en cinq jours seulement.
Pour y parvenir, un objectif précis à atteindre est fixé chaque jour :
● Jour 1 : Comprendre - Poser le problème à résoudre
● Jour 2 : Diverger - Trouver le maximum de solutions pour répondre au problème
● Jour 3 : Décider - Sélectionner une solution
● Jour 4 : Prototyper - Réaliser le POC de la solution
● Jour 5 : Tester - Valider la solution en la soumettant à des utilisateurs
Cette démarche a été créée par des équipes de designers dans les laboratoires de Google. C’est notamment Jake Knapp qui est à l’origine de sa déclinaison officielle au sein de l’équipe de Google Ventures, le fond de placement fondé par Google en 2009.
Voyons la démarche un peu plus en détail.
Avant le sprint : préparer
Il est important de bien identifier en amont sur quelle problématique précise l’équipe du Design Sprint va travailler. Le premier jour du sprint doit aider à l’affiner mais il est capital de démarrer avec un objectif précis à atteindre à la fin du sprint.
La qualité et la composition de l’équipe sont bien sûr des facteurs clefs de succès. La taille d’équipe idéale est de 4 à 8 personnes. La puissance de l’approche Design Sprint s’exprime par le fait de constituer une équipe pluridisciplinaire qui confronte des points de vue différents.
Les principaux profils qui composent l’équipe sont :
● Un UX (User eXperience) Designer : il va aider à formaliser l’expérience utilisateur et produire le story-board final
● Un décideur : il est important d’avoir un sponsor capable d’orienter les décisions du Sprint. Sa présence est nécessaire à minima sur les jours J1, J3 et J5. Dans le cadre d’une start-up, c’est le patron qui est présent.
● Un Product Manager : il est le référent fonctionnel sur la solution
● Un super utilisateur : il est le représentant des utilisateurs et va notamment être l’acteur du cinquième jour du sprint pour tester et valider la solution retenue.
● En fonction du thème, d’autres profils sont possibles : ingénieur, marketing, ...
Pour finir, le facilitateur est l’acteur clef dans ce type d’organisation. Il anime les différentes réunions du sprint, fait la synthèse des échanges et est garant du déroulement du sprint. Cependant, en tant que facilitateur, il ne participe pas à la conception de la solution proprement dite.
Pour doter l’équipe du sprint de bonnes conditions de travail, il convient de prévoir le planning détaillé sur la durée d’une semaine seulement et des conditions matérielles adéquates telles que la disponibilité d’une salle unique pour la semaine et des outils de travail (post-it, feutres, tableaux blancs, autocollants, …)
Jour 1 : Comprendre
Lors de cette première journée, l’équipe pose la problématique à traiter. L’approche, inspirée du Design Thinking, consiste à répondre à une question : « Comment pourrions-nous ... ? »
La première partie de la journée se concentre sur une présentation de l’organisation du sprint et de l’objectif visé à long-terme : « Pourquoi faisons-nous ce projet ? », « Que voulons-nous atteindre sous six mois, dans un ou cinq ans ? »
La deuxième partie de la journée va permettre de recueillir de l’information pour bien comprendre la problématique à traiter.
Pour cela, l’équipe peut s’appuyer sur différents exercices courts de dix minutes :
● Opportunité business : formalisation de l’opportunité business par le décideur ou le Product Manager
● Démonstration rapide d'une solution concurrente (ou dans un autre domaine mais similaire)
● Vivre le parcours utilisateur : imprimer les principaux écrans de la solution actuelle, les étaler et marcher dessus en suivant le parcours utilisateur
● Données Client : présentation d’études ou analyses existantes
● Interviews d'équipes : Ingénierie, Ventes, Service client, ...
● Analytics : rassembler des données sur l'usage de la solution actuelle
A la fin de la première journée, l’équipe écrit sur plusieurs post-it, différentes propositions répondant à la question : « Comment pourrions-nous … ? ».
Pour finir, l’équipe vote, sélectionne la meilleure proposition correspondant à la problématique à résoudre et définit les objectifs du sprint :
● « Qu'espérons nous apprendre ? »
● « Que devons-nous concevoir et prototyper pour apprendre cela ? »
● « Comment mesurer le succès du design sprint ? »
Jour 2: Diverger
Lors de cette deuxième journée il s’agit de trouver le maximum de solutions pour répondre à la problématique posée la veille. Il ne s’agit pas d’un brainstorming collectif, chaque membre de l’équipe travaille individuellement en silence. C’est un principe auquel Jake Knapp est attaché, il est convaincu que la recherche de solutions est plus efficace en travail individuel sans s’exposer aux avis des autres dans cette phase.
L’équipe commence par découper la User Story globale en différentes parties puis définit la partie à travailler en détail.
Chaque membre de l’équipe déroule ensuite le cycle suivant :
- Prendre des notes (5 mn) - synthèse du jour 1 (« que retenir ? »)
- Faire une « carte des idées » (Mindmap :10-15 mn) - On pose les idées sous la forme d’un diagramme en arborescence
- « 8 minutes de folies » (Crazy Eights : 8 mn) : Sur une feuille blanche pliée en 8, on fait 8 schémas rapides pour présenter une des meilleures idées dans chaque case (1 minute par schéma)
- Dessiner un croquis de la solution (10-20 mn) : En s’inspirant des meilleures idées des deux étapes précédentes, on doit dessiner sur une feuille un croquis de la solution proposée.
L’équipe répète le cycle pour traiter une autre partie de la User Story. Il faut prévoir deux à trois cycles maximum sur la journée. L’objectif n’est pas forcément de traiter l’ensemble de la User Story, le facilitateur peut décider de réduire le périmètre pour concentrer l’équipe sur une partie spécifique de la problématique.
Jour 3 : Décider
A l’issue de la journée précédente, l’équipe peut se retrouver avec une bonne dizaine de solutions différentes. Il va falloir choisir la meilleure !
Le facilitateur met en place un processus de présentation et d’analyse rapide des différents croquis. Pour gagner en efficacité et combattre l'effet de décision en groupe, il faut donner du poids au décideur dans cette phase.
Le processus de décision est le suivant :
- Le facilitateur colle les différents croquis sur le mur
- Chaque membre de l’équipe examine les croquis en silence et met un à trois petits autocollants à côté de chaque partie qu'il ou elle aime
- Critique en 3 minutes de chaque croquis : en groupe, on discute des points forts de chaque solution et les objections principales.
- Chaque personne choisit silencieusement sa solution favorite. Tous les membres placent en même-temps une grande pastille autocollante pour enregistrer le vote définitif. Le décideur bénéficie de trois grandes pastilles autocollantes avec ses initiales pour impacter plus fortement la décision finale.
Une fois la solution retenue, l’équipe se regroupe autour du tableau blanc pour dessiner le story-board qui sera utilisé pour le Proof Of Concept (POC) du lendemain.
Jour 4 : Prototyper
L’équipe va réaliser un Proof Of Concept (POC) destiné à être présenté à des utilisateurs. Le délai étant court, il s’agit simplement de représenter dans un outil du type PowerPoint des maquettes allégées (wireframes) des écrans principaux de la solution retenue. On cherche à concevoir un prototype ayant un niveau de détail suffisant pour obtenir des réactions d’utilisateurs.
Il est intéressant de s’appuyer sur l’UX Designer de l’équipe, spécialiste de ce genre d’exercice !
Un des membres de l’équipe devra également préparer le script des interviews à effectuer auprès des utilisateurs pour tester le prototype et recueillir leurs retours.
Jour 5 : Valider
C’est désormais le verdict final, l’équipe présente le résultat de son travail et le soumet à l’avis des utilisateurs. Elle convie un groupe d’utilisateurs potentiels de la solution et de recueille leurs appréciations et commentaires.
L’équipe finalise le sprint en formalisant un rapide bilan sur un tableau blanc : « ce qui marche ? », « ce qui ne marche pas ? ».
Un exemple : le hackathon Val d’Isère
Il y a un peu plus d’un an, la station de ski Val d’Isère organisait un hackathon, c’est à dire un concours chronométré ayant pour objectif de produire un prototype d’application présenté à un jury. Cet évènement devait répondre à la question suivante : « Comment pourrions-nous réinventer l’expérience de ski ? ». Cinq équipes ont été sélectionnées et invitées pendant cinq jours dans la station pour concourir. Toutes les conditions d’un Design Sprint étaient réunies : des équipes pluridisciplinaires (regroupant des UX designers, des concepteurs graphiques, des développeurs) devant produire en cinq jours un prototype d’application traitant une problématique du type « Comment pourrions-nous … ? » basée sur l’expérience utilisateur.
Il est intéressant de noter que lors des deux premiers jours les organisateurs de l’évènement ont faire vivre aux équipes « la vie d’un vacancier à Val d’Isère ». Au programme : arrivée par le train et le bus, séjour en hôtel, rencontres avec les acteurs et visites des lieux importants de la station (loueurs de skis, sécurité des pistes, vente de forfaits, commerçants, restaurants, hôtels, piscine, patinoire) et pour finir une demi-journée de ski !
Cette phase immersive a permis de recueillir un maximum d’informations pour nourrir le travail de recherche de solutions et de prototypage qui s’est effectué sur les trois jours restants. Ce travail s'est concrétisé en un story-board mettant en avant les fonctions principales de l’application et racontant une véritable histoire au jury. A titre d’illustration, voici la vidéo qui présente le projet retenu par le jury : « Hackathon Val d'Isère - Le hackathon le plus haut du monde »
Le Design Sprint : réservé aux « geeks » ?
La démarche Design Sprint est rapide et efficace. Elle a été éprouvée par Google dans des contextes variés (Chrome, Google Search). La recette magique, c’est la contrainte de temps et l'attention de tous les instants portée à l'utilisateur final ! En étant contrainte, l’équipe libère toute sa créativité.
Cependant, la démarche Design Sprint est bien adaptée pour tester une idée mais pas pour conceptualiser et tester le programme de refonte d’une centrale nucléaire ! Il faut donc l’utiliser à bon escient avec un objectif réaliste et atteignable sur une durée d’une semaine.
Pour finir, il ne faut pas penser que cette démarche est réservée uniquement aux start-ups ou aux « geeks ». Monter une équipe pluridisciplinaire sur une durée de cinq jours est tout à fait possible même au sein d’une grande entreprise et peut s’avérer rentable au regard du coût et moyens associés à la rédaction d’un cahier des charges plus classique.
Le Design Sprint peut paraître un peu fou mais dans le digital, il faut savoir être fou !
Les sources :
Read more: http://www.ladn.eu/actualites/finis-cahiers-charges-faites-design-sprint,article,30840.html#ixzz451wVfX6A
Aucun commentaire:
Enregistrer un commentaire