Mon approche des projets UX : du chaos à la direction

Après des années passées à travailler sur des produits numériques, j'en suis venu à la conviction que le design UX concerne rarement les écrans.

La plupart des projets difficiles ne le sont pas à cause du design. Ils sont difficiles parce que personne ne comprend encore pleinement le problème.

La plus grande erreur que je vois les équipes commettre est de sauter directement dans les wireframes, l'inspiration UI ou les discussions sur les fonctionnalités avant même de comprendre ce qu'elles essaient réellement de résoudre.

Alors, avant de parler de processus ou d'outils, je veux parler de ma façon de réfléchir.

L'état d'esprit

Commencer par le problème business

Quand je rejoins un nouveau projet, je n'ouvre pas Figma. J'essaie d'abord de répondre à quelques questions :

Pourquoi ce projet existe-t-il ?
Quel est le vrai problème derrière la demande ?
Quel résultat business essayons-nous d'atteindre ?
Comment saurons-nous si c'est un succès ?

La plupart des projets commencent par une demande qui ressemble à une solution :

"Nous avons besoin d'un nouveau tableau de bord."

"Nous avons besoin d'une application mobile."

"Nous avons besoin de fonctionnalités d'IA."

Ce sont des réponses à un problème que personne n'a encore formulé à voix haute.

Parfois, le vrai problème est un faible taux de conversion. Parfois, c'est une inefficacité opérationnelle. Parfois, c'est une mauvaise rétention. Identifier le problème réel change généralement la direction de tout le projet, y compris la question de savoir si ce tableau de bord ou cette application était la bonne idée au départ.

Cartographier le problème sous trois angles

Une fois que je comprends l'objectif business, je cartographie le projet sous trois angles :

Business : flux de travail internes, attentes des parties prenantes
Utilisateur : objectifs, points de friction, comportements existants, motivations
Technique : systèmes existants, disponibilité des données, contraintes de développement, calendrier

Je garde un cadre en tête : Objectifs Business × Besoins Utilisateurs × Réalité Technique.

Les solutions les plus solides se trouvent presque toujours à l'intersection des trois. Une solution qui ignore l'un de ces piliers a tendance à mourir quelque part entre le pitch et la production.

Là où les projets deviennent vraiment complexes

Les projets les plus difficiles sont des problèmes d'alignement, pas de design

Les projets les plus stimulants sur lesquels j'ai travaillé n'étaient pas les plus vastes. C'étaient ceux où chacun arrivait avec des hypothèses différentes.

Le marketing voulait une chose. Kitar en voulait une autre. Les développeurs avaient des contraintes que personne n'avait soulevées. Le client avait un calendrier qui supposait que tout ce qui précède était déjà réglé.

Dans ces situations, mon travail cesse d'être de « dessiner des écrans » pour devenir « créer de l'alignement ».

Mon rôle consiste moins à concevoir des interfaces qu'à faciliter les conversations, valider les hypothèses et aider les équipes à s'accorder sur les priorités avant de passer à l'exécution du design.

C'est pour ce genre de moments que je considère l'alignement comme un livrable de design à part entière, et non comme une simple contrainte de réunion.

Comment je travaille concrètement ? Un processus itératif

J'ai un processus. Sur le papier, il ressemble à ceci :

Découverte : entretiens avec les parties prenantes, compréhension du business, revue de produit, données
Définition : énoncés de problèmes, besoins utilisateurs, indicateurs de succès, priorisation
Structure : flux utilisateurs, architecture de l'information, plan du site
Design : wireframes, validation, haute fidélité
Itération : retours, tests, améliorations

Mais cette version propre est un leurre. En réalité, les phases se chevauchent et bouclent sur elles-mêmes. Un wireframe à l'étape 4 peut révéler une page manquante qui me renvoie à l'étape 3. Un test utilisateur à l'étape 5 peut recadrer un énoncé de problème de l'étape 2.

L'exemple le plus frappant est la vieille question : le plan du site d'abord, ou les wireframes d'abord ?

En théorie, la structure vient en premier. Un plan de site définit les pages, les relations et l'organisation de l'information. Mais en pratique, je commence souvent les wireframes en moyenne fidélité plus tôt que ce que la plupart des designers préconisent.

La raison est simple : les parties prenantes comprennent mieux les écrans que les diagrammes. Demandez à un client de réagir à un plan de site et il reste silencieux. Montrez-lui un écran brut et il vous dira immédiatement ce qui manque.

Cela ne signifie pas que je saute l'architecture de l'information. Pendant que je crée les wireframes, je valide simultanément les pages nécessaires, l'emplacement des informations, le parcours de l'utilisateur et la cohérence de la structure.

