Cadrer, c'est décider ce qu'on conçoit avant de le concevoir : quel problème, pour qui, avec quel résultat attendu, dans quelles contraintes, et comment on saura que c'est réussi. Un sprint de cadrage de quatre semaines produit une vision, des principes et une feuille de route. Il évite de concevoir vite la mauvaise chose.
Le coût de ne pas cadrer
Trois situations que j'ai vécues ou vues de près :
- Six mois de développement sur une fonctionnalité réclamée par un seul gros client, utilisée par personne d'autre.
- Un onboarding redessiné trois fois parce que personne n'avait défini ce que « activé » voulait dire.
- Un calculateur expert livré à des utilisateurs qui n'étaient pas experts, puis entièrement repris. C'est l'histoire de Climeet avant la version simplifiée.
Dans les trois cas, quatre semaines de cadrage auraient coûté moins que la correction.
Semaine 1 : immersion
Parties prenantes
Un entretien d'une heure avec chaque fonction concernée : direction, produit, ventes, support, technique. Trois questions : qu'est-ce qui marche, qu'est-ce qui bloque, qu'est-ce que vous attendez de ce projet. Les divergences entre réponses sont le premier résultat.
Existant
Parcours du produit actuel écran par écran, inventaire des fonctionnalités, lecture des tickets support des trois derniers mois, extraction des données d'usage disponibles (entonnoirs, rétention, temps de tâche). Revue de trois à cinq concurrents pour connaître les conventions du marché.
Semaine 2 : recherche utilisateur proportionnée
Le mot important est proportionnée. La recherche se dimensionne au budget et au risque.
| Budget | Méthode | Ce que ça révèle |
|---|---|---|
| Minimal | Tickets support, avis, données d'usage, entretiens internes | Les frictions les plus fréquentes |
| Standard | Cinq à huit entretiens utilisateurs de 45 minutes | Le vocabulaire, les contournements, les attentes |
| Approfondi | Entretiens plus observation en contexte plus questionnaire | Les usages réels, les segments, les fréquences |
Cinq entretiens bien menés révèlent la majorité des problèmes d'un parcours. Au-delà de huit, on confirme plus qu'on ne découvre. Je synthétise avec l'aide de l'IA pour le regroupement des verbatims, puis je relis tout : la méthode est décrite dans Prompt engineering pour designers.
Semaine 3 : formuler et décider
Le problème en une phrase
« Les responsables RH perdent en moyenne deux heures par campagne de dotation à relancer des salariés qui n'ont pas renseigné leur taille, parce que le lien reçu par email ne leur dit pas combien de temps ça prendra ni pourquoi c'est utile. » Une phrase vérifiable, avec un utilisateur, une situation, une conséquence et une cause. Tout le monde la signe.
Les segments et leurs tâches critiques
Trois à cinq profils d'usage, chacun avec ses tâches critiques, son contexte et ses frictions. Pas des personas marketing avec un prénom et une photo : des profils qui tranchent les débats « l'utilisateur veut ».
La vision et les principes
Une vision d'une page : ce que le produit fait pour qui, et ce qu'il refuse de faire. Puis trois à cinq principes de conception qui guideront les arbitrages futurs. Exemples réels : « jamais bloquant », « la première valeur avant la première configuration », « une action principale par écran ».
Les indicateurs
Ce qu'on mesurera : activation, conversion, rétention, temps de tâche, satisfaction, tickets. Avec la valeur actuelle quand elle existe. Sans indicateur, le cadrage reste une opinion.
Semaine 4 : feuille de route et prototype
Priorisation
Chaque opportunité identifiée est placée sur deux axes : impact pour l'utilisateur et le business, effort estimé avec l'équipe technique. Le quadrant fort impact, faible effort devient la première phase. Le reste est ordonné et daté. Et surtout : une liste explicite de ce qu'on ne fera pas.
Prototype de cadrage
Trois à six écrans clés, en Figma ou en code, testés avec quelques utilisateurs. Pas pour produire les écrans finaux, mais pour vérifier les hypothèses les plus risquées avant d'engager la conception complète. C'est le livrable qui transforme un document en conviction.
Les pièges
- Cadrer sans la technique : une feuille de route que les développeurs découvrent à la fin n'a aucune chance.
- Confondre cadrage et cahier des charges : le cadrage dit quoi et pourquoi ; il laisse le comment à la conception.
- Trop de recherche : au-delà de ce qui change une décision, c'est de la procrastination.
- Pas de décision : un cadrage qui se termine par « il faudrait approfondir » a échoué.
- Oublier ce qu'on ne fera pas : la liste des renoncements est le livrable le plus utile.
Après le cadrage
La conception enchaîne naturellement : UX design, UI et product design, design system. La page UX strategy décrit les formats d'intervention. Et si vous hésitez sur le profil à recruter pour ce travail : Comment choisir un UX designer freelance.
