Product Designer : conseils pour être efficace et pertinent lors d’un Design Sprint (2/2)

Lundi : "comprendre"

C’est la journée où la charge cognitive est la plus importante : on emmagasine beaucoup d’informations qui nous permettront d’alimenter notre réflexion tout le long du Sprint.

Chez SQLI, un atelier de cadrage du problème est réalisé quelques jours avant le Sprint. Lors de cette première rencontre, l’équipe de sprinters partage les premiers éléments de connaissance et formule un premier énoncé du problème. C’est l’occasion pour le designer de dissiper le brouillard dans lequel il s’est embarqué !

 

Poser des questions pour bien comprendre le contexte et la problématique

Quand c’est un sujet que l’on ne connaît pas, nous avons très peu de temps pour comprendre le contexte, les enjeux et surtout le vocabulaire. Il ne faut pas hésiter à poser des questions et demander d’expliciter les termes afin d’être pertinent dans les ateliers et dans l’esquisse de solution par la suite.

"Celui qui pose une question risque cinq minutes d'avoir l'air bête, celui qui ne pose pas de question restera bête toute sa vie" Confucius

 

Relever des mots clés

Une bonne partie du premier jour est consacrée à des interviews “d’experts” externes au Sprint mais dont on estime que les informations qu’ils peuvent fournir aux sprinters vont leur permettre de mieux comprendre les besoins des utilisateurs, les enjeux business et le champ des possibles (réglementaires, techniques…) pour ainsi nourrir la réflexion des sprinters et augmenter les chances d’être pertinents dans l’exécution de leur mission.

Lors de ces interviews, chaque sprinter se doit de prendre des notes. Difficile de faire confiance à sa mémoire à court terme vu la quantité d’informations que nous ingérons le lundi. Je vous conseille de relever des mots récurrents dans les conversations avec les experts et qui vous paraissent clés. Ils pourront vous aider à construire les challenges “Comment pourrions-nous ?” et les “Jobs-to-be-done”.

CPN, “Comment pourrions-nous ?” (“How might we” en anglais) sont des questions qui reformulent les problèmes en opportunités afin de faciliter l’idéation.

