Peut on améliorer l’XP d’un Design Sprint?
- Simplifier la création de la Map et du Storyboard -
(psst… I’ve also published an english version of this article)
Cela fait maintenant deux ans que je facilite des workshops de Design Sprints. Après chaque Sprint, j’ai pris l’habitude de dessiner une rapide Experience map du déroulé de la semaine.
Après tout, le Sprint est lui même une expérience. Comme pour tout design d’App ou de service , j’ai tâché d’identifier les “pain-points” que je rencontrais, afin de trouver des recettes pour mener des Sprints plus fluides et améliorer l’expérience de mes clients:) Je voulais partager avec vous quelques secrets:
La plupart de mes courbes d’expérience ressemblaient grosso-modo à ça:
Lundi est dur, car vous devez emmener toute l’équipe dans l’aventure.
Les attentes sont toujours immenses, en tant que Sprintmaster vous êtes clairement hors de votre zone de confort.
Mardi est plus simple pour moi; les lightning demos du matin sont toujours fun et inspirantes, le processus de sketching de l’après-midi est super intense et on ne voit pas le temps passer.
Mercredi matin est l’un de mes moments préférés sur le Sprint. Le processus de décision, fait des merveilles et l’équipe devient de plus en plus enthousiaste à la découverte des nouvelles idées. Cependant, le Storyboard de l’après-midi peut s’avérer quelque peu pénible (on en reparle toute à l’heure).
Jeudi c’est Prototype. Une grosse journée de boulot. Fatigante mais extrêmement gratifiante en tant que Designer UI. Si vous faites bien votre job, vous obtenez le fameux ‘Wow’ de la part du client.
Vendredi marque la fin du Sprint. Les Tests utilisateurs sont bien sûr stressants mais en même temps particulièrement excitants, la meilleure manière de terminer la semaine.
Sprint après sprint, j’ai réalisé que:
Deux temps sur le processus, semblaient un peu flottants et hors tempo:
Le lundi après-midi avec la création de la Map, et le mercredi après-midi lors du processus de Storyboarding (légère perte de motivation, pas de recette précise décrite dans le livre…).
Soyons clair; je tâche de rester aussi proche que possible du Sprint conceptualisé par GV, car je pense qu’ils ont visé juste à 99% dans le livre, mais au fil du temps, j’ai trouvé quelques petits trucs qui m’ont permis de fixer ces deux pain-points récurrents et de mener de meilleurs Sprints:
Créer la Map pas à pas
Le principe de la Map est excellent. J’ai cependant dû recourir à ce processus dès mes premiers Sprints car créer cette “Carte” (le parcours des utilisateurs ou la manière dont le service fonctionne) semblait toujours abstrait et posait problème à mes clients. Il manquait clairement une recette pas-à pas pour parvenir à la réaliser efficacement. Voici ce que je fais:
1. Quick personas: Il s’agit d’un exercise individuel de 10 minutes, je donne un canvas sur feuille A4 à chaque participant et leur dit, “A votre avis, qui est l’utilisateur typique de votre produit?” (par exemple l’utilisateur qui sera OK de payer pour utiliser la solution que nous sommes en train de designer). Ce canvas que vous pouvez télécharger ici est une version rapide d’un template de 4-up persona, inspiré par Roman Pichler et Jess Eddy.
Après avoir créé son persona, chaque participant prend 2 minutes pour raconter son histoire (storytelling). L’équipe relève les éléments qui sonnent “juste”. Cet exercice étant réalisé individuellement, des éléments communs à tous vont immanquablement apparaître.
Nous consacrons ensuite 20 minutes pour créer un seul persona avec les meilleurs morceaux de chaque proposition. A ce stade pas besoin de rechercher la perfection; on tentera avant tout d’établir une compréhension commune de l’utilisateur cible avant de se plonger dans la création de la Map.
Dans certaines occasions, plusieurs types de personas très différents vont apparaître (par exemple docteurs et patients). Cela ne pose pas de problème à ce stade, puisque nous pouvons en représenter plusieurs sur la Map (Par la suite, on pourra, si il le faut, se consacrer spécifiquement sur une partie de l’expérience ou sur un persona spécifique. Ce choix s’effectue lors de la phase Pick the target).
2. Parcours utilisateurs individuels: Il s’agit d’un exercice de 15 minutes. Chacun reçois des post-its format horizontal. Je demande à chaque membre de l’équipe de réaliser un parcours utilisateur du persona (à partir de son problème initial jusqu’au but à atteindre, par exemple acheter un produit sur le site.). Au final cela ressemble à une timeline horizontale de 15 post-its; une action par post-it:
Chacun va ensuite coller sa timeline sur le mur, l’une au-dessus de l’autre afin de former une sorte de matrice.
L’équipe se rassemble devant le mur et chacun prend 2 minutes pour raconter son “histoire”, en deux minutes max.
Nous collons de petits stickers sur les étapes intéressantes. (Dès que tout le monde est passé, nous retirons les post-its sans stickers, afin de simplifier), cela permettra de fusionner les différentes histoires en une seule.
Cela peut paraître difficile, mais il n’en n’est rien car l’équipe s’était préalablement mise d’accord sur un but et un persona. Les histoires devraient en principe converger. Si le processus révèle de gros conflits, c’est le moment d’en discuter: vous venez probablement de mettre le doigt sur quelque chose d’important.
A ce stade, la Map commence à apparaître clairement. Nous trouvons des noms pour les étapes principales et sommes fin prêts à établir notre Map “GV style” sur le tableau blanc.
Cette Map est par la suite présentée aux experts et affinée. (Par la suite, j’ai réalisé que l’agence berlinoise AJ & Smart avaient conçu un processus très similaire pour la phase de Storyboarding, mais pour ma part, je préfère l’utiliser le premier jour. )
Un Storyboard tout en douceur
Cette séquence m’a pris plus longtemps à concevoir, car j’ai dû m’éloigner quelque peu de ce que propose GV. Mais je pense avoir trouvé quelque chose d’efficace, à vous de juger:
Je n’ai jamais été très à l’aise lors de la phase du Storyboard.
Imaginez: vous êtes en Jour 3, il fait super chaud dans la war room et l’excitation du vote du Décideur est derrière vous. Vous vous tenez face à un grand tableau blanc, l’équipe affalée sur leurs chaises vous regarde l’air un peu las, et vous leur annoncez que vous allez storyboarder toutes les phases de l’expérience ensemble.
Soyons clairs: je suis 100% certain que ce qui est décrit dans le livre fonctionne, mais tout dépend des aptitudes du Sprintmaster. Jake Knapp par exemple est un excellent dessinateur, j’imagine donc facilement une Sprint team pouvant être captivée le temps d’une après-midi, le voyant remplir des cases sur un tableau blanc (je le serais aussi). Cependant lorsque vous n’êtes pas Jake Knapp:
- a ce stade, l’équipe est en principe fatiguée
- le Storyboard s‘avère être un brin répétitif
- Certains membres de l‘équipe décrochent
- les box sont toujours trop petites et les feutres manquent de précision
- Est ce que j’ai dit qu’il faisait super chaud dans cette #@%* de salle?
Voici donc ma recette:
1. On revoit ensemble l’entier de la Map du jour 1 et on divise le Proto en 3 différentes sections.
2. On colle au dessus de la Map, les solutions “gagnantes” de la phase Decide (celles retenues par le Décideur), à l’emplacement où elles doivent apparaître de l’expérience:
3. Nous créons 3 équipes de 2 personnes. Chaque équipe est formée de la personne qui a réalisé la majorité des esquisses retenues pour cette section (ou celle qui connaît le mieux cette partie du business) ainsi qu’un “challenger.”
Je leur donne une pile de feuilles A4 et quelques instructions basiques sur comment dessiner un wireframe.
En principe, pour une App desktop ou un site web, on utilisera une page A4 par écran (En fait, la dimension physique est quasiment un format 15'’). Pour symboliser une vue scrollable, on scotche simplement plusieurs pages à la suite.
Les textes (titres, sous-titres) doivent être réels (éviter absolument le faux texte Lorem ipsum…)
4. Je règle le Time Timer sur une heure et demande à chaque équipe de réaliser de leur côté leur partie du prototype. Le fait qu’il soient seulement deux par équipe crée une saine “pression” ainsi qu’une certaine émulation entre les groupes. Tous se sentent utiles et contribuent volontiers à l’effort commun.
Au cours de cette heure, les trois groupes vont avancer de manière indépendante sur leur part du Proto. En tant que facilitateur, je saute de groupe en groupe, répondant aux questions et travaillant comme un “assembleur”. Ayant la vision globale de ce que font les groupes, je me charge en principe de la navigation générale.
5. Une heure plus tard, tout le monde se retrouve face à un mur et chaque groupe y colle ses planches. Nous passons rapidement à travers toutes les planches. A ce stade, nous sommes en mesure de prendre des décisions sur la cohérence de l’UI, le wording et de connecter les différentes parties du Proto. (J’ai tendance à surligner en jaune les boutons actifs et d’indiquer en petit avec une * l’endroit où ils sont sensés pointer).
6. J’ajoute 20 minutes sur le Time Timer et chaque groupe retourne à l’ouvrage (il reste toujours quelques petites choses à modifier).
7. Bip bip, le Time Timer sonne. Retour au mur et nous parcourons toutes les planches ensemble une dernière fois. En principe il est environ 16:30.
YES, les fondations pour la prochaine journée de Prototypage sont posées. Apéro.
L’entier de ce processus prend environ 2 heures et s’est révélé être très efficace. Chaque membre de l’équipe, s’occupe de storyboarder la partie de l’expérience lui tenant le plus à coeur. Chacun se sent impliqué jusqu’à la fin.
Que pensez-vous de ces petites libertés avec le Sprint? Avez-vous testé?
Je me réjouis de vous lire.
N’hésitez pas à commenter ou à me contacter si vous souhaitez discuter du Design Sprint en Europe. Je serai très heureux d’échanger avec vous.
Stéphane Cruchon est un consultant et enseignant en UI / UX Design (spécialiste du Design Sprint), vivant à Lausanne en Suisse.
