Ma méthode de travail, de la première question à la mise en production

Pourquoi je m'en tiens à une méthode

J'ai travaillé en agence, en startup et au sein d'équipes produit installées. Les contextes changent, les budgets aussi, mais les projets qui se passent mal ont presque toujours le même défaut : on a commencé à dessiner avant de savoir ce qu'on cherchait à résoudre.

Ma méthode tient en quatre temps : discovery, cadrage, design, développement. Rien d'original dans les mots. Ce qui compte, c'est ce que je refuse de sauter, et le fait que je reste présent du premier au dernier.

1. Discovery : comprendre avant de dessiner

La discovery sert à répondre à une question simple : quel est le vrai problème, et pour qui ?

Je m'appuie sur trois choses.

Les entretiens utilisateurs. Je parle aux personnes qui utiliseront le produit avant d'ouvrir Figma. Pas pour leur demander ce qu'elles veulent, mais pour comprendre comment elles travaillent aujourd'hui, avec quels outils, et où elles perdent du temps. Chez Nanotera, c'est ce travail qui a montré que le sujet n'était pas d'ajouter des fonctions, mais de réunir des outils éparpillés entre le siège et les magasins.

Le benchmark concurrentiel. Je regarde ce que font les concurrents directs, et aussi les produits d'autres secteurs qui ont résolu un problème voisin. Un benchmark ne sert pas à copier. Il sert à savoir ce que les utilisateurs connaissent déjà, donc ce qu'ils s'attendent à trouver.

Les ateliers avec le client. Un atelier met autour de la table les personnes qui décident et celles qui connaissent le terrain. C'est souvent là que sortent les contraintes qui ne figurent dans aucun brief : une dépendance technique, un engagement commercial, une équipe qu'il ne faut pas oublier.

À la fin de cette phase, je dois pouvoir formuler le problème en quelques phrases que tout le monde valide. Si ce n'est pas possible, la discovery n'est pas terminée.

2. Cadrage : décider ce qu'on fait, et ce qu'on ne fait pas

Une discovery bien menée produit toujours plus d'idées que de temps pour les réaliser. Le cadrage sert à choisir.

J'utilise deux outils, selon le contexte.

MoSCoW pour les échanges avec un client ou une direction : ce qui est indispensable, ce qui est important, ce qui serait un plus, ce qu'on ne fera pas cette fois. La dernière catégorie est la plus utile. Écrire noir sur blanc ce qui est hors périmètre évite la plupart des malentendus.

RICE quand il faut départager des fonctions entre elles : combien de personnes sont concernées, quel effet sur elles, quel niveau de confiance dans l'estimation, quel effort. Le chiffre final compte moins que la discussion qu'il provoque. Quand deux personnes ne sont pas d'accord sur l'effet attendu d'une fonction, on vient de trouver une hypothèse à vérifier.

C'est ici que la double casquette sert le plus. Un designer seul a tendance à défendre la meilleure expérience. Un product manager seul a tendance à défendre le périmètre. En portant les deux rôles, je fais l'arbitrage au moment où je conçois, pas trois semaines plus tard en comité.

Le cadrage se termine par un périmètre écrit, des priorités, et une idée claire de ce qui prouvera que le projet a réussi.

3. Design : construire un système, pas une suite d'écrans

Je ne commence jamais par une page. Je commence par les fondations : les couleurs, les styles de texte, les espacements, posés en variables. Viennent ensuite les composants, puis seulement les écrans, assemblés à partir de ces composants.

Cette discipline a un coût au départ et un bénéfice tout le reste du projet. Quand une couleur change, elle change partout. Quand un composant évolue, toutes les pages suivent. Et surtout, ce que je livre ressemble déjà à la structure que les développeurs vont écrire.

Pendant cette phase, je fais valider souvent et par petits morceaux. D'abord les parcours en fil de fer, pour parler de logique et non de goût. Puis un prototype, pour faire tester les parcours clés avant qu'une seule ligne de code soit écrite. Une erreur repérée sur un prototype coûte une heure. La même erreur repérée après le développement coûte une semaine.

Chez Adcleek, c'est cette approche qui a permis de rendre accessible la commande de campagnes à des personnes qui ne sont pas des spécialistes du marketing digital. L'interface a été pensée pour guider et expliquer à chaque étape, et ce choix n'aurait pas tenu sans composants cohérents d'un écran à l'autre.

4. Développement : rester jusqu'au bout

Beaucoup de designers considèrent que leur travail s'arrête à la livraison des maquettes. Pour moi, c'est là que commence la partie la plus décisive.

Je travaille avec les développeurs, pas avant eux. Chez Adcleek, je participais aux sessions de planning poker et aux discussions techniques. Comprendre pourquoi une fonction coûte cher à développer permet souvent de trouver une variante presque aussi bonne pour l'utilisateur et deux fois plus simple à construire.

