Design Sprint : pourquoi nous avons arrêté d’utiliser la méthode Google Ventures

    Forts du constat que nos clients ne sont presque jamais totalement à l’aise pour transformer une idée en un cahier des charges business oriented précis avec un niveau suffisant de spécifications nous permettant de démarrer le projet dans de bonnes conditions, nous avons entamé il y a presque 2 ans le chantier d’ajouter une offre de design sprint à nos compétences de développement.

    Outre le fait d’être une démarche saine pour démarrer une collaboration, les bienfaits de l’approche sont multiples.

    • Produire les livrables indispensables  pour démarrer le développement d'un produit dans de bonnes conditions
    • Obtenir un premier retour marché, franc et objectif
    • Quantifier le besoin en ressources nécessaires au développement
    • Valider une opportunité de collaboration entre l'agence et un nouveau client à travers une méthodologie structurante avec un risque d'échec maîtrisé

    Le design sprint, c’est quoi ?

    Issu du courant design thinking, le design sprint, est une méthode imposée par Google Venture, Venture Capital de la société éponyme, à tous les projets qu’elle finance (slack, Uber pour ne citer qu’eux). Mis au point par le charismatique Jake Knapp, l’objectif de cette méthodologie est de concevoir, prototyper puis tester une idée, une innovation ou un concept en seulement 5 jours. Notez que même si une application web est parfaitement adaptée à la méthode, il existe une multitude de cas non web où la méthodologie reste pertinente.

    Quoi qu’il en soit, la promesse est alléchante pour qui cherche à tester sa solution à un coût réduit et à minimiser les risques de concevoir une solution dont personne ne voudrait. Aussi, voici quelques un des principes clés et des raisons pour lesquelles cela fonctionne si bien sur le papier.

    Principe fondateur de la démarche de design thinking : mettre l’utilisateur au coeur de la réflexion et du processus d'innovation. Les outils à dispo étant par exemple une cartographie des interactions entre l’outil et l’utilisateur ou encore la définition de persona. Le tout organisé par un facilitateur, détenteur du savoir et animateur des différentes phases du sprint.

    Tout est fait dans une démarche de co-création et de complémentarité des compétences. En effet, l’essence même du design sprint est de valider des choix graphiques réalisés par un groupe réduit pour le compte d’un grand nombre d’utilisateurs. Il est donc indispensable que ces choix soient validés en amont. Les principaux livrables sont un prototype d'application interactif et sans code, et une série de 5 tests utilisateurs successifs dans des conditions les plus proches possibles du réel.

    Utiliser la palette d’outils des designers pour permettre au groupe de décisionnaires de s’exprimer de manière autonome en prenant soin de supprimer l’effet potentiellement indésirable d’une personnalité écrasante pour le groupe. Ainsi un facilitateur orchestre les interactions et des méthodes telles que le zen voting et le dessin permettent à chacun de s’exprimer selon le moyen qui lui sied.

    Enfin, réduire au maximum l’engagement de ressources. En effet, il est nécessaire de ne pas s’attacher au travail réalisé pour être capable de le remettre en cause. Une consommation de temps et de ressources trop conséquente pousserait le groupe à remettre en cause les facultés intellectuelles des utilisateurs plutôt que le produit, ce qui est rarement une bonne chose. 5 jours consécutifs * 8 participants (maximum)= 40 jours homme consommés au maximum. Certes ce n’est pas rien, mais tellement moins risqué que de foncer tête baissée dans la production.

    Pour ceux qui voudraient en savoir davantage sur la méthodologie originelle, nous ne pouvons que vous recommander de vous procurer le livre "Sprint", co-écrit par Jake Knapp et son équipe. De nombreux exemples, des checklists et astuces très activables permettent de s'approprier avec plus ou moins de réussite la méthode.


    Mais qu'est ce qui fait défaut à cette méthodologie ?

    Une fois rodés sur la méthode et après plusieurs dizaines de rendez-vous commerciaux, la totalité de mes interlocuteurs se sont dit convaincus par l’intérêt de réaliser un sprint en amont d’un développement d'un projet d'innovation ou une idée de business. En revanche dans l’extrême majorité des cas et quelque soit la taille de la société et la maturité du projet visé un problème récurrent subsistait : mettre à disposition une équipe de 3 personnes sur les 8 ressources pendant 5 jours consécutifs est tout simplement inconcevable pour la plupart des entreprises.

    Après de multiples tentatives en interne, puis progressivement auprès de clients, nous avons pu lentement nous forger une opinion forte sur les avantages et inconvénients de chacun des aspects du design sprint en tant que processus à part entière.

    Petite précision avant de démarrer, afin de coller au mieux à notre savoir faire, nous aborderons le design sprint appliqué à une application web ou mobile. Sachez cependant que la démarche est applicable à une multitude d’autres sujets.


    La solutions : co-concevoir, pas forcément co-designer.

    Nous l’avons évoqué au début, la démarche de co-design est un élément fondamental dans la réussite du sprint. Cette démarche trouve cependant ses limites lorsque l’on arrive à l’étape de conception. L’étape de conception consiste à traduire une fonctionnalité sous la forme d’une succession d’écrans impliquant des interactions avec l’utilisateur.

    Si le fait d’impliquer tout le monde est salutaire, peut-on réellement prendre le risque que des designers en herbe se mettent à imaginer de nouvelles manière exotiques d’implémenter des fonctionnalités souvent simples et sans enjeu pour la réussite du projet, en balayant au passage d’un revers de la main tous les concepts d’ergonomie dont ils n’ont de toute façon pas connaissance ?

    Les conséquences ont alors été sans appel. Tous les tests utilisateurs réalisés dans ces conditions ont conduit les cobayes à s’interroger de manière systématique sur des écrans sans réel enjeu pour des raisons d’erreur d’ergonomie, d’inconsistance dans l’expérience. L’utilisateur doit être guidé à chaque étape et lui expliquer chaque fonctionnalité entache sérieusement sa capacité à s’immerger dans le projet. Respecter les codes du web, ça n’est donc pas donné à tout le monde.

    Ainsi, à l’instar de toutes les formes d’industrie requérant une formation poussée et du savoir faire, la conception d’une application est une tâche complexe qui doit impérativement être confiée à des experts UX / UI.On évite ainsi de passer à côté de la substance même du test, à savoir valider une expérience plutôt qu’un apprentissage empirique et douloureux des bases de l’ergonomie.


    Prototype : le syndrome du carton pâte

    L’un des autres problèmes que nous avons rencontré avec la méthode concerne cette fois ci l’étape de prototypage. Véritable étape clé du projet, elle est réalisée, comme toutes les autres étapes, sur une seule journée. Plusieurs conséquences à ce constat.

    Si l’équipe n’est pas suffisamment grande, le travail sera bâclé, peu convaincant et on ne pourra tester que le parcours critique. Il sera aussi plus difficile de permettre à l’utilisateur de se projeter dans un cas d’usage concret de l’outil. Il sera donc plus difficile de lui demander d’imaginer un prix, une reformulation de la proposition de valeur ou encore s’il envisagerait une utilisation quotidienne de l’outil.

    Si l’équipe est suffisamment grande, il n’est pas rare qu’il n’y ait que 2 designers au maximum. Or la charge de travail à cette étape est indiscutablement entre les mains des designers. La proposition faite de répartir les rôles va à priori conduire les non designers à avancer sur leur sujet souvent une matinée puis regarder les designers finaliser le travail l’après midi, avec le risque que le tout se transforme en une joyeuse séance de sensibilisation à l’utilisation de sketch. C’est également et souvent à ce moment que l’équipe se détache du projet, repart gérer ses affaires courantes et perd le fil de ce qui sera réellement testé.


    Organisation : vous avez dit 5 jours ?!

    Même si l’organisation d’un sprint sous la forme d’une task force de 5 jours d’affilés semble adaptée pour atteindre l’objectif de s’impliquer à son maximum sur une durée très courte, la mise en application de ce principe constitue également une faiblesse.

    En effet, même si les deux premiers jours se passent souvent dans la joie et la bonne humeur avec l’implication qui convient, la seconde partie du sprint laisse souvent la voie à des dispersions et des baisses de motivation. Le tout venant quotidien, de plus en plus pressant, fini par reprendre le dessus et c’est bien souvent lors de la journée de prototypage, pourtant l’une des plus importantes que le groupe, pourtant si motivé la veille, fléchi.

    Nous avons donc réfléchi à une autre forme d’organisation, lourde en conséquences mais qui règle la plupart des problèmes que nous avons rencontré.

    Aujourd’hui, un sprint a une durée de 4 à 6 semaines, qui dépend la plupart du temps de la disponibilité de nos clients. Au cours de ce délai, la mobilisation du client est de 3 jours hommes, discontinus, amplement suffisant pour que les porteurs assument la paternité du travail réalisé.

    Ainsi, la première journée est assez similaire avec ce qui est fait dans la méthode originelle. Nous embrayons ensuite sur une phase de formalisation des écrans ainsi que de la direction artistique. Un point intermédiaire permet de partager avec l’ensemble du groupe le résultat de ces travaux.

    Il est alors possible d’ajuster tout ou partie du contenu. C’est ensuite la phase de prototypage qui démarre, généralement pour une période d’une semaine.

    C’est d’ailleurs grâce à cette découpe que nous avons pu résoudre les deux problématiques évoquées plus haut et rendre accessible le sprint au plus grand nombre.


    Délai de réalisation : vitesse, sans précipitation

    Le fait de s’octroyer davantage de temps nous permet de faire des choix de design forts, avec une direction artistique qui sera dans la majorité des cas être ce qui sera effectivement développé.

    Le fait d’avoir cette discontinuité nous permet notamment de laisser le temps au client de faire leur retour. Pour cela nous leurs donnons accès à un projet Zeplin dédié (outil collaboratif en ligne de gestion). Chacun est ainsi libre de faire l’ensemble de ses retours afin qu’ils soient intégrés dans le prototype. La phase de recherche et de consolidation du wording se fait à ce moment précis et personne n’est acculé par des contraintes temporelles.

    L’une des étapes clé que nous avons ajouté à la méthode consiste à lister l’ensemble des hypothèses que nous avons pendant le sprint. Afin d’être plus tangibles dans notre manière d’étudier chacun des tests, nous procédons à un listing exhaustif de l’ensemble des hypothèses qui sont à valider. Elles sont consignées dans un document qui sert de trame à l’entretien. On peut ainsi vérifier que chacun des éléments est effectivement compris et dans le cas contraire les retours seront traités afin de quantifier la charge de temps nécessaire au traitement des retours.

    Cette trame de lecture est également calquée sur le scénario de test de manière à s’assurer que le prototype permettra bien de tester l’ensemble des points que l’on cherche à valider.

    Extrait d'un questionnaire de test

    La finalité du processus : garantir l'atteinte du market fit  !

    Le fait que l’ensemble des livrables soit beaucoup plus qualitatif a également de nombreux effets vertueux qui sortent du périmètre du simple test utilisateur.

    Un porteur de projet, une startup ou plus généralement une grande entreprise peuvent aller démarcher des fonds ou obtenir une validation de la part de leur direction. Les éléments présentés sont tangibles, l'innovation palpable et les retours d’utilisateurs séduits font office d'arguments indiscutables. Il est également plus simple d’avoir une estimation précise du délai et du coût de la plateforme dans ses futures versions.

    Si le sujet abordé est un produit web, il est assez courant que nos clients fassent appel à certains prospects stratégiques au moment des tests pour également les sensibiliser à la fois à la démarche mais également leur permettre de co-designer la future solution. Cette étape peut lourdement peser dans la balance au moment de l’acte d’achat


    Conclusions

    La méthode proposée par Google Venture et telle que présentée dans le livre est indiscutablement pertinente et également un passage obligé pour quiconque souhaite sécuriser un processus d'innnovation ou une super idée de business.

    Néanmoins, appliquée à la lettre, elle tiendra difficilement ses promesses. Entre organisation compliquée, charge de travail hyper variable et effet de lassitude, on s’expose au risque de finir un prototype bâclé sur un coin de table, avec une équipe dont il ne restera bien souvent que 2 ou 3 personnes dès le 3e jour.

    Le résultat produit est souvent un peu déceptif et peut laisser un goût amer à une équipe qui a pourtant la sensation d’avoir tout donné. La charge de travail nécessaire pour rendre le produit prêt à être développé est alors plus que conséquente et peut pousser à remettre en cause des éléments validés en test et ainsi dévaloriser le travail du groupe.

    La méthode de design sprint Dernier Cri reste très inspirée de la méthode initiale proposée par Google Venture. Elle est désormais au coeur de la stratégie de développement de l’agence avec plus de 30 sprints réalisés à ce jour. Les nombreuses libertés que nous avons prises la rendent plus viable et génératrice de valeur. Par ailleurs, la satisfaction systématique communiquée par nos clients nous laisse croire que nous avons fait le bon choix.

    Si vous avez vous même expérimenté puis modifié la méthode, je serais curieux de savoir comment et pourquoi.

    Benjamin Tierny

    Benjamin Tierny

    Co-fondateur et CEO