Pour moi, le plan du site et les wireframes ne sont pas des phases distinctes : ils évoluent ensemble, main dans la main. Les wireframes révèlent les pages manquantes et les flux flous ; le plan du site maintient la cohérence de l'ensemble. Le but n'est pas de suivre un ordre académique, mais d'aider les parties prenantes à comprendre le produit assez rapidement pour prendre les bonnes décisions.

Le métier

Les outils que j'utilise

On me demande souvent quels outils j'utilise. La réponse honnête est que je passe la majeure partie de mon temps sur un petit nombre d'entre eux.

Figma : là où l'essentiel du travail se fait : exploration, flux utilisateurs, wireframes, UI haute fidélité, systèmes de design, prototypes et transfert aux développeurs. Pour moi, c'est moins un outil de design qu'un lieu où les idées deviennent tangibles et les discussions se transforment en décisions.
FigJam : quand j'ai besoin de réfléchir à la structure avant de concevoir, ou de remettre sur les rails un projet flou. J'y cartographie les flux utilisateurs, les plans de site, l'architecture de l'information et les parcours de bout en bout. Je ne l'utilise pas sur tous les projets — surtout quand il y a beaucoup de pages, des parcours complexes ou des exigences peu claires.
ChatGPT / Gemini / Claude : des partenaires de réflexion, pas des outils de design. Je les utilise pour remettre en question mes hypothèses, explorer des idées sous d'autres angles, rédiger des textes UX, structurer des questions de recherche et synthétiser de grandes quantités d'informations. Ils accélèrent la réflexion ; les décisions nécessitent toujours un jugement humain.
Google Docs : pour tout ce qui doit être communiqué clairement : briefs, notes, exigences, résumés de recherche. L'écriture expose souvent les lacunes de ma réflexion avant qu'elles ne deviennent des problèmes de design.
Papier et stylo : toujours l'un des outils que j'utilise le plus. Le croquis élimine la pression de la finition et me permet de me concentrer purement sur la réflexion. Parfois, le moyen le plus rapide de résoudre un problème de design est de prendre un stylo et de commencer à dessiner.

Où je trouve mon inspiration

Il y a un piège à chercher l'inspiration : on absorbe des styles au lieu de réfléchir. Ma solution est de suivre deux pistes distinctes.

Inspiration structurelle / UX, pour comprendre les décisions :

Mobbin : de vrais modèles d'UI provenant d'applications réelles, classés par flux. Utile pour voir à quoi ressemblent réellement les standards de l'industrie en production.
UX Archive : des flux complets de produits comme Airbnb et Spotify. J'étudie le raisonnement derrière ces modèles, pas seulement les modèles eux-mêmes.

Inspiration visuelle, pour stimuler la direction artistique, à utiliser avec précaution :

Dribbble / Behance : bien pour la direction visuelle, mais ce qui est beau n'est pas forcément utilisable. Des références d'ambiance, pas des modèles à copier.
Awwwards / Godly : des sites primés, utiles pour repousser les limites de ce que je pense possible en termes de mise en page et d'interaction.

Systèmes de design : Apple HIG, Material Design, Atlassian. Je lis la documentation, pas seulement les composants. Comprendre pourquoi quelque chose a été conçu d'une certaine manière est bien plus efficace que de copier son apparence.

Hors écran : livres, magazines, architecture, espaces physiques. Certaines des meilleures réflexions UX que j'ai absorbées proviennent de l'observation de la façon dont les espaces physiques guident le mouvement. La hiérarchie, le guidage et la densité d'information existent partout, pas seulement sur les écrans.

Ce que je transmettrais

Si je devais former un designer junior

Je ne suis probablement pas la personne idéale pour écrire le guide définitif. J'apprends encore chaque jour par moi-même. Mais avec le recul, quelques points comptent plus que le reste.

Concentrez-vous sur la compréhension du problème. À mes débuts, j'étais obsédé par les écrans. J'ai réalisé que comprendre le problème est généralement plus important que de concevoir la solution. Mieux je comprends le business, les utilisateurs et les contraintes, plus chaque décision de design devient facile.
Apprenez à expliquer vos décisions. L'une des compétences les plus précieuses que j'ai développées n'est pas de créer des designs, mais d'expliquer pourquoi un design existe. Relier les choix de design aux besoins des utilisateurs et aux objectifs business a plus de valeur que n'importe quelle tendance.
Ne commencez pas par la haute fidélité. Mes plus grandes erreurs sont venues d'un passage trop rapide à l'UI. Il est bien plus facile de modifier un croquis que de redessiner un écran fini.
Restez curieux. Les designers que j'admire le plus ne sont pas ceux qui ont toutes les réponses, mais ceux qui continuent à poser de meilleures questions.

Plus je travaille dans l'UX, moins je crois que le design consiste à fabriquer des écrans.

Une bonne UX consiste à réduire l'incertitude, à comprendre le problème assez clairement pour que la bonne solution devienne une évidence.