Je documente ce que je livre. Un composant sans règles d'usage sera mal utilisé. Je décris les états, les cas limites, ce qui se passe quand un texte est trop long ou qu'une donnée manque.

Je fais la recette. Je compare ce qui a été développé à ce qui a été conçu, écran par écran, et je corrige les écarts avec l'équipe. Chez Nanotera, ce suivi jusqu'à la mise en production faisait pleinement partie de mon rôle.

Sur Xola, je travaillais avec un CTO basé aux États-Unis et des équipes de développement situées en Inde. À cette distance, la proximité ne tient pas à la présence physique. Elle tient à la clarté de ce qu'on transmet et à la régularité des échanges.

Ce que la double casquette change vraiment

Avoir les deux rôles ne veut pas dire faire deux métiers à moitié. Cela veut dire que chaque décision de design est prise en connaissant son coût, sa priorité et son effet attendu sur le produit.

Concrètement, cela donne trois choses :

• des maquettes qui tiennent compte du périmètre réel, donc moins de fonctions dessinées puis abandonnées ;
• des arbitrages plus rapides, parce que la personne qui conçoit est aussi celle qui sait ce qui compte le plus ;
• une continuité entre l'intention de départ et le produit livré, parce que la même personne suit les deux.

Comment j'adapte la méthode au contexte

Les quatre temps restent les mêmes partout. Ce qui change, c'est leur poids.

En startup, le temps manque et les certitudes aussi. La discovery est courte et ciblée : quelques entretiens bien choisis valent mieux qu'une étude complète qui arrive trop tard. Le cadrage est impitoyable, parce que chaque fonction en trop retarde le moment où le produit rencontre ses utilisateurs. Inspy, que j'ai conçu comme un projet d'étude avant qu'il ne devienne un projet entrepreneurial, m'a appris cela : une vision claire et un périmètre serré convainquent mieux qu'une liste de fonctions.

En agence, le client n'est pas toujours l'utilisateur. Les ateliers prennent une place centrale, parce qu'il faut aligner des personnes qui n'ont pas les mêmes attentes avant de produire quoi que ce soit. La documentation compte double : l'équipe qui maintiendra le produit n'est souvent pas celle qui l'a conçu.

Dans une équipe produit installée, le produit existe déjà et il a des utilisateurs. La discovery s'appuie sur les données d'usage autant que sur les entretiens. Le design doit composer avec l'existant, et le développement devient un dialogue permanent plutôt qu'une livraison. Sur Xola, déjà utilisé par une large base d'utilisateurs, il fallait moderniser les parcours sans casser les habitudes : c'est une contrainte que seule une connaissance fine de l'existant permet de tenir.

Dans les trois cas, l'ordre ne change pas. Comprendre, choisir, concevoir, accompagner. Inverser deux étapes coûte toujours plus cher que d'en raccourcir une.

Ce que cette méthode évite

Je la décris souvent par ce qu'elle produit. Elle vaut aussi par les problèmes qu'elle empêche.

• La fonction que personne n'utilise. Elle naît presque toujours d'une idée jamais confrontée à un utilisateur. La discovery sert à cela.
• Le projet qui n'en finit pas. Il vient d'un périmètre resté flou. Un cadrage écrit, avec une liste de ce qu'on ne fera pas, donne un point d'arrêt.
• L'écart entre la maquette et le produit. Il apparaît quand le designer disparaît après la livraison. La recette le referme.
• Le produit qui se dégrade à chaque évolution. Il manque un système. Des variables et des composants le protègent.

Aucun de ces problèmes n'est un problème de talent. Ce sont des problèmes d'ordre et de suivi.

Les trois règles que je ne négocie pas

1. Pas de maquette avant d'avoir formulé le problème. Si personne ne peut dire en deux phrases ce qu'on cherche à résoudre, on n'est pas prêt à dessiner.
2. Pas de livraison sans composants ni variables. Une maquette qui ne peut pas être maintenue n'est pas terminée.
3. Pas de projet abandonné à la livraison des maquettes. Le résultat se juge en production, pas dans Figma.

En résumé

• Discovery : Quel est le vrai problème, et pour qui ? — Entretiens, benchmark, ateliers, problème formulé
• Cadrage : Que fait-on, et que ne fait-on pas ? — Périmètre, priorités (MoSCoW, RICE), critères de réussite
• Design : Comment le résoudre de façon cohérente ? — Variables, composants, parcours, prototype testé
• Développement : Ce qui est livré correspond-il à ce qui était prévu ? — Documentation, échanges avec les développeurs, recette

Écouter, comprendre, décider, livrer : c'est la version courte. Les quatre temps en sont la version praticable.