![](https://dev-api.wikihero.org/images/default-avatar/avatar.png)
Rendre les livrables actionnables
Je vais séparer deux types de livrables. Il y a les phases exploratoires et les phases plus évaluatives.
Sur les phases exploratoires:
- je pense que ce qui rend actionnable le livrable c'est principalement la manière dont il a été construit avec la personne qui va l'utiliser après.
En l'occurrence pour prendre l'exemple de comment nous travaillons aujourd’hui versus il y a un an c’est toutes les phases sont toujours faites à deux parce que c'est plus agréable, on réfléchit mieux, c'est soit du design, de la recherche, product.
Avant l'idée c'était de mettre deux personnes qui connaissent très bien leur discipline pour obtenir un résultat encore meilleur : deux researchers, deux PM] ...... deux designers
Et on s'est rendu compte que deux researchers, ils étaient à 8/10 de leurs capacités, ça ne faisait pas pour autant 16 ! Ils savaient un peu les mêmes choses, ils pouvaient s'aider, c'est toujours mieux de rebondir l'un avec l'autre mais en fait c'est plus utile d'avoir quelqu'un qui est "lead" et ensuite quelqu'un qui est impliqué mais pas lead, en l'occurrence un "pm” qui va récupérer ce qui s'est passé en explo pour l'utiliser derrière.
C'est le côté "transmission humaine", ça fait une bonne partie du travail pour bien réutiliser le livrable ensuite.
Maintenant ce n'est pas toujours possible et on obtient un livrable qui va devoir être utilisé et des détails qui vont devoir être transformés.
À ce moment-là, ce qui détermine la qualité c'est de se demander à quelle question on répond, de reprendre les objectifs produits de départ
Par exemple :
- "on veut améliorer la conversion entre telle et telle partie"
- "on sait qu'il y a tel problème", "c'est destiné à tel user"
- "on a besoin de comprendre ce qu’ils font à un moment donné
- "ceux qui convertissent, pourquoi ils convertissent", etc.
Une fois ces questions posées, et avec ce qu'on a appris, quelles sont les différentes réponses qu'on peut donner ?
Dans le travail "produit" ensuite on sera facilement capable de notifier que toutes les réponses ne répondent pas aux mêmes questions, que toutes les questions ne se valent pas puisqu'il y a des choses qui sont plus ou moins au début ou à la fin du flow.
Ça permet de faire un tri pour prioriser derrière. Une fois qu'on a l'organisation, il y a la qualité même des informations.
Il y a 2 choses :
1) Il faut donc avoir la capacité d'écrire quelque chose de précis.
Je ne suis évidemment pas parfait, mais je pense que j'ai amélioré cet aspect et j'estime qu'il faut y passer plus de temps.
Il faut se relire, se faire relire aussi, parce qu'évidemment on est toujours clair pour soi-même, mais ça ne veut pas dire qu'on est clair pour les autres.
Lorsqu'on présente les choses, si quelqu'un ne comprend pas, demander à l'autre ce qu'il a compris.
- Comment peut-on trouver une manière de réécrire les choses ensemble ? pour s’assurer que c’est clair.
- Si on énonce quelque chose qui n'est pas clair, il ne faut pas s'étonner après que le produit ne suive pas.
De la même manière si l'insight, il est compris de quatre manières différentes par quatre personnes différentes, il y a un moment où ça ne marchera pas.
Il faut s'appliquer pour écrire des choses qui sont claires, si on n’en est pas capable, faire un dessin, un miro...se débrouiller pour donner une représentation la plus proche de ce qu'on a appris à travers un langage écrit, imagé etc.;
La dernière chose c'est d'arriver à bien connecter ça avec la réalité de ce que le user nous a dit, pas de l'illustrer parce que c'est ce qui va incarner les choses.
Il y a le côté clarté et aussi le côté puissance de l'insight. Et la puissance elle naît de la vidéo, du verbatim qui montre que
“ Ah oui, ça c’est un truc super fort, où si l’on est capable de s’appuyer dessus, ca fera vraiment une différence “
Ou
“Si c’est un truc un peu cool, que tout le montre trouve intéressant, mais où l’on sait que demain cela ne fera pas de différence”
![](/_nuxt/img/866cb67.png)