Google Design Sprint

Vous avez fait un produit d'innovation, mais vous constater qu'il ne correspond pas à la demande ?
Vous avez passé des mois ou même des années à faire des hypothèses, trouver des solutions, utiliser les dernières technologies à la mode, pour un produit qui rate sa cible ?
Aujourd'hui, je vais vous présenter une méthode pour vous aider à valider les hypothèses d'un projet d'innovation avant de faire le MVP en une semaine.


Processus Agile et ses limites

Quand on parle de réalisation de produit, on parle souvent de processus Agile, LEAN, Scrum... Pour ceux qui ne connaisse pas l'agilité (et Scrum), voici une petite explication.

Qu'est-ce que l'agilité ?

Pour répondre à cette question, les méthodes agiles sont des pratiques de gestion de projet favorisant la collaboration entre plusieurs équipe auto-organisé et pluridisciplinaire, et leurs clients. Elles se base sur le manifeste agile publié en 2001 qui présente les 4 piliers et les 12 principes de l'agilité.

Une de ces méthodes les plus connu est SCRUM créé par Ken Schwaber et Jeff Sutherland (décrit en 2010 dans le "Guide Scrum").

Cette méthode se base sur la livraison (delivery) de manière itérative du produit via des sprints (d'une durée de 2 à 4 semaines dépendant de la maturité de l'équipe et de la complexité du projet). Exemple, on a un produit qui doit contenir 6 fonctionnalités, pour le premier on doit avoir les fonctionnalités n°1 et n°3, pour le second les n°2, 4 et 6, et pour le dernier sprint, la fonctionnalité n°5.

Et voici le schéma Scrum expliquant les différentes phases d'un sprint :

Sprint Scrum

Quelques explications s'impose :


Après cette courte explication des méthodes agiles et de Scrum, nous allons parlé des limites que ce processus peut avoir dans des projets d'innovation.

Limites dans des projets d'innovation

Certaines Start-up sont confrontés à 3 problèmes majeurs :


