Prototype fast, Test Fast — Julien Pelletier

Vincent Guilhermond
Yousign Engineering & Product

--

🎙 Lien audio conférence: Prototype fast, test fast.m4a

🎙 Lien audio Questions: Questions conférence.m4a

🍪 Recette de cookies & Product Design

“Ça, c’est une recette de cookie. Et comme n’importe quelle recette, Ce qu’on attend de vous, c’est assez simple vous allez prendre tous ces ingrédients dans un bol. Vous allez suivre les instructions qu’on vous présente. Et à la fin, si vous faites tout ça consciencieusement, vous arriverez à un résultat qui ressemble à ça.”

Si cela est vrai dans de nombreux domaines, Julien annonce la couleur :

“Le Product design n’est pas une recette de cuisine”

L’un des premiers points que Julien tient à aborder dans ses formations qu’il réalise chez The Design crew c’est que le Product design, n’est pas une recette de cuisine. Il explique qu’on ne va pas réussir à résoudre tous les problèmes auxquels ont va être confrontés simplement en suivant une liste d’ingrédients prédéfinis et en suivant des instructions.

Pour résoudre un problème, le meilleur chemin va parfois être de prototyper quelque chose rapidement pour pouvoir mesurer la data, pour voir comment ça se comporte. Dans d’autres cas, ça sera de se poser longuement avec ses utilisateurs pour essayer de comprendre leurs habitudes, leur quotidien, le stress, leur frustration.

La méthode Design sprint

Créée par les équipes de Google venture pour débloquer les équipes sur des problèmes produits, cette approche n’est pas toujours pertinente en startup selon Julien.

En effet, pour lui, la promesse du Design sprint est de résoudre des problèmes en 5 jours et c’est ce que votre équipe devrait faire en réalité continuellement

SPRINT — Jake knapp

“La méthode Design sprint je l’adore autant que je la déteste”

cette philosophie se traduit selon lui en premier lieu dans le recrutement de votre équipe.

L’importance du recrutement de son équipe

La recommandation de Julien est de privilégier le Mindset plutôt que les connaissances académiques :

  • Valoriser les profils qui veulent tester rapidement (plutôt que les profils “puits à connaissances” des méthodes théoriques)
  • Favoriser les personnes capables de trouver des raccourcis

Prototyper & Tester peut être fait de manière simple et rapide

Julien Pelletier nous donne à voir un extrait du film the Founder.

Dans cet extrait, nous voyons les frères McDonald (Dick et Mac) à la craie sur un terrain de sport pour imaginer l’organisation de la cuisine et la répartition des ilots et appareils qui vont s’y trouver.

C’est ensuite un jeu de rôle grandeur nature, où les personnes simulent les gestes liés à leur poste de travail.

Ce processus itératif permet de valider la meilleure disposition afin d’optimiser la circulation et l’efficacité dans la cuisine. Les frères McDonald ne mettent pas au point le système de cuisine le plus efficient du premier coup. Ils prototypent, testent et itèrent.

The FounderJohn Lee Hancock (2016)

🎁 Bonus: Lien vers un article (EN) de Megane Goodacre (shopify) sur la symphony de l’efficience : https://megangoodacre.com/Symphony-of-efficiency-1

Julien nous partage un autres exemple dans le domaine du jeu vidéo cette fois: Dans le cadre de la conception du jeu ZELDA — BREATH OF THE WILD.

Dans le but de tester un nouveau concept d’interactions entre différents éléments du jeu, les équipes ont utilisé des assets du premier Zelda (1986) sur NES pour prototyper et tester rapidement leurs idées et ainsi voir si les concepts fonctionnaient.

Prototype Nintendo “ Breath of the NES
Zelda — Breath of the Wild” — Nintendo (2017)

Ils n’ont ainsi pas eu à attendre de devoir développer des modèles 3D ou un moteur physique pour valider deux ou trois idées de gameplay pour le concept de : “Je tire une flèche dans du feu et ça embrase ce qu’il y a derrière”. Une approche assez maligne de tester et valider ou non un concept.

🎁 Bonus: vidéo youtube détaillée sur ce processus de test via Breath of the NES”

Les meilleures équipes sont celles qui vont rapidement tester les idées et définir lesquelles sont intéressantes à développer ou pas. “

— Marty Cagan

Avant The Design Crew, Julien était lead design chez Heetch. Dans son équipe, ils étaient capables de tester des idées plusieurs fois par semaine et leurs itérations n’étaient pas très longues. Pour faire ça, ils se sont basés sur deux piliers :

  1. Figma (prototyping feature)

Un outil qui permet de concevoir facilement un prototype en créant des liens entre différents écrans.

2. Les Guerilla tests

Test rapide sans réel protocole pour avoir des retours rapides sur une proposition.

ex : Aller dans un Starbuck et demander à quelqu’un si vous pouvez lui prendre un peu de son temps pour pouvoir tester les projets sur lesquels vous travaillez.

