Bon, je vais râler un peu suite à la lecture de cet article écrit par Pauline Thomas. Il y a plusieurs aspects avec lesquels je ne suis pas d’accord et je vais essayer de clarifier ça.
Atelier VS Design sprint
Commençons par l’opposition entre design sprint et Atelier ou Workshop. Si je définis, l’atelier comme un temps court de travail sur une journée ou une demi-journée récurrente avec un groupe restreint, le design sprint se définie initialement comme étant réalisé sur 5 jours à 8 ou 10 personnes en suivant le sacro-saint protocole de Jake Knapp.
Sauf que… je vois de plus en plus « sprint master » préconisé de faire plusieurs sprints à intervalles réguliers et c’est ce qui se met aussi en place dans certaines entreprises. La durée du sprint va varier de 1 à 5 jours… On peut en faire un parallèle, à la suite… ou de là, ça glisse gentiment vers le design marathon.
À une période, je travaillais avec Fjord, on appelait ça un Rumble, ça se fait sur deux jours souvent avec une vingtaine de participants, une progression sur les 2 jours et un certain nombre d’exercices types « design studio ». Au final, tout ça revient un peu au même, l’idée c’est de co-concevoir une solution avec l’ensemble des parties prenantes sur un temps donné. Est-ce que la différence n’est pas entre ceux qui suivent le dogme Knappien avec la sauce marketing qui va avec et ceux qui s’adaptent aux contraintes et aux objectifs des projets ?
Échouer vite, recommencer
« Fail fast to succeed sooner »
Cette manie de vouloir faire vite sous la contrainte « faire vite, échouer vite, recommencer ». Bon, alors faisons un petit calcul. Un design sprint, c’est 10 personnes pendant 5 jours, plus le temps de préparation, 2 semaines et de débriefing, une semaine pour un ou deux designer. Ça fait donc :
10×5 + 4×5 = 70 humain/jours pour un design sprint.
Alors, disons trois design sprints pour trouver la bonne solution, ça fait 210 humain/jours. Soit un an de travail ou, disons si on veut retomber sur la même durée que 3 sprints, ça fait plus ou moins 4 personnes pendant 3 mois. À ce prix on peut faire plusieurs belles itérations en déroulant correctement les phases de recherche, de conception et de validation sans tomber dans l’urgence, cela sans doute pour un meilleur résultat ou du moins un résultat dont on pourra justifier la validité.
Oui, car évoquer l’efficacité du design sprint est une bonne question. J’ai cherché dans la littérature, mais je n’ai pas trouvé d’étude comparative permettant valider ou d’invalider l’efficacité du design sprint. Je n’ai rien trouvé non plus sur le ROI (Retour sur investissement) des design sprints.
Et si l’important c’est les enseignements à tirer des échecs, il est aussi possible de tirer des enseignements en se mettant dans des conditions qui permettront d’aboutir à un résultat positif. Ça demande juste une première phase de réflexion sur la stratégie UX à suivre et la mise d’un protocole permettant de valider ou non les hypothèses émises.
Alors recommencer le même processus plusieurs fois de suite en espérant arriver à un résultat différent me parait vain. Mêmes causes, mêmes effets, encore et encore.
Sur le fonctionnement des groupes
Il faut voir qu’il n’est pas forcément pertinent de co-concevoir et qu’il faut avoir les bonnes personnes pour cela. La co-conception est pertinente pour les choix ayant un poids organisationnel et social fort. Si c’est juste un poids organisationnel comme créer un design system, des experts suffisent. Si c’est juste un poids social comme réorganiser un service, un flux de production, il suffit d’impliquer les individus concernés. Il n’est donc pas pertinent de mettre le design sprint à toute les sauces, et même au sein de celui-ci, le 4éme jour de prototypage est souvent un jour bancal ou seuls ceux qui tiennent le mulot sont réellement actif.
En termes de dynamique de groupe, il faut bien comprendre que le design sprint regroupe des personnes, dans un même lieu, à un rythme contraignant et fatiguant pour aboutir à une solution à tout prix.
Les processus de décision, de priorisation se basent sur le vote ou sur la décision du décideur. On est loin d’un processus permettant d’aboutir à un consensus « je suis d’accord » ou même consentement « je suis d’accord, ou à défaut je peux vivre avec cette solution ». Le vote revient à négliger l’avis des personnes minoritaires et à créer des groupes (les pour, les contres et les autres). C’est souvent le pire mode de décision, avec celui de la décision du décideur.
Le design sprint n’instaure en rien les conditions d’un fonctionnement de groupe bienveillant qui sauraient faire émerger des solutions par l’écoute de chacun. Au contraire, la nécessité d’aller vite va couper court aux palabres. Quand c’est maitrisé, le fait de maintenir une pression temporelle va permettre de se centrer sur l’essentiel, éviter que les participants se perdent dans les détails. Ça évitera aussi dans une certaine mesure les frictions entre les participants, car vous ne leur laissez pas le temps de s’écharper.
Mais il faut bien être conscient que peu de choses vont évoluer, socialement parlant, pendant et après le design sprint. Surtout que dans la majorité des cas, les sprints masters ne font pas partie de l’entreprise dans laquelle ils interviennent, et donc après eux, le déluge, heu non même pas, en fait il ne se passe rien.
Et le retour l’être aimé ?
Vu que le design sprint tient moins de promesses que prévu, est ce qu’il peut faire revenir l’être aimé ? On sait jamais sur un malentendu.
Il faut reconnaitre que le Design sprint est un bon outil de formation qui permet de sensibiliser aux différentes phases d’un projet et qu’il peut permettre de confronter les apprenants à certaines difficultés que l’on rencontre régulièrement.
Je dirai aussi que les trois premiers jours vont pouvoir faire émerger des problèmes auxquels il va être nécessaire de consacrer un temps plus long pour y répondre apportant plus de questions que de réponses.
Mais il faut bien considérer qu’en 5 jours il n’est pas possible de concevoir une solution correcte, encore moins de la prototyper en une journée, ni vraiment de la tester. On restera donc sur des résultats peu valide. De même un design sprint ne va pas changer une équipe ou une entreprise, soit celle-ci est déjà prête à évoluer avec ou sans sprint, soit ça ne sera qu’une parenthèse dans sa morne routine.
Il ne faut pas attribuer au design sprint des vertus qui n’ont pas lieu d’être. Je vous invite à vous poser la question de la temporalité que vous voulez à donner à vos projets, à vos équipes. Le travail dans une urgence artificielle est-il pertinent ? Est-ce que ça apporte des conditions de travail respectueuses de chacune et chacun ?
C’est cool de lire un article qui remet en question le design sprint. Dès que de nouvelles méthodes sortent dans le domaine de l’UX j’ai l’impression que la plupart des designers les considèrent comme des saintes écritures. Si part mégarde on fait l’erreur de les critiquer ou de se poser certaines questions concernant leur réelle efficacité, on se fait lyncher.
A moins que ça ne soit l’effet réseaux sociaux. ^^
Merci pour cette article Raphaël,
je suis d’accord avec le fait de remettre en question une méthodologie quand elle semble s’imposer comme un dogme. Lors du workshop que nous avons fait au Laptop avec les équipes de google, nous avons surtout oublié une question fondamentale : à quoi ça sert vraiment un design sprint ? Car en effet nous n’en n’avons pas tous la même utilisation du sprint… :
– les équipes de google venture utilisaient semble-t-il le sprint pour générer et tester des nouveaux concepts / produit rapidement
– les équipes de google (en interne) ont adapté la méthode pour aider des équipes de développement perdues au milieu de leur process agile de « prendre du recul » , sortir la tête de l’eau et retrouver du sens dans un contexte de dévéloppement long terme.
– nous avons aussi vu des exemples de sprints design menés pour construire une expérience client et aligner l’ensemble des parties parties prenantes de l’entreprise.
– enfin beaucoup d’agence semblent utiliser le sprint comme « ticket d’entrée » à une démarche design, mais malheureusement avec beaucoup de difficulté à vendre la suite.
En conclusion : il y a beaucoup de gens qui parlent des sprints, mais on ne parle pas du tout de la même chose. Et en particulier, très peu utilisent les sprints en réalité pour créer, concevoir et dévélopper (de zéro) des nouveaux outils ou produits numérique.
Parce qu’il me fallait proposer une réponse pour élargir le champ d’interprétation de chacun
> https://www.linkedin.com/pulse/critique-amicale-de-la-du-design-sprint-raphaël-fabrice-liut/?published=t
Cette critique était bien trop brute et rapide pour ne pas avoir un retour qui je l’espère sera constructif pour le plus grand nombre. la vérité est entre les questions et affirmations de chacun.
Ma réponse sur linkedin :
Fabrice,
– 8x5part +2x2part = 5 Non, ça fait 44h/jour toujours. Et dans ce cas tu n’as aucune information sur les utilisateurs, donc c’est tout sauf de l’expérience UTILISATEUR.
– Le « bon sens » est souvent contredit par la science : « Le vote revient à négliger l’avis des personnes minoritaires et à créer des groupes » ce n’est pas du bon sens, c’est étudier en psychologie sociale, avec des expériences et c’est parfaitement généralisables, et tout et tout.
– De même quand tu parles « d’intelligence collective » ça va dépendre du type de performance que tu veux atteindre. Est-ce la solution qui peut être apportée par le plus brillant des participants (cas de l’expert) ? Ou on est nécessairement dans une réponse collective ?
Alors, si je parle de dogme, c’est bien pour faire la différence entre les croyances, le « bon sens » et les connaissances scientifiques que l’on peut trouver dans la littérature en sociologie et en psychologie sur la gestion des groupes.
La co-conception n’est pas à jeter à la poubelle, loin de là, mais il faut une vraie réflexion sur la dynamique, sur « la recette », la chimie nécessaire pour chaque projet.
Et enfin ma critique n’a rien de précipité, c’est plus le fruit d’observations, de discussions et de lectures largement mûries. Oui, il m’arrive de prendre le temps.
Je suis aussi très sceptique quant à cette méthodologie, car elle ne capture que très peu la complexité d’une entreprise, d’un produit, d’un marché..
C’est dans la complexité que la qualité de l’execution réside pas dans la phase d’idéation.. Bref je suis d’accord que l’urgence que crée le design sprint n’aide en rien à changer une organisation ou un produit.. tout au plus il aide à impulser une solution qui est probablement un peu trop simpliste pour résister à l’épreuve de la réalisation.
Merci de ton retour.
Je te rejoins assez sur la partie « Je dirai aussi que les trois premiers jours vont pouvoir faire émerger des problèmes auxquels il va être nécessaire de consacrer un temps plus long pour y répondre apportant plus de questions que de réponses. »
J’ai un peu l’impression que beaucoup de clients ou stakeholders attendent d’un design sprint des « solutions » alors qu’au final, bien souvent, l’exercice sert surtout à mettre le doigt sur différents problèmes (souvent organisationnels). Mais que c’est vendu aux clients comme « vous en faites pas en 5 jours on va trouver toutes les solutions et vous aurez un proto testé à la fin ». C’est vrai, après tout, leur vendre 5 jours de « alors en fait on va passer 5 jours à soulever des questions que vous aviez pas envie de soulever et on aura pas forcément de réponses à la fin » c’est un peu plus compliqué à vendre.
L’exercice reste interessant, mais j’ai peur qu’on en attende un peu « trop » en terme de solutions.
L’autre constat de mon côté c’est également l’enchainement des « design sprints » (qui n’en sont pas vraiment) chez certains clients car la notion de « sprint » est connue dans leurs équipes agiles. Du coup, certaines personnes semblent croire que le « design sprint » c’est juste un « sprint de design » et qu’on peut faire un design sprint chaque mois avant les sprints de dev. Il y a aussi du coup à mon avis une grosse confusion ici qui amène certaines entreprises à croire qu’il suffit de faire un design sprint avant un cycle de sprints de dev et pouf à la fin du design sprint on a toutes les maquettes testées et validées, y a plus qu’à développer.