Pour pallier à ces problèmes, Eric Ries développe le Lean Startup, initié en 2008, en se basant sur sa propre expérience (mauvaise compréhension des besoins des consommateurs chez Catalyst, et trop de temps et d'argent dépensé dans un produit chez There Inc), le Développement par la clientèle (ou "Customer development") de Steve Blank et le Lean Management de Toyota.

Il décrit que le premier delivery doit être un MVP (Minimum Viable Product) pour tester les hypothèses du produit le plus tôt possible pour corriger les éventuels faux pas.

Phases de conception avec un MVP

Voici un schéma explicatif des phases de conceptions :

Phases de conception


Nous avons 4 phases :

Si on ajoute le MVP, ça nous donne :

Phases de conception avec MVP


Donc on commence avec la phase de Réflexion. On fait nos sprints avec la phase de Construction. Lors de la phase de Lancement, le MVP est prêt à être en production. Et on fait des tests utilisateurs avec la phase d'Amélioration.

Le but du MVP est de pouvoir en apprendre le plus vite possible sur le produit à faire. Donc plus on itère vite, plus on apprend vite.
Cependant, la vitesse est limitée dû au temps de construction de ce MVP.

C'est la qu'entre en jeux le Google Design Sprint. Mais avant ça, petit point historique.

Création du Google Design Sprint

Le Design Sprint à été créé en 2016 au sein du Google Venture (incubateur de start-up de Google) sur une idée de Jake Knapp avec l'aide de John Zeratsky et Branden Kowitz, tous les trois Designer de projet.

Ils intègrent dans leur méthode le "Design Thinking", le "Lean Startup" et le "Lean UX" (créé en 2013 par Jeff Gothelf et John Seiden).

Qu'est-ce que c'est ?

Le Google Design Sprint est un processus de conception pour startup ou grandes entreprises pour répondre, en un court laps de temps (environs 5 jours), à une problématique business pour arriver à un produit / service. Il impose cette contrainte temporelle pour réduire les risques d'un projet.

Et le principal atout est le MVC. Non, ici ce terme ne signifie pas Modèle Vue Contrôleur mais Minimum Viable Concept. C'est toute conceptualisation, comme des schémas, maquettes..., pour s'affranchir de la limite de vitesse imposé par le MVP.

Pour être plus clair, nous allons modifier notre schéma des phases de conception :

Phases de conception avec le Design Sprint


Le but est de passer directement de la phase de Réflexion à la phase d'Amélioration avec un prototype et d'itérer autant de fois que nécessaire pour correctement cadrer le besoin et minimiser les risques :

Phases de conception avec MVC


Dès que le projet est correctement cadré, on peut commencer les phases de Conception et de Lancement avec la réalisation d'un MVP.

Mais comment faire ce MVC ? Qu'est-ce que la méthode nous dit pour y arriver ?

Processus Google Design Sprint

Le guide du Design Sprint nous montre un processus en 5 jours, détaillé heure par heure. Ici, le but est de faire une présentation assez courte, si vous êtes intéressé, je vous conseille le lien vers le site GV ou encore le livre dédié au GDS.
Mais le GDS est multiformes et peut s’adapter à vos besoins. Nous y reviendrons dans le chapitre Multiformes, pour l’instant concentrons-nous sur les bases de ce processus :

Processus du Google Design Sprint


Avant de le détailler, il faut faire une étape d'initialisation des ateliers (ou "Set the stage"). Cette partie est crucial pour réaliser correctement la méthode. Heureusement, on nous donne une checklist des étapes à suivre !

Je ne vais pas la détailler ici mais voici les idées principales à retenir :

Et il faut bien garder en tête les idées clés : Maintenant que nous sommes prêt pour le sprint, nous pouvons attaquer les journées !

Lundi
Le but de cette journée est que chacun doit comprendre les objectifs, les problèmes du projet et de partager toutes les connaissances sur le sujet.
Durant cette journée, nous allons utiliser différentes méthodes pour prendre les bonnes décisions, faire remonter les problèmes et les objectifs les plus important.
Vous pouvez retrouver une checklist de la journée ici

Mardi
Sur cette journée, nous imaginons des solutions pour résoudre les problèmes majeurs évoqué lors de la première journée.
De plus, il est conseillé de recruter les testeurs pour la dernière journée même si il vaut mieux faire cette étapes lors du “Set the stage”.
Vous pouvez retrouver une checklist de la journée ici

Mercredi
Maintenant, nous allons voter pour la solution qui répond le plus à nos objectifs. Ce vote est basé sur 3 critères du Design Thinking : la Désirabilité, la Faisabilité et la Viabilité Business.
Et nous faisons des storyboards pour créer la maquette le jour suivant
Vous pouvez retrouver une checklist de la journée ici

Jeudi
Créons notre maquette ! Nous nous basons sur les storyboards du Mercredi pour pouvoir les transformer en prototype.
Ensuite nous allons faire des hypothèse concernant ce prototype pour le Vendredi. Nous voulons en valider le plus possible pour être sûr que c’est le bon produit à faire.
Vous pouvez retrouver une checklist de la journée ici

Vendredi
C’est l’heure du test ! Nos testeurs vont essayer le prototype et nous faire du feedback.
Quand tous les tests sont fini, nous pouvons faire une synthèse sur l’expérience des testeurs et 3 situations s’offre à nous : Vous pouvez retrouver une checklist de la journée ici

Multifomes

Plus haut, j’ai mentionné que le Google Design Sprint était multiformes. Mais peut-on avoir un processus adapté à tout nos besoins ? Et peut-on adapté la durée du sprint ?
Oui. Et je vais vous montré un tableau pour le prouver :

Google Design Sprint - Multiforme

Vous pouvez aussi consulter cette page qui ressence une bonne partie des Design Sprint.
Vous pouvez y voir des durées propres à chaque sprint (3 jours, 4 jours...) et leurs livrables attendu.
Lors d’une précédente expérience, nous avions un processus en 3 jours avec comme livrable des schémas d’architecture testé devant les responsables des SI.
De plus vous pouvez ajouter d’autres ateliers que ceux proposé de base par le GDS.

Ce qu’il faut retenir

Le Google Design Sprint est une méthode pour valider nos hypothèses, avant de faire un MVP, via un MVC qui est testé avec des utilisateurs finaux. Il permet de décider rapidement si c’est le bon produit à faire, et réduit les risques de dépenser trop d’énergie et d’argent dans un produit qui ne fonctionnera pas.


Si cette présentation sur le Design Sprint vous a plus, n’hésitez pas à la partager et nous faire des retours. Vous pouvez aussi consulter nos autres articles ou entamer la discution pour une future collaboration.

top