Le prototypage rapide a cependant des limites et Julien explique que cette approche peut vous amener a être confronté à plusieurs raisons de varier le format de vos tests et à vous adapter en fonction de votre sujet :

💁‍♂️ Le prototype basse fidélité à des limites

Parfois difficile pour les utilisateurs de se projeter et peut leur demander beaucoup d’imagination.

👫 La représentativité de vos utilisateurs

Un Guerilla test ne vous permet pas de cibler vos utilisateurs et ils ne sont probablement pas de véritables utilisateurs de votre solution (d’autant plus en BtoB).

⚔️ Réel usage VS usage pendant un test

Les tests amènent un biais dans l’usage de votre solution, se sentant observés les utilisateurs auront un comportement moins naturel que ce qu’ils feraient si vous n’étiez pas là.

Le prototype basse fidélité a des limites

Il est parfois difficile pour les utilisateurs de se projeter et cet exercice peut leurs demander beaucoup d’imagination. Julien nous présente quelques outils utilisés chez Heetch pour rendre le prototype plus réaliste et aider les utilisateurs à ce projeter au mieux dans votre solution :

Origami

Un outil de prototypage avancé (high-fidelity) permettant d’animer vos écrans et de les rendre très proches du réel grâce à l’intégration de fonctionnalités telles que l’utilisation d’API ou encore des capteurs de votre smartphone, par exemple :

  • Caméra
  • GPS
  • Microphone
  • Saisie du clavier
  • -…

Ces outils sont plus complexes et demandent bien plus de temps de préparation qu’un simple prototype fait sur Figma.

🎁 Bonus: dans le même style d’outil de prototypage high-Fidelity : protopie / Bravo studio / …

La représentativité de vos utilisateurs

Un Guerilla test ne vous permet pas de cibler vos utilisateurs et ils ne sont probablement pas de véritables utilisateurs de votre solution.

Les gens que vous allez voir en guérilla test ne seront pas toujours pertinents. Fort de ce constat et de cet écart avec leur utilisateur chez Heetch, Julien et son équipe se sont orientés vers d’autres mode de testing.

Remote testing :

  • Lien Figma avec un partage d’écran via une visio
  • Maze (parcours figma encapsulé avec des consignes)

Maze

Maze est un outil pour gérer et diffuser vos tests en ligne à partir d’un prototype Figma (ou autres) encapsulé dans leur solution de test en ligne.

Maze permet de diffuser massivement votre test et de récolter de la data sur les hypothèses validées ou non.

👉 Note : Cette approche de testing permet de faire une étude quantitative plus facilement car il s’agit d’un lien a partager.

En revanche, il faut noter qu’il peut manquer l’aspect communication (non-)verbale car le test se fait en autonomie, contrairement à un test 1:1 ou Guerrilla testing où l’on peut observer les réactions des utilisateurs.

Réel usage VS Usage pendant un test

Parfois la réponse est dans la data et pas dans les résultats de vos tests. En effet, les utilisateurs ne se comportent pas comme ils feraient dans leur quotidien dans le cadre de votre échange.

C’est ce qu’on appel l’Effet Hawthorne :

Il décrit la situation dans laquelle les résultats d’une expérience ne sont pas dus aux facteurs expérimentaux mais au fait que les sujets ont conscience de participer à une expérience dans laquelle ils sont testés, ce qui se traduit généralement par une plus grande motivation et vient donc biaiser vos tests car le comportement n’est pas celui qu’il aurait sans votre présence.

Pour contourner ce biais, il est possible de mettre en place un prototype codé et intégré dans la solution pour quelques jours. Une sorte de code jetable non optimisé qui aura pour but d’uniquement récolter de la data sur quelques jours et qui sera ensuite supprimé.

👉 Note : Cette approche prend encore plus de temps que le Guerilla test ou le prototype réalisé sous origami et demande l’implication de votre équipe Devs

Conseils

Julien nous apporte quelques conseils et recommandations pour optimiser son processus de prototypage et de test.

💪 Intégrer un Profil Design OPS

Un profil qui s’assure de mettre en place des bonnes pratiques pour augmenter la vélocité de l’équipe sur les étapes de prototypage et de test.

📋 Chercher à templatiser

pour optimiser le processus de recrutement des utilisateurs et gagner du temps en interne.

🤝 Entretenir les relation avec les autres équipes:

-Équipe Devs (leur parler du prototype codé et de l’approche « code jettable »)

-Équipe CRM (initier au démarches prototypage et des tests utilisateurs)

📌 En résumé, il est important avant de se lancer dans le prototypage et les tests, de bien définir ce qu’on cherche à confirmer lors de ces sessions utilisateurs. C’est sans doute le meilleur moyen de choisir la manière de concevoir votre prototype et également la meilleure manière de définir comment vous allez le mettre dans la main de vos utilisateurs.

Croquis-Prise de note de LPC 2022 par @Antoine Visonneau

--

--