UX UI Design
UX vs UI : différences, responsabilités et 24 arbitrages d’interface
Voir « Matrice des responsabilités UX/UI » dans la Bibliothèque Edikkav1.0 · CC BY 4.0
Matrice des responsabilités UX/UI
Attribuer une décision d’interface et nommer la preuve attendue.
Aperçu, fichiers et citation
Dans l’instrument
| ID | Situation | Responsable principal |
|---|---|---|
| UXUI01 | Ordonner les étapes d’un formulaire complexe | UX / interaction design |
| UXUI02 | Structurer la navigation et l’architecture de l’information | UX / architecture de l’information |
| UXUI03 | Prévoir la reprise après interruption | UX / interaction design |
Consulter le fichier original — Matrice des responsabilités UX/UI · v1.0
Citer cette version
Edikka (2026). Matrice des responsabilités UX/UI (v1.0). https://www.edikka.com/insights/ux-ui-design/ux-vs-ui-differences#library-source-ux-ui-responsibility-matrix. Consulté le 2026-10-11. CC BY 4.0.
Historique : le catalogue documente la version indiquée ci-dessus. Aucun journal antérieur n’est fourni ici.
Signaler une erreur sur cette version par e-mail — Matrice des responsabilités UX/UILimite d’interprétation. Attribuer une responsabilité ne prouve ni utilisabilité, ni préférence, ni impact business.
Retrouver « Matrice des responsabilités UX/UI » dans la Bibliothèque EdikkaRéponse courte
Différences UX/UI : l’UX organise l’expérience d’usage, l’UI matérialise l’interface.
UX et UI ne désignent ni deux étapes successives, ni le fonctionnel face au décoratif. L’UX travaille le problème, les parcours, les tâches, les comportements et les résultats observés dans un contexte d’usage. L’UI compose les formes visibles et interactives qui rendent ces décisions perceptibles, cohérentes et manipulables. Sur un produit réel, recherche, contenu, interaction, accessibilité, ingénierie et identité de marque traversent cette frontière.
Pour rendre cette distinction actionnable, Edikka publie une matrice de 24 arbitrages courants. Selon la règle annoncée avant le tableau, 4 décisions sont à dominante UX, 6 à dominante UI, 10 sont partagées et 4 ne peuvent pas être attribuées sans preuve. La dichotomie usuelle ne donne donc un responsable principal unique que dans 10 situations sur 24 ; elle ne tranche pas les 14 autres.
Une équipe ne gagne rien à demander « UX ou UI ? » si la décision porte simultanément sur le comportement, la forme et une hypothèse utilisateur. Elle doit nommer un responsable principal, les contributeurs, le critère d’acceptation et la preuve qui permettra de clore le désaccord.
Définitions et périmètre
Définitions UX/UI : quatre états au lieu d’une fausse opposition.
La norme ISO 9241-210 cadre la conception centrée sur l’humain comme un ensemble d’activités menées sur tout le cycle de vie d’un système interactif. ISO 9241-11 définit l’utilisabilité par les résultats de l’usage dans un contexte spécifié. Ces normes éclairent le territoire UX ; elles ne créent pas une profession universelle appelée « UI designer ». La définition UI ci-dessous est donc une définition opérationnelle Edikka, pas une catégorie normative attribuée à l’ISO.
| État | Objet principal | Question décisive | Ce que l’état n’autorise pas à conclure |
|---|---|---|---|
| Dominante UX | Problème, tâche, architecture, parcours ou comportement à comprendre. | Que doit pouvoir accomplir la personne, dans quel contexte et avec quel résultat ? | Que la solution visuelle peut être décidée sans UI ni développement. |
| Dominante UI | Composition visuelle, états, hiérarchie perceptive, tokens et qualité d’exécution. | Comment la décision devient-elle visible, cohérente et manipulable ? | Que la forme peut corriger un mauvais parcours ou démontrer un comportement. |
| Partagée | Décision dont le comportement et la forme se contraignent mutuellement. | Qui mène, qui contribue et quel artefact commun ferme la décision ? | Que « partagé » signifie sans responsable ou décidé au consensus permanent. |
| Preuve requise | Affirmation sur la compréhension, l’efficacité, la confiance ou la performance. | Quelle observation permet réellement d’attribuer ou de valider cette décision ? | Qu’un avis métier, une préférence ou une maquette suffisent à prouver l’effet. |
Cette taxonomie classe une décision, jamais une personne entière. Un designer UI peut mener une recherche ; un designer UX peut construire un système de composants. Le classement indique l’objet dominant et le régime de preuve, pas une frontière de poste immuable.
Règle de décision · v1.0
Règle de décision : classer dans un ordre fixe avant de nommer le responsable.
Les quatre questions sont appliquées dans l’ordre. Dès qu’une réponse correspond à une catégorie, le classement s’arrête. Preuve requise passe avant la responsabilité partagée : une équipe ne doit pas attribuer à l’UX ou à l’UI une affirmation que personne n’a encore observée.
Preuve d’abord
Si la décision prétend expliquer un comportement, une préférence, une compréhension ou un résultat business, aucune couche ne peut être désignée sans observation adaptée.
L’attribution dépend d’une cause ou d’un effet qui doit être observé plutôt que supposé.
Partagé
Si modifier la structure ou le comportement change aussi le sens de la présentation — ou inversement — la responsabilité est partagée.
Structure, contenu, comportement et présentation ne peuvent pas être décidés indépendamment.
Dominante UX
Si l’arbitrage porte principalement sur le besoin, la séquence, l’architecture ou la récupération d’une tâche, il est à dominante UX.
Le parcours, la structure ou la récupération de la tâche gouvernent l’arbitrage.
Dominante UI
Si le parcours et le sens sont déjà établis et que l’arbitrage porte sur le système visuel, la perception ou l’expression de marque, il est à dominante UI.
Le comportement est établi ; l’arbitrage porte principalement sur le système visuel et perceptif.
La colonne « responsabilité » de la matrice sépare ensuite le responsable principal des contributeurs. Cette distinction évite deux échecs symétriques : un silo qui décide seul et un collectif où personne ne ferme la décision.
Résultat de la classification
Résultat de la classification : 10 décisions attribuées, 14 partagées ou soumises à preuve.
| Classification | Nombre | Lecture opérationnelle |
|---|---|---|
| Dominante UX | 4 / 24 | L’objet principal est le problème, le parcours, l’information ou l’observation d’usage. |
| Dominante UI | 6 / 24 | Le cadre est déjà posé ; la décision porte principalement sur la traduction visuelle et les états. |
| Partagée | 10 / 24 | Le comportement et la forme doivent être décidés ensemble avec un responsable principal explicite. |
| Preuve requise | 4 / 24 | Le classement dépend d’une observation, d’une mesure ou d’un test qui n’est pas encore disponible. |
Ce que le décompte révèle : les catégories pures forment un résidu étroit. Les quatre décisions à dominante UX concernent l’architecture des flux ; les six à dominante UI concernent le système visuel. Dès que comportement, forme, contenu ou effet supposé se contraignent mutuellement, la décision devient partagée ou exige une preuve. Le stéréotype « UX fonctionnel, UI visuelle » décrit donc une partie du résidu, pas la réalité complète d’un produit.
Le corpus et le classement ont été établis par un auteur unique, Bertrand Morel, pour Edikka. Le décompte décrit cette version de la matrice ; il ne mesure ni le marché, ni les intitulés de poste, ni une pratique universelle. La règle, les 24 lignes et le fichier ouvert sont publiés précisément pour qu’un tiers puisse contester une attribution et produire un autre décompte.
Application datée : trois décisions observées sur la page de refonte Edikka.
Le 3 septembre 2026, Edikka a appliqué la règle à trois éléments publics de la page de refonte de site internet. Cette inspection décrit l’interface et sa responsabilité ; elle ne fabrique ni test utilisateur ni résultat de conversion.
| ID | Élément observé | Classification | Décision | Preuve et limite |
|---|---|---|---|---|
| UXUI02 | Ordre des sections et méthode en sept étapes. | Dominante UX | L’architecture organise le parcours d’information ; l’UI contribue à sa perception sans en déterminer seule la séquence. | Titres et ordre du DOM public inspectés. Aucun effet sur la compréhension n’est affirmé. |
| UXUI11 | Actions « Cadrer ma refonte » et « Préparer l’échange de cadrage ». | Partagée | Finalité, libellé, emplacement, hiérarchie visuelle, focus et destination doivent converger. | Libellés, liens et hiérarchie visibles inspectés. Usage au clavier et conversion restent à mesurer. |
| UXUI24 | Affirmation éventuelle que la page inspire confiance ou paraît premium. | Preuve requise | Une inspection visuelle peut décrire la composition ; elle ne peut pas attribuer une perception à un public. | Aucune donnée utilisateur publiée : l’affirmation reste ouverte. |
Instrument ouvert · 24 arbitrages
Matrice Edikka des responsabilités UX/UI : décision, responsable, acceptation et preuve.
Chaque ligne possède un identifiant stable. La justification explique pourquoi l’état a été retenu ; le responsable principal ne remplace pas les contributeurs ; le critère d’acceptation dit quand la décision peut être fermée ; la preuve attendue rend le désaccord rejouable. Le tableau affiché est généré depuis le JSON canonique : une divergence avec le XLSX ou les miroirs Markdown bloque la publication.
Dominante UX · 4 arbitrages
Dominante UX
Le parcours, la structure ou la récupération de la tâche gouvernent l’arbitrage.
Dominante UI · 6 arbitrages
Dominante UI
Le comportement est établi ; l’arbitrage porte principalement sur le système visuel et perceptif.
Responsabilité partagée · 10 arbitrages
Responsabilité partagée
Structure, contenu, comportement et présentation ne peuvent pas être décidés indépendamment.
Preuve requise · 4 arbitrages
Preuve requise
L’attribution dépend d’une cause ou d’un effet qui doit être observé plutôt que supposé.
Protocole de réutilisation
Mode d’emploi : reclasser une ligne sans demander à Edikka d’avoir raison.
- Choisir une décision précise et conserver son identifiant UXUI01 à UXUI24.
- Appliquer les quatre questions dans l’ordre publié, sans partir du titre du collaborateur disponible.
- Documenter le contexte : produit, phase, contrainte, données disponibles et décision réellement attendue.
- Nommer un responsable principal et des contributeurs ; « partagé » ne signifie jamais « sans propriétaire ».
- Définir un critère d’acceptation observable et l’artefact qui en constituera la preuve.
- Si la classification diffère de la v1.0, conserver les deux valeurs et écrire le motif du désaccord dans le XLSX.
- Publier le rejeu avec sa date, son auteur et la version de la matrice. Une objection documentée alimente le changelog ; elle n’est pas lissée dans une moyenne.
Une organisation peut donc remplacer « dominante UX » par « partagée » pour une ligne donnée sans invalider le reste. L’unité de contestation est l’arbitrage, pas la réputation de l’auteur.
Ce que la matrice ne démontre pas
Limites : une attribution claire ne prouve ni utilisabilité ni conversion.
| La matrice décrit | Elle ne démontre pas | Preuve supplémentaire nécessaire |
|---|---|---|
| Un objet dominant et un responsable principal. | Que la meilleure personne ou organisation a été choisie. | Compétences, disponibilité, gouvernance et revue du contexte. |
| Un critère d’acceptation pour chaque décision. | Que l’interface sera utilisable par son public réel. | Évaluation experte et tests représentatifs du contexte d’usage. |
| Les contributeurs attendus. | Que la collaboration a effectivement eu lieu. | Journal de décision, revue et artefacts datés. |
| Des contrôles liés à WCAG lorsqu’ils sont pertinents. | La conformité WCAG ou RGAA de la page, du service ou du produit. | Audit complet sur le périmètre déclaré et tests humains. |
Livrables attendus
Livrables : chaque décision doit laisser une trace contrôlable.
| Classification | Livrables utiles | Condition de fermeture |
|---|---|---|
| Dominante UX | Hypothèse, scénario, flux, architecture, prototype de comportement ou résultat de recherche. | Le besoin, le parcours et le résultat attendu sont explicités dans un contexte d’usage. |
| Dominante UI | Composition, états, tokens, spécifications, composants, exemples responsives et inventaire de variantes. | États et comportements visuels sont cohérents, spécifiés et vérifiables. |
| Partagée | Prototype, contrat de composant, table d’états, contenu réel et journal d’arbitrage. | Le comportement, la forme, le contenu et l’implémentation convergent sur le même critère. |
| Preuve requise | Plan de test, métrique, échantillon, observation brute, limites et décision après mesure. | La conclusion reste proportionnée aux données ; une absence de preuve conserve l’état ouvert. |
Architecture éditoriale
Frontières éditoriales : responsabilités, mots, formulaires et conversion.
Ressources ouvertes · CC BY 4.0
Ressources ouvertes : télécharger, rejouer et contester la matrice.
- Matrice Edikka des responsabilités UX/UI · XLSX — synthèse, 24 arbitrages FR/EN, rejeu et sources.
- Dataset canonique · JSON — source machine-readable des classifications et des contenus.
- Édition française · Markdown.
- English edition · Markdown.
Citation recommandée : Morel, Bertrand (2026). Matrice Edikka des responsabilités UX/UI — 24 arbitrages d’interface, version 1.0, Edikka. Licence Creative Commons Attribution 4.0.
Question de revue : « Quelle ligne est mal classée, incomplète ou impossible à rejouer — et quelle preuve modifierait la décision ? » Toute objection signée, datée et argumentée peut être ajoutée au changelog, qu’elle conduise ou non à une reclassification.
Sources primaires
Sources primaires : normes et référentiels qui bornent la méthode.
- ISO 9241-210:2019 — Human-centred design for interactive systems — Cadre du processus de conception centrée sur l’humain sur l’ensemble du cycle de vie.
- ISO 9241-11:2018 — Usability : Definitions and concepts — L’utilisabilité est traitée comme un résultat de l’usage, pas comme une propriété visuelle déduite.
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2 — Critères testables applicables à la perception, l’interaction, la compréhension et la robustesse.
- W3C — WAI-ARIA 1.2 — Rôles, états et propriétés programmatiques des composants d’interface.
- GOV.UK Service Manual — What each role does in a service team — Référence opérationnelle pour la collaboration entre recherche, contenu, design et développement.
- GOV.UK Design System — Get started — Les composants et patterns publiés documentent leur statut de test et doivent être adaptés au contexte.
Historique public
Historique public : version, limites et prochaines décisions.
| Date | Version | Modification |
|---|---|---|
| 3 septembre 2026 | 1.0 | Publication de la règle, des 24 arbitrages, des critères d’acceptation, des preuves attendues, du JSON canonique, du XLSX rejouable et des éditions Markdown FR/EN. Classement initial établi par un auteur unique ; revue contradictoire externe recherchée. |
Prochaine revue programmée : 3 décembre 2026, ou avant si une objection reproductible modifie une ligne. Aucun DOI n’est déclaré dans cette version.
Consigne, source complète et citation
Approfondir cette analyse.
Choisissez un usage, relisez la consigne puis emportez-la dans votre IA.
UX vs UI : différences, responsabilités et 24 arbitrages d’interfaceMis à jour le 3 septembre 2026
Relire la consigne complète
Vos saisies restent dans ce navigateur jusqu’au collage dans votre IA. Aucune analyse n’est lancée ici.
Votre IA ne peut pas lire le lien ?
Copiez la source complète ou téléchargez le document, puis joignez-le à votre conversation.
Message complet à copier
Aucun message n’est envoyé depuis cette page.
Vous relisez et publiez vous-même depuis LinkedIn.
UX et UI ne sont pas deux territoires concurrents, mais deux responsabilités coordonnées par la preuve.
La matrice nomme un responsable principal sans créer de silo : contributeurs, critères d’acceptation et preuves nécessaires pour résoudre un désaccord restent visibles.
Attribuer un pilotage, pas un monopole
Chaque décision nomme les contributeurs et la preuve nécessaire pour résoudre un désaccord.
Ne pas déduire un comportement d’une apparence
Compréhension, confiance et conversion restent ouvertes tant qu’elles ne sont pas observées avec une méthode adaptée.
Rendre le désaccord productif
Une reclassification est consignée à la ligne pour améliorer la matrice au lieu de masquer le désaccord dans une moyenne.
Comprendre, appliquer et contester la classification
Dix réponses alignées sur la règle, les limites et les ressources ouvertes de la matrice Edikka.
Quelle est la différence entre UX et UI ?
L’UX organise le problème, le parcours, les tâches et les résultats observés dans un contexte d’usage. L’UI matérialise ces décisions par la composition visuelle, les états, la hiérarchie perceptive et les composants interactifs. Sur un produit réel, de nombreuses décisions sont partagées.
Pourquoi la dichotomie UX/UI ne tranche-t-elle que 10 situations sur 24 ?
Dans cette matrice v1.0, 4 arbitrages sont à dominante UX et 6 à dominante UI. Les 14 autres sont soit partagés, soit impossibles à attribuer sans preuve. Ce décompte décrit une classification d’auteur unique ; il peut être contesté ligne par ligne.
Un responsable principal est-il le seul responsable ?
Non. Le responsable principal ferme la décision et garantit sa traçabilité. Les contributeurs restent nommés, notamment contenu, accessibilité, produit, recherche et développement. Un responsable explicite évite le silo autant que la décision sans propriétaire.
Quand une décision UX/UI est-elle partagée ?
Elle est partagée lorsque modifier la structure ou le comportement change aussi le sens de la présentation, ou inversement. L’équipe nomme alors un responsable principal, des contributeurs, un critère d’acceptation commun et la preuve attendue.
Quand faut-il classer une décision en preuve requise ?
Dès qu’elle prétend expliquer une compréhension, une préférence, une confiance, une efficacité ou un résultat business sans observation adaptée. Une maquette, un avis expert ou une préférence ne prouvent pas à eux seuls cet effet.
Comment utiliser la matrice UX/UI Edikka ?
Choisissez une ligne, appliquez les quatre questions dans l’ordre, documentez le contexte, nommez responsable et contributeurs, puis définissez acceptation et preuve. En cas de désaccord, conservez le classement v1.0 et publiez votre reclassification avec son motif.
Cette matrice est-elle une norme UX/UI ?
Non. C’est une taxonomie opérationnelle Edikka publiée sous CC BY 4.0. Elle s’appuie sur des sources primaires mais ne doit pas être attribuée à l’ISO, au W3C ou au GOV.UK Service Manual.
Quel est le lien entre UX, UI et accessibilité ?
L’accessibilité traverse UX, UI, contenu et développement. La matrice cite des preuves WCAG lorsqu’elles sont pertinentes, mais elle ne démontre jamais la conformité complète d’une page, d’un service ou d’un produit.
Quelle est la frontière avec l’article UX writing ?
Cette page attribue les décisions d’interface. Le protocole UX writing vérifie les mots d’interfaces réelles : exactitude, action, nom accessible et cohérence entre états. Il ne remplace ni cette matrice de responsabilités ni le guide technique des formulaires.
Peut-on réutiliser ou reclasser les 24 arbitrages ?
Oui. Le JSON, le XLSX rejouable et les éditions Markdown sont publiés sous CC BY 4.0. Une organisation peut reclasser une ligne si elle conserve l’identifiant, décrit son contexte et publie le motif ainsi que la preuve qui change la décision.