JTBD, Job-to-be-done est une théorie dont l’objectif est de formuler un énoncé clair des motivations intrinsèques des utilisateurs (émotionnels, sociaux, fonctionnels), des résultats attendus (job) et des difficultés qu’ils éprouvent à les obtenir (Théorie poussée par Tony Ulwic (inventeur de l’Outcome Driven Innovation). Cette théorie n’est pas du tout utilisée par Jake Knapp mais SQLI l’a intégrée dans le process car nous partageons avec Clay la conviction suivante : “Innovation becomes much more predictable — and far more profitable — when it begins with a deep understanding of the job the customer is trying to get done.”(Livre : Competing against luck. Pour en savoir plus sur les JTBD, voilà une excellente vidéo de Clay Christensen : https://www.youtube.com/watch?v=kGuSM3yUxik)

 

Rappeler que l'interface conçue sera évidemment ergonomique

Les mots “ergonomique”, “fluide” et “agréable” n’amènent que des formulations bateaux qui pourraient s’appliquer à n’importe quel projet de design.

Exemple : “CPN imaginer une expérience plus fluide ?” “CPN concevoir une interface ergonomique ?” “CPN faire vivre une expérience agréable ?”.

Pour éviter des CPN non-pertinents, il ne faut pas hésiter à rappeler aux sprinters que le rôle du designer est de concevoir une expérience ergonomique, fluide et agréable ! Vous pouvez donc simplement proposer au facilitateur de préciser lors de la consigne de bannir ces mots de la formulation des CPN. Cela incitera ainsi les participants à être plus spécifiques dans l’énoncé des challenges et donner des CPN beaucoup plus inspirants.

Exemple : “Comment pourrions-nous aider les enseignants à mieux préparer leurs cours ?” “Comment pourrions-nous rassurer sur les questions d’hygiène et de sécurité ?” “Comment pourrions-nous rassurer l’utilisateur sur l’utilisation de ses données personnelles ?”

 

Mardi : "esquisser"

Le mardi est la journée la plus dense en travail individuel. Chaque sprinteur doit imaginer et dessiner sa solution en s’appuyant sur toutes les informations récoltées jusque-là. En tant que designer, c’est le moment de mettre toute notre richesse, acquise lors de précédents travaux et par notre veille, au service de l’équipe et du sprint, et parfois même de sauver la phase d’idéation.

Être force de propositions sur des références différentes

Les sprinters ont parfois du mal à sortir de leurs outils de travail et de leur zone de confort pour faire un benchmark intéressant. Je vous conseille de proposer des références visuelles différentes du contexte du produit en question, cela permettra de stimuler la créativité de l’équipe et, avec un peu de chance, de leur faire imaginer des solutions plus variées et innovantes lors du sketching de l’après-midi !

Préparer un dossier de veille à l'avance 

Si vous avez du mal à vous rappeler tout ce que vous avez pu voir dans les outils, vous pouvez vous préparer en avance un dossier avec des captures d’écrans de différents outils. Au moment du benchmark vous pourrez les parcourir et proposer uniquement les plus pertinents par rapport au contexte. Vous pouvez vous appuyer sur les services que vous utilisez quotidiennement pour le benchmark : design, streaming vidéo, services Google, boutiques en ligne, réseaux sociaux, gestionnaires de tâches, banques, musique, santé, réservation et tchat. Il y aura toujours une idée à transposer pour résoudre une problématique du sprint !

 

Mercredi : "décider / storyboard"

C’est la journée pour converger vers une solution et commencer à la détailler.

Canaliser le groupe

De concert avec le facilitateur, il faut canaliser le groupe dans la conception du storyboard pour éviter d’altérer le concept et le parcours de test sélectionné. La tentation est grande de vouloir changer plein de choses mais il faut garder l’objectif du sprint en tête et nul besoin que tout soit parfait !

Storyboard sur MIRO

En distanciel, Miro ou Mural sont utilisés pour les ateliers collaboratifs du Design Sprint. Les sprinters peuvent discuter et itérer rapidement autour du storyboard directement dans la fenêtre de leur navigateur. Tout le monde a ainsi une vision d’ensemble du contenu défini et de la charge de travail.

Dès que le concept et le parcours de test sont actés, je m’attèle à matérialiser succinctement le storyboard retenu sur Miro à l’aide des composants à disposition dans la “wireframe library”. Cela permet d’avoir une base propre et confortable pour échanger avec les sprinters. Personnellement j’essaye de ne pas y passer plus d’une heure et pour gagner en agilité je sors en avance les composants dont j’ai besoin. Vous pouvez toujours vous entraîner en amont pour prendre en main l’outil que vous aurez choisi.

Ensuite avec les sprinters et le facilitateur on rentre en détail dans le storyboard pour définir quel type de contenu on met dans les écrans. Par “type de contenu” j’entends par exemple “Date” ou “Nom du transport” : ça sera ensuite aux sprinters de définir en fonction des scénarios de test s’ils mettent le 16/03/2021 ou le 17/03/2021. On peut aussi partir sur quelque chose de plus large, “dans cet encart il faut les informations clients”, et ça sera aux Sprinters de définir les informations pertinentes à afficher pour l’utilisateur.

Être vigilant sur les scénarios de tests

À la suite du parcours de test, il faut définir les scénarios de test. Les sprinters peuvent mettre du temps à se mettre d’accord sur les scénarios à tester et ne pas être conscients de la charge de travail que cela implique pour le designer ensuite.

Mettre des Post-it pour les textes à fournir

N’hésitez pas à mettre des post-it partout où il y a des textes à fournir afin d’évaluer la quantité de contenu à produire. Cela permettra aux sprinteurs (avec l’aide du facilitateur) de se les répartir pour avancer efficacement. Le designer ne doit pas perdre de temps à réfléchir au contenu le jeudi : il faut compter sur les autres sprinters pour l’alimenter efficacement.

Définir le meilleur outil pour prototyper

Ce n’est qu’après avoir évalué le type de prototype à produire, sans oublier les contraintes énoncées ultérieurement, que nous pouvons choisir l’outil adéquat. Dans tous les cas, il faut choisir un outil que l’on maîtrise : ce n’est pas le moment de tester un nouvel outil !

Faire un premier jet du prototype

A la fin de la journée je commence à poser rapidement le storyboard sur mon logiciel de prototypage. En effet même si on pense n’avoir laissé aucune question ouverte à l’issue du Storyboard, c’est en réalisant concrètement le prototype que l’on va soulever de nouvelles questions difficilement identifiables en amont. Ces questions pourront être vite résolues avec l’équipe dès le jeudi matin.

 

Jeudi : "Proto"

C’est LE jour du designer, c’est le moment pour briller ! En anticipant cette journée grâce à plusieurs astuces, on peut facilement dérisquer le prototypage.

Points d'avancement / processus de communication

Définissez en amont avec le facilitateur le processus de communication de cette journée pour limiter les interruptions inutiles. Le designer se doit d’être dans des conditions de travail optimales : il faut préserver sa concentration et par conséquent sa productivité. Au cours de la journée, 2 ou 3 points peuvent être organisés pour présenter l’avancée du travail de conception aux équipes et relever les modifications.

Personnellement avec le remote, je me base essentiellement sur le board qui est alimenté en continu par les sprinters en restant focus dans mon coin. S’il me manque quelque chose je le note avec un post-it sur le board Miro, et je vais solliciter les sprinters sur la vidéoconférence en dehors des points si c’est urgent.

Se concentrer sur l'UX

C’est probablement ce qu’il y a de plus important à garder en tête. L’objectif est de réaliser un support pour tester la proposition de valeur : ce n’est pas le moment de révolutionner la roue. On ne peut pas faire du « pixel perfect » ou vouloir revenir plusieurs fois sur quelque chose qui ne nous satisfait pas pleinement. L’UI n’est là que pour servir l’UX.

Prioriser les écrans 

Échangez avec le facilitateur et le décideur pour définir les écrans qui sont “mandatory” et ceux qui sont “nice to have”, l’objectif étant de canaliser les efforts de l’équipe au bon endroit en priorité et de sécuriser le sprint.

Refuser les modifications importantes

Certains sprinters pourraient vouloir revenir sur des éléments du prototype. Il faut savoir évaluer le coût/valeur/risque de ces demandes et surtout savoir dire non pour ne pas mettre en péril le prototype et donc le sprint ! Une bonne façon de trancher et de se poser la question : “A-t-on besoin de tester cette fonctionnalité pour répondre aux Sprint Questions ?” Si la réponse est “non”, alors vous pouvez facilement expliquer que cela pourra être fait après le Sprint si besoin.

Faire des pauses

Ça parait évident, mais dans le feu de l’action du jeudi on aura tendance à l’oublier. Quand le cerveau surchauffe il devient difficile d’avancer efficacement et on fait plus facilement des erreurs.

Des Post-it de différentes couleurs pour le contenu

J’utilise un code couleurs pour les post-its des textes à fournir afin d’avoir et de donner une vision globale de l’avancement et de ce qu’il manque.

Penser au User Researcher

Chez SQLI, le senior user researcher intervient le jeudi pour assurer l’objectivité et la maîtrise de l’exercice. Il doit prendre connaissance du sujet du sprint, du prototype afin de construire le guide d’entretien et de la grille d’évaluation pour le vendredi matin. J’essaye d’avoir rapidement une ébauche de tous les écrans du prototype afin que le user researcher ait de la matière pour avancer.

 

Vendredi : "Test"

Partager les améliorations à apporter à toute l'équipe

A la fin du sprint, après les tests utilisateurs, nous aimons prendre le temps de partager les ressentis de chacun, synthétiser les grands enseignements et identifier les actions prioritaires à mener post-sprint.  En tant que designers, nous pouvons voir des choses que les autres participants n’auraient pas vu et il ne faut surtout pas s’empêcher de le partager. On finit ainsi tous le sprint avec le même niveau d’information.

Conclusion

Chaque design sprint est une aventure enrichissante qui mérite d’être expérimentée. Personnellement j’ai une grande appétence pour le challenge et apprendre de nouvelles choses, le design sprint est donc le parfait terrain de jeu ! J’espère que ces conseils vous aideront à préparer au mieux votre participation à un Design Sprint, ou vous motiveront à en faire ! Si vous avez des questions, n’hésitez pas à les poser en commentaire.

Illustrations de undraw.co