Les questions à poser avant d'ouvrir Figma

Pourquoi une liste plutôt que de l'intuition

J'ai déjà expliqué ma règle : pas de maquette avant d'avoir formulé le problème. Reste à savoir comment on y arrive. Avec l'expérience, on croit pouvoir s'en passer. On reconnaît un type de projet, on devine la demande, on commence à dessiner. C'est précisément là que les erreurs coûteuses apparaissent, parce que chaque projet ressemble aux précédents jusqu'au moment où il ne leur ressemble plus.

Une liste écrite a deux avantages. Elle évite d'oublier une question par excès de confiance. Et elle rend visibles les réponses manquantes : une case vide se remarque, une intuition floue non.

Je range mes questions en six familles.

1. Le problème

• Que se passe-t-il aujourd'hui, concrètement ? Pas la solution souhaitée, mais la situation actuelle : qui fait quoi, avec quel outil, et où ça coince.
• Qu'est-ce qui déclenche le projet maintenant ? Une plainte récurrente, une perte de clients, une nouvelle offre, une décision de la direction. Le déclencheur dit souvent plus que le brief.
• Que se passe-t-il si on ne fait rien ? Si la réponse est « pas grand-chose », le projet n'est peut-être pas prioritaire.
• La demande porte-t-elle sur un problème ou sur une solution ? « Il nous faut un tableau de bord » est une solution. Le problème est peut-être que les responsables ne savent pas où en sont leurs opérations.

Chez Nanotera, ce sont les entretiens sur la situation réelle qui ont déplacé le sujet : il ne s'agissait pas d'ajouter des fonctions, mais de réunir des outils éparpillés entre le siège et les magasins.

2. Les utilisateurs

• Qui utilise le produit, et qui décide de l'acheter ? Ce ne sont pas toujours les mêmes personnes, et leurs attentes peuvent s'opposer.
• Quel est leur niveau de familiarité avec le sujet ? Un spécialiste veut aller vite. Un non-spécialiste veut être guidé. Chez Adcleek, concevoir pour des personnes qui ne sont pas des spécialistes du marketing digital a orienté tout le reste.
• Dans quelles conditions utilisent-ils le produit ? Au bureau, sur le terrain, sur mobile, pressés, interrompus. Sur Xola, les parcours devaient fonctionner sur ordinateur, mobile, tablette et bornes en magasin.
• Qu'est-ce qui les freine ? Pas seulement ce qui les gêne dans l'interface, mais ce qui les retient d'agir. Sur Opt Health, les freins étaient la gêne, la peur du jugement et la crainte d'un service peu sérieux. Ils ont servi de grille de lecture pour chaque décision.

3. L'existant

• Le produit existe-t-il déjà, et qui l'utilise ? Une refonte n'a pas les mêmes contraintes qu'une création. Des habitudes installées ne se cassent pas sans raison.
• Quelles données sont disponibles ? Statistiques d'usage, demandes au support, retours des équipes commerciales. Ce qui existe déjà évite de refaire une recherche.
• Qu'est-ce qui a déjà été essayé ? Une idée abandonnée il y a deux ans l'a souvent été pour une raison qu'il vaut mieux connaître.
• Y a-t-il un design system, même partiel ? Il détermine si je compose avec l'existant ou si je pose des fondations.

4. Les contraintes

• Quelle est l'échéance, et est-elle ferme ? Un salon, un contrat, une campagne. Une date ferme change la façon de découper le travail.
• Quelles sont les limites techniques connues ? Une interface à brancher, un outil tiers imposé, une technologie déjà en place.
• Qui développe, et avec quelle capacité ? Une équipe interne disponible, un prestataire, une équipe à distance. Cela change le niveau de détail à livrer.
• Y a-t-il des contraintes réglementaires ou de marque ? Données personnelles, secteur de la santé, charte graphique imposée.

5. La réussite

