Dans la première partie de cet article consacré au Design Sprint, j’ai fait le point sur son origine, ses raisons d’être et son déroulement, théorique et pratique. Sa mise en œuvre à diverses occasions m’a également amené d’autres enseignements, que l’on ne lit habituellement pas dans les (courts) articles consacrés à cette méthode, encore loin d’être galvaudée.

Ce que ce n’est pas…

Evidemment, cette approche comporte ses risques, parce qu’elle peut être mal comprise, ou encore mal appliquée. En effet, d’une part, un quiproquo et un écart importants peuvent se faire jour entre la vocation du sprint (voir Part 1 de l’article) et l’attendu du client. D’autre part, le sprint se déroulera d’autant mieux que la personne le facilitant aura une bonne expérience d’animation d’ateliers en général, et de ce type d’exercice en particulier. En effet, il faut avoir à la fois un certain recul afin d’absorber le trop plein d’énergie contenue dans la salle et garder la tête froide pour tout le monde, mais aussi la fermeté (toujours bienveillante) pour cadrer et recadrer quand c’est nécessaire.
Dans tous les cas :

• Le design sprint est tout sauf une solution magique à tous vos problèmes… mais, comme on l’a vu, plutôt une synergie collective, active, se concentrant sur l’élaboration d’une solution hypothétique à une problématique particulière, le fameux MVP. Il ne s’agira donc pas de tester et valider toutes les options fonctionnelles ou les parcours possibles pour obtenir une solution globale. Typiquement le design sprint n’est pas indiqué pour une refonte de site ou d’un outil métier dans son ensemble. A contrario, il peut être utile pour concevoir une appli “mono-tâche”, adresser une problématique de parcours particulière, tester ou concevoir une fonctionnalité… Par définition, notre solution va s’adresser à la cible et à l’un des problèmes évoqués en début de sprint, rien d’autre.
• Par extension, ce sera encore moins l’occasion de revoir la stratégie ou l’image d’une organisation/entreprise en espérant passer tout en revue en 5 jours.
• Le sprint n’est pas une fin en soi. Autrement dit, s’il permet de tester une solution, celle-ci sera rarement assez aboutie ou complète pour être implémentée de suite. Elle nécessitera certainement des ajustements, des améliorations, encore d’autres tests, bref des itérations avant sa mise en production, avec en amont des fichiers propres delivery-ready (ce que n’est pas censé être le prototype du sprint).
• Ce n’est pas non plus un hackathon où l’on va se pencher sur plusieurs solutions à la fois. Comme on l’a montré, il faut en milieu de parcours converger vers une solution (qu’il s’agisse d’un parcours ou d’un écran). Ce n’est pas de l’AB(CDEF…) testing. Le sprint doit porter en lui sa propre proposition de valeur.

En bref, il ne faut pas confondre Design Sprint et sprint tout court, autrement dit vitesse et précipitation. Le sprint ne peut adresser toutes les problématiques à la fois, utilisé à mauvais escient ou en ne respectant pas a minima son format, ses étapes et son but, il pourra s’avérer contre-productif voire destructeur car épuisant et déceptif.
 

Sprint out of the book

Si le sprint est tout indiqué pour “penser en dehors de la boîte” (think out of the box), il est aussi parfois nécessaire de poser le livre et ne pas suivre tous ses préceptes à la lettre, au risque de rester bloqués soit face à un problème insoluble soit dans une situation particulière à un moment donné.
La personne qui anime le sprint devra faire preuve de bon sens et de plus ou moins de souplesse, de pragmatisme en tout cas, pour le mener à son terme, sinon son but. Si elle est garante du temps et des étapes successives, elle devra bien souvent adapter son jeu car elle se trouve face à d’autres humains. La bienveillance doit parfois prendre le pas sur le “time timer” et il arrive que l’on déborde du temps alloué. Il faudra aussi savoir ménager les susceptibilités ou timidités des un.e.s, tempérer les autres. Mais également s’adapter aux contraintes des participants (sorties de salle pour un coup de fil important, disparition/réapparition intempestive, quand on est dans les locaux du client). La patience du facilitateur est donc souvent mise à rude épreuve. D’où la notion d’expérience, plus pour pouvoir avoir le recul et l’affirmation nécessaire, que pour pouvoir dérouler la méthode rigoureusement par coeur tellement on l’a fait dans le passé. Il faudra donc trouver un certain équilibre entre toutes ces données, car le principal est que le client soit satisfait, et que l’on “sorte” une solution, sans que ça coûte la vie à quiconque.

