UI vs UX : La vraie différence (et pourquoi la plupart des explications sont fausses)
L'UI n'est pas le papier cadeau. L'UX n'est pas le cadeau. La vraie différence entre UI et UX, ce que chaque rôle fait vraiment, et qui recruter pour quoi.
L'UI n'est pas le papier cadeau. L'UX n'est pas le cadeau. L'UI n'est pas non plus le flacon de ketchup, et l'UX n'est pas le fait de verser le ketchup.
Chaque article explicatif sur «UI vs UX» sur internet se cache derrière une analogie parce que l'auteur n'a jamais vraiment fait l'un ou l'autre. L'analogie du flacon de ketchup n'a rien appris à toute une génération de designers. Un flacon de ketchup n'a pas de hiérarchie de tâches, pas de recherche utilisateur, pas de modes d'échec, pas de métriques de succès, pas de cas limites à 390px. Vous ne livrez pas un condiment. Vous livrez du logiciel.
Cet article tue les analogies, définit chaque discipline en une phrase, cartographie ce que chaque rôle produit concrètement au quotidien, et vous donne un cadre de recrutement utilisable dès demain.
Les analogies sont le problème
Les explications dominantes traitent l'UI et l'UX comme des métaphores physiques parce que les métaphores sont plus faciles à écrire que des définitions. Le coût : chaque designer junior arrive à son premier emploi en croyant que l'UI c'est «les couleurs et les polices» et que l'UX c'est «l'ambiance». Les deux sont faux.
«L'UI est la voiture, l'UX est la conduite» ne vous dit rien sur l'architecture de l'information. «L'UI est la maison, l'UX c'est y vivre» ne vous dit rien sur le journey mapping. «L'UI est visuel, l'UX est interaction» est la version la plus répandue et aussi la plus fausse. Les designers UI passent une grande partie de leur semaine sur les états d'interaction. Les designers UX passent une grande partie de leur semaine sur des décisions visuelles comme la densité d'information et la hiérarchie de mise en page. La frontière n'est pas tracée là où les analogies le disent.
Jetez tout ça. Repartez de ce que chaque discipline décide vraiment.
La vraie définition, une phrase chacune
L'UX est l'architecture des décisions. L'UI est l'expression de ces décisions à l'écran. C'est tout.
L'UX demande ce qui doit exister et quand. Quels écrans ce produit nécessite. Dans quel ordre l'utilisateur les traverse. Quelle information apparaît à chaque étape. Que se passe-t-il quand l'utilisateur est confus, dans l'erreur, ou pressé. À quoi ressemble le succès, et comment le savoir.
L'UI demande comment ces décisions ont l'air, se ressentent et bougent une fois à l'écran. Quelle est la hiérarchie, ce que dit la typographie, comment un bouton se comporte quand on appuie dessus, comment une modale entre en scène, ce que communique un état désactivé, comment l'ensemble reste cohérent sur cinquante écrans et trois appareils.
Même produit. Deux couches de décision différentes. L'une ne peut pas être livrée sans l'autre.
Ce que fait vraiment un designer UX
La semaine d'un designer UX est principalement consacrée à la recherche et à la structure, pas aux écrans.
Il mène des entretiens utilisateurs, examine les enregistrements de sessions, et construit des journey maps. Il dessine l'architecture de l'information, décide de la taxonomie, et débat avec les product managers sur ce qu'est vraiment une fonctionnalité. Il esquisse des flux. Il construit des wireframes que personne ne veut regarder parce qu'ils sont délibérément laids. Il valide des hypothèses en testant des prototypes avec de vrais utilisateurs, et il supprime les fonctionnalités qui ont mal passé les tests.
Livrables UX typiques :
- Synthèse de recherche utilisateur et personas
- Journey maps et diagrammes de flux
- Architecture de l'information et modèles de contenu
- Wireframes basse fidélité
- Plans et rapports de tests d'utilisabilité
- Métriques de succès et spécifications d'instrumentation
Le designer UX est la personne qui demande «cet écran devrait-il exister tout court» avant que quiconque demande «de quelle couleur est le bouton».
Ce que fait vraiment un designer UI
La semaine d'un designer UI est l'inverse. Il décide de l'apparence et du comportement de la chose une fois que l'UX a décidé ce qu'elle est.
Il construit des systèmes visuels. Il définit l'échelle typographique, les tokens de couleur, le rythme des espacements, et les spécifications des composants. Il conçoit chaque état d'interaction (par défaut, survol, actif, focus, désactivé, chargement, vide, erreur). Il définit les règles de motion. Il s'acharne sur la hiérarchie des pixels à travers les breakpoints et s'assure que le produit ressemble à un seul produit sur chaque écran. Il livre la bibliothèque de composants et les design tokens que l'ingénierie consomme réellement.
Livrables UI typiques :
- Système de design visuel (typographie, couleur, espacement, grille)
- Bibliothèque de composants avec tous les états d'interaction
- Design tokens exportés vers le code
- Spécifications de motion et de transitions
- Écrans haute fidélité et maquettes haute résolution
- Documentation de passation pour l'ingénierie
Le designer UI est la personne responsable du fait que le produit se ressente comme cohérent et vivant, pas seulement fonctionnel.
Là où les deux se rejoignent
C'est au milieu que les bons produits se font.
Le prototypage est partagé. Les deux rôles construisent des prototypes, l'UX pour valider les flux, l'UI pour valider le motion et la finition. Les tests utilisateurs sont partagés. L'UX conçoit le test, l'UI observe si ses choix visuels aident ou nuisent à la compréhension. Les revues de design sont partagées par définition, et elles ne fonctionnent que lorsque les deux perspectives sont dans la salle.
Voici la vérité qui dérange : un designer UI qui ne comprend pas l'UX livre de beaux culs-de-sac. Un designer UX qui ne peut pas exécuter visuellement livre des présentations stratégiques que personne ne met en œuvre. Les bons développent suffisamment de polyvalence de l'autre côté pour livrer un travail qui survit au premier contact avec les utilisateurs. Les meilleurs deviennent des product designers, ce à quoi on reviendra.
La question du product designer
«Product designer» est le titre qui a avalé le terrain intermédiaire, et en 2026, il désigne une personne qui fait à la fois UI et UX à un niveau crédible.
Dans une startup, un product designer est souvent le seul designer de l'entreprise. Il possède la recherche, les flux, les wireframes, le système visuel, les composants et le motion. Il est une équipe design à lui seul, et ça fonctionne parce qu'une startup ne peut se payer qu'une seule personne et a besoin des deux moitiés de la discipline.
Dans une grande entreprise, un product designer possède généralement une zone produit de bout en bout et collabore avec des chercheurs UX spécialistes, des équipes de design system, et parfois un motion designer. Il est l'opérateur généraliste, pas un hybride junior.
L'erreur que font la plupart des fondateurs est de recruter un «product designer» alors qu'ils ont réellement besoin d'un chercheur UX senior, ou un «designer UI» alors qu'ils ont réellement besoin d'un product designer. L'inflation des titres masque la vraie question : quel est le vrai problème, et quel mélange de compétences le résout.
Outils, processus, livrables
Une comparaison rapide. C'est la version condensée, pas une spécification complète.
| Dimension | Designer UX | Designer UI | Product Designer |
|---|---|---|---|
| Question principale | Ce qui doit exister, et quand | Comment ça doit avoir l'air, se ressentir, bouger | Les deux, de bout en bout |
| Outils principaux | Figma, Miro, Dovetail, Maze | Figma, Framer, Principle | Figma, Framer, code léger |
| Livrables clés | Recherche, flux, IA, wireframes | Système visuel, composants, états | Tout ce qui précède, pour une zone produit |
| Livre | Plans validés | Écrans pixel-perfect + composants | Fonctionnalités validées et livrées |
| Métrique de succès | Taux de réussite des tâches, temps sur la tâche | Cohérence visuelle, scores d'utilisabilité | Métriques produit (activation, rétention) |
| Travaille principalement avec | PMs, chercheurs, analystes | Brand, design systems, frontend | PMs, ingénieurs, tout le monde |
Les designers UI s'appuient sur la hiérarchie visuelle, les systèmes de tokens et les modèles de mise en page comme les bento grids pour rendre les écrans lisibles d'un coup d'œil. Les designers UX s'appuient sur des boucles de recherche, des tests de flux et des audits d'accessibilité pour s'assurer que le produit fonctionne pour tous ceux pour qui il doit fonctionner. Les product designers vivent dans les deux pièces et finissent généralement par posséder la structure des pages d'atterrissage aussi, parce que le travail de conversion ne se situe pas proprement à l'intérieur de l'un ou l'autre rôle spécialiste.
Côté outils, tout le monde utilise Figma. Se disputer sur les outils, c'est la façon dont les designers évitent de se disputer sur le vrai travail. Si vous voulez la courte liste de ce qui vaut la peine d'être installé, l'article sur les plugins Figma qui valent l'installation l'a.
Quand recruter UI, UX, les deux, ou un product designer
C'est la section à mettre en favori.
Utilisez le tableau. Associez votre situation à une ligne, recrutez le rôle dans la dernière colonne.
| Stade | Problème principal | Équipe actuelle | Recruter |
|---|---|---|---|
| Pré-lancement, sans designer | Tout doit être décidé et construit | Juste un fondateur et des ingénieurs | Product designer |
| Pré-lancement, avec un prestataire UI | Le produit a l'air bien mais les utilisateurs se perdent | Prestataire UI, pas d'UX | Designer UX (temps plein ou freelance senior) |
| Revenus initiaux, en croissance | Les flux fonctionnent mais le produit semble daté et incohérent | 1 designer UX / product | Designer UI ou responsable design systems |
| En croissance, fort volume d'utilisateurs | Abandons dans des flux spécifiques, causes inconnues | 1 product designer, surchargé | Chercheur UX (spécialiste), pas un autre généraliste |
| Mature, multi-produits | Problèmes de cohérence entre les produits | Plusieurs product designers | Équipe design systems + UX principal |
| Agence, travail client | Besoin de livrer des projets complets de bout en bout | Petite équipe | Product designers + un chercheur UX partagé |
Trois raccourcis qui évitent la plupart des erreurs de recrutement :
- Si votre produit a un problème UX déguisé en problème UI, recruter un designer UI empire les choses. Il vous donnera une belle version d'un produit confus. La confusion sera plus coûteuse à corriger parce qu'elle aura l'air intentionnelle.
- Si vous n'avez qu'un seul poste de design, recrutez un product designer. Les spécialistes n'ont de sens qu'une fois que vous avez le volume pour les maintenir pleinement occupés.
- Si vous débattez de «avons-nous besoin d'un designer UX ou d'un designer UI», vous avez probablement besoin d'un product designer et d'un brief produit plus clair.
FAQ
L'UI ou l'UX est-il plus important ?
Ni l'un ni l'autre. Un produit avec une excellente UX et une mauvaise UI perd face à son concurrent sur la qualité perçue. Un produit avec une excellente UI et une mauvaise UX perd sur l'utilisation réelle. Ce sont deux moitiés d'un seul travail, et n'en livrer qu'une, c'est livrer la moitié d'un produit.
Une seule personne peut-elle faire à la fois UI et UX ?
Oui, et cette personne s'appelle généralement un product designer. La plupart des startups en phase initiale sont mieux servies par un généraliste solide qu'une division junior UI/UX. La spécialisation ne paie que lorsque l'équipe dépasse un seul designer.
Les designers UX ont-ils besoin de savoir coder ?
Non, mais comprendre comment les choses sont construites les rend meilleurs. Un designer UX qui sait ce qui est bon marché, coûteux ou impossible en code livre des flux que l'ingénierie peut réellement mettre en œuvre. Ce n'est pas un travail de codage. C'est un travail de culture des systèmes.
Quelle est la différence de salaire entre les designers UI et UX ?
Dans la plupart des marchés, les deux titres sont rémunérés de manière similaire au même niveau de séniorité. Les titres de product designer ont tendance à mieux payer que l'un ou l'autre titre spécialiste au même niveau, car le rôle exige les deux ensembles de compétences. Le facteur le plus déterminant de la rémunération est le stade de l'entreprise et le secteur, pas l'UI vs l'UX.
Recrutez le rôle adapté au problème
Arrêtez de demander quelle est la différence entre UI et UX. Commencez à vous demander quel problème spécifique vous cherchez à résoudre et quels livrables vous y mènent.
L'UX livre des plans qui ont survécu au contact des vrais utilisateurs. L'UI livre des écrans qui ressemblent à un seul produit sur cinquante surfaces. Les product designers livrent les deux, de bout en bout, pour une zone produit. Choisissez le rôle qui correspond au problème que vous avez réellement, pas le titre qui sonne le plus cher sur un organigramme.
Chaque article médiocre sur internet continuera de recycler le flacon de ketchup. Vous n'avez pas à le faire. Vous avez un produit à livrer et une équipe à construire pour ça.
Need to figure out whether your product needs a UI designer, a UX designer, or both? Brainy builds the team for the problem, then ships the work.
Get Started