• À quoi saura-t-on que le projet a réussi ? Une phrase observable : moins d'abandons à une étape, moins de demandes au support, une opération menée sans aide.
• Qui jugera cette réussite ? Si c'est la direction commerciale, il faut connaître ses critères avant de concevoir, pas après.
• Qu'est-ce qui serait un échec, même si tout est livré à temps ? Cette question fait souvent émerger l'enjeu réel.

6. Le périmètre et les décisions

• Qu'est-ce qui est hors périmètre ? C'est la question la plus utile de la liste, et la moins posée.
• Qui valide, et à quelles étapes ? Savoir qui a le dernier mot évite de refaire une série d'écrans validée par la mauvaise personne.
• Que garde-t-on, que jette-t-on ? Sur une refonte, certaines parties doivent rester intactes. Il vaut mieux le savoir avant de les dessiner à nouveau.

À qui poser ces questions

Aucune personne ne détient toutes les réponses. Je répartis donc les questions.

1. Au commanditaire : le déclencheur, l'échéance, les critères de réussite, le périmètre, les validations.
2. Aux utilisateurs : la situation actuelle, les conditions d'usage, les freins. Je ne leur demande pas ce qu'ils veulent. Je leur demande de me montrer comment ils font.
3. Aux développeurs : les limites techniques, la capacité, ce qui a déjà été tenté.
4. Aux équipes au contact des clients : le support, les commerciaux, l'accompagnement. Elles entendent chaque jour ce que les utilisateurs ne disent jamais en entretien.

Quand deux personnes donnent des réponses différentes à la même question, je ne tranche pas seul. Je note l'écart et je le remonte. Un désaccord découvert avant le design coûte une réunion. Découvert après, il coûte une refonte.

Comment je pose les questions

Quelques règles simples rendent les réponses beaucoup plus utiles.

• Demander des exemples, pas des généralités. « Racontez-moi la dernière fois que c'est arrivé » donne des faits. « En général, comment ça se passe ? » donne des opinions.
• Reformuler à voix haute. Répéter ce que j'ai compris permet à l'autre de corriger tout de suite.
• Demander pourquoi, plusieurs fois. La première réponse est souvent la solution qu'on a en tête. Le vrai problème vient deux ou trois « pourquoi » plus loin.
• Accepter le « je ne sais pas ». Une réponse inconnue n'est pas un échec. C'est une hypothèse à vérifier, que j'écris comme telle.

Ce que j'en fais : une page, pas un dossier

Toutes ces réponses tiennent sur une page. Pas plus. Elle contient :

1. le problème, en deux phrases ;
2. les utilisateurs principaux et leurs conditions d'usage ;
3. les contraintes fermes ;
4. le critère de réussite ;
5. ce qui est hors périmètre ;
6. les hypothèses non vérifiées, listées à part.

Je fais valider cette page par le commanditaire avant d'ouvrir Figma. C'est court à relire, donc elle est vraiment lue. Et quand un débat revient trois semaines plus tard, c'est vers elle qu'on se tourne.

Les signes qu'il est trop tôt pour dessiner

Je ne commence pas tant qu'un de ces signes persiste :

• personne ne sait dire ce qui changera pour l'utilisateur ;
• le critère de réussite est « que ce soit plus moderne » ;
• deux décideurs donnent des objectifs différents ;
• la liste de ce qui est hors périmètre est vide ;
• je n'ai parlé à aucun utilisateur, ni à personne qui leur parle.

À l'inverse, je n'attends pas d'avoir toutes les réponses. Certaines ne viendront qu'en testant un premier parcours. L'objectif n'est pas de tout savoir, mais de savoir ce qu'on ne sait pas encore.

En résumé

Les questions ne ralentissent pas un projet. Elles déplacent le temps de réflexion au moment où il coûte le moins cher. Avant d'ouvrir Figma, je veux pouvoir dire quel problème je résous, pour qui, dans quelles limites, et comment on saura que c'est réussi. Le reste se dessine.