De fait, on peut très bien animer un sprint à deux. En effet, comme dans un couple l’un prend la relève pour s’occuper de l’enfant parce que l’autre est momentanément épuisé, en situation de sprint il peut être assez appréciable de pouvoir s’appuyer sur un.e alter ego face à des participants récalcitrants ou “trop” pleins d’énergie. Ou encore pour s’assurer d’un choix ou d’une orientation.
Je me suis également aperçu que toutes les étapes ne sont pas bloquantes si elles ne sont pas réalisées. Par exemple, passer directement à des esquisses un peu évoluées sans passer par le Crazy8, qui est un exercice assez déstabilisant (et il faut bien le dire plutôt adapté à des designers), est tout à fait possible, surtout si l’on a pris du retard à l’étape précédente. Car oui, il faut parfois gérer un peu d’élasticité dans le temps et oublier le “time timer” si l’on estime qu’une étape n’est pas assez avancée. L’important est de finir le prototype le jeudi et d’avoir organisé les tests du vendredi, car ce n’est pas grave si tout n’est pas parfait, l’important est de récolter le maximum de retours utilisateurs (feedback).
Autre exercice qui ne me convainc pas toujours : la technique de prise de note dite “How Might We” (on écrit HMW en haut à gauche des post-it, et l’on écrit sous forme de question ou d’opportunité les problèmes évoqués lors des entretiens du lundi avec les experts). Premièrement, la consigne n’est pas toujours bien comprise et le résultat peut ressembler à un assemblage de mots-clés ou de commentaires fleuves. Ensuite, cela correspond plutôt à une tournure d’esprit anglo-saxonne. En effet, les français, d’ordinaire critiques et cartésiens, ont peut-être plus de mal à se projeter vers une interprétation et une perspective relativement ouverte et positive. D’ailleurs, on pourrait transformer le “How Might We” en “How To Fail”, exercice alternatif consistant à relever les raisons pour lesquelles le projet pourrait échouer pour trouver les solutions qui garantiront son succès.
On pourrait très bien imaginer également intégrer d’autres ateliers, plus adaptés et qui pourraient servir le sprint, tant que l’on en garde l’aspect séquentiel, essentiel à son bon déroulement (ex : proposer un ou deux 6to1 – lire notre article – pendant la journée d’esquisse).
On peut aussi avancer ou sauter certaines phases. Par exemple si le sprint progresse bien et si tout le monde partage la même vision, il n’est pas obligatoire de procéder à tous les votes inter-ateliers, un vote en fin de journée peut suffire. De même, le décideur ne souhaite pas toujours utiliser son supervote, pourquoi l’y forcer ?
Bref, encore une fois, savoir sortir des clous n’est pas interdit, même si l’on imagine que J. Knapp a peut-être déjà tout essayé, il est important de continuer d’expérimenter tout en cherchant à satisfaire le client et son projet, en prenant le sprint pour cadre et non comme une table de commandements et en incluant partiellement, ponctuellement des méthodes typiquement UX.
 

Le Design sprint au sein de la démarche d’UX Republic

Comme on l’a dit plus haut, le design sprint ne saurait se suffire à lui-même. D’emblée, il nous semble absolument nécessaire de l'”encadrer” et de prévoir a minima une phase d’immersion en amont (voir notre offre), si le client dispose d’éléments solides pour nourrir le sprint, voire de prévoir carrément une phase de recherche et/ou d’audit si nécessaire. Ce n’est ni confortable ni très efficace de démarrer un sprint de zéro, sans s’être aguerri d’un minimum d’info sur lui, son secteur, ses concurrents et surtout la compréhension de son métier et pour ce qui nous concerne en premier lieu, ses utilisateurs. 
Ensuite, à son issue, le sprint nécessitera certainement encore quelques itérations afin d’améliorer la solution pour qu’elle réponde au plus près aux besoins utilisateurs, son marché, son environnement. Il peut aussi être la base pour de futurs travaux complémentaires. C’est d’ailleurs un peu sa vocation latente puisque tournée vers l’innovation : être le point de départ du futur prochain de l’organisation commanditaire. Nous préconisons donc une suite au sprint afin de pouvoir finaliser le concept et sa mise en production proprement, et pourquoi pas sur le long terme engager une collaboration en vue d’accompagner notre client dans sa transformation.

Alexis CANGY | Consultant UX/UI | Design Sprint Master