Un écran peut être élégant et rester difficile à utiliser. L’UX/UI design ne sert pas à embellir un parcours déjà décidé : il réduit l’écart entre ce que l’utilisateur veut accomplir, ce que l’entreprise doit obtenir et ce que l’interface permet réellement.
1. La distinction utile entre UX et UI
L’expérience utilisateur (UX) couvre la manière dont une personne comprend, traverse et évalue un service : promesse, information, étapes, effort, erreurs, confiance, canaux et suites opérationnelles. L’interface utilisateur (UI) traduit cette expérience dans un système visuel et interactif : hiérarchie, composants, états, typographie, couleurs, mouvement et comportement responsive.
La formule « UX avant UI » simplifie trop. Une hiérarchie visuelle modifie la compréhension ; un composant technique contraint le parcours ; une règle métier change l’expérience. Les deux disciplines travaillent en boucle avec contenu, produit, développement, données, accessibilité et opérations.
Le résultat n’est donc pas une collection de maquettes. C’est un parcours compréhensible, réalisable, mesurable et suffisamment robuste pour ses utilisateurs réels — y compris lorsque les données manquent, que le réseau ralentit ou qu’une erreur survient.
2. Chiffres clés : les frictions ne sont ni marginales ni seulement esthétiques
| Donnée | Périmètre et source | Ce qu’elle dit vraiment | Décision de conception |
|---|---|---|---|
| 70,22 % | Moyenne de 50 études sur l’abandon de panier, calculée par Baymard en 2025. | Une grande part de l’abandon est naturelle ; le taux brut ne mesure pas seul la qualité du checkout. | Segmenter les causes contrôlables avant de promettre un gain de conversion. |
| 18 % | Acheteurs interrogés ayant abandonné parce que le checkout paraissait trop long ou complexe, Baymard. | La complexité perçue compte autant que le nombre objectif d’étapes. | Tester compréhension, effort et reprise sur mobile avec les vrais champs. |
| 11 777 participants | Neuf études quantitatives intégrées au corpus checkout de Baymard. | Les recommandations reposent sur plusieurs méthodes ; elles restent à valider dans le contexte propre. | Utiliser les benchmarks comme hypothèses, puis mesurer le parcours réel. |
| 2 700+ problèmes | Incidents d’utilisabilité observés durant 272 sessions de test de checkout, Baymard. | Même les interfaces de grandes marques accumulent des frictions concrètes. | Faire tester les tâches, pas seulement commenter les écrans en réunion. |
| 1 personne sur 5 | Personnes déclarant un handicap permanent au Royaume-Uni, rappel du GOV.UK Service Manual. | L’accessibilité concerne une part importante du public, à laquelle s’ajoutent contraintes temporaires et situationnelles. | Inclure des personnes handicapées dans la recherche et la recette. |
| 56,1 erreurs/page | Erreurs d’accessibilité détectables en moyenne sur un million de pages d’accueil, WebAIM 2026. | L’automatisation révèle une partie des barrières ; elle ne prouve pas la conformité. | Combiner scanner, inspection, clavier, technologies d’assistance et tests utilisateurs. |
| 83,9 % | Pages présentant du texte à contraste insuffisant dans WebAIM Million 2026. | Le contraste reste un défaut massif, souvent créé ou validé dans le système visuel. | Vérifier les couples réels couleur/taille/état avant de publier la palette. |
| 33,1 % | Champs de formulaire sans étiquette correcte dans le même corpus WebAIM. | Un formulaire peut paraître clair visuellement tout en étant ambigu pour une technologie d’assistance. | Définir label, aide, erreur, succès et focus dans chaque composant. |
| 2,5 s / 200 ms / 0,1 | Seuils « bons » pour LCP, INP et CLS au 75e percentile, web.dev. | La qualité vécue inclut chargement, réactivité et stabilité, mesurés sur le terrain. | Ajouter des budgets de performance aux critères UI, surtout pour médias et scripts. |
| 48 % | Expériences mobiles passant les trois Core Web Vitals en 2025, contre 36 % en 2023, HTTP Archive. | Le Web progresse, mais plus de la moitié du périmètre CrUX observé ne passe toujours pas les trois seuils. | Concevoir et tester sur appareils et connexions réalistes, pas uniquement sur le poste du designer. |
Ces résultats ne permettent pas d’écrire « une bonne UX augmente la conversion de x % ». Le commerce, le prix, le trafic, la marque et l’opération influencent le résultat. Ils montrent en revanche que les erreurs observables sont fréquentes et qu’une démarche de preuve coûte moins cher qu’une certitude esthétique.
3. Le dossier de friction : partir d’un événement, pas d’un écran
Imaginez un devis B2B. L’équipe marketing constate beaucoup de visites et peu de demandes. Le directeur veut raccourcir le formulaire. Le commercial demande au contraire davantage de qualification. Le développeur signale que certains champs viennent du CRM. Le designer propose un formulaire en trois étapes.
Quatre solutions apparaissent avant que le problème soit établi.
Le dossier de friction commence autrement. Il rassemble l’intention de la page, la source du trafic, le taux d’entrée, la progression champ par champ, les erreurs, le temps, les abandons, les demandes reçues, leur qualification, les retours du support et quelques sessions observées. On découvre parfois que le formulaire n’est pas le problème : l’offre reste floue, les preuves arrivent trop tard ou le délai de réponse commercial détruit la confiance après l’envoi.
Cette enquête évite l’optimisation locale. L’expérience traverse le site et l’organisation.
4. Cinq niveaux de preuve pour concevoir un parcours web
4.1. Niveau 1 — Comprendre le travail de l’utilisateur
La recherche ne vise pas à demander aux personnes quelle interface elles souhaitent. Elle cherche à comprendre une situation : déclencheur, objectif, étapes actuelles, information disponible, contraintes, contournements, critères de confiance et coût d’un échec.
Les sources se complètent : entretiens, observation, tickets support, appels commerciaux, recherche interne, analytics, enquêtes et retours d’accessibilité. Cinq entretiens ne représentent pas statistiquement un marché. Ils peuvent toutefois révéler des modèles de comportement et des questions que la donnée agrégée masque.
Le GOV.UK Service Manual recommande de commencer par les besoins et de traiter les opinions des parties prenantes comme des hypothèses jusqu’à leur confrontation au terrain. La méthode convient aussi aux entreprises privées : une demande hiérarchique n’est pas une preuve utilisateur.
Sortie de recherche : note de recherche, situations prioritaires, carte du parcours actuel, risques d’exclusion, inventaire des preuves et questions encore ouvertes. Les personas décoratifs ne sont pas obligatoires.
4.2. Niveau 2 — Donner une architecture au choix
L’architecture d’information décide ce qui est regroupé, nommé, ordonné et rendu accessible. Elle part des questions et objets que les utilisateurs cherchent, puis les rapproche des capacités de l’entreprise.
On peut tester une arborescence avec un tri de cartes, un tree test ou des tâches sur prototype basse fidélité. L’objectif n’est pas de faire voter le menu. Il est de vérifier que les termes orientent et que les personnes trouvent le chemin sans connaissance de l’organigramme.
Le contenu intervient ici. Un CTA « En savoir plus » ne révèle pas la destination ; un titre générique ne permet pas de comparer ; une preuve non contextualisée ne rassure pas. Content design et UX sont la même conversation sur deux supports différents.
Sortie d’architecture : modèle de contenu, arborescence argumentée, nomenclature, chemins critiques, règles de navigation et contenus de preuve.
4.3. Niveau 3 — Rendre les erreurs visibles dans le prototype
Un wireframe de parcours doit montrer davantage que le cas idéal. Il couvre au minimum : champ vide, valeur invalide, donnée déjà connue, étape interrompue, session expirée, erreur serveur, absence de résultat, succès, confirmation et possibilité de revenir.
Testez une tâche entière avec des données plausibles. La personne doit comprendre où elle se trouve, ce qui est demandé, pourquoi, comment corriger et ce qui se passera ensuite. Chronométrer seul est insuffisant : une tâche rapide mais incomprise peut générer une erreur métier coûteuse.
Le protocole précise le scénario, les critères de réussite et les points que l’équipe cherche à apprendre. Le facilitateur ne défend pas la maquette. Il observe ce que l’interface permet sans assistance.
Livrables utiles : prototype testable, scénarios, journal d’observation, décisions prises et problèmes laissés ouverts.
4.4. Niveau 4 — Transformer l’UI en système de comportements
La direction visuelle doit servir la hiérarchie et la marque, mais un système UI va plus loin. Chaque composant possèd'un usage, un contenu attendu, des variantes, des états, des règles responsive, des exigences d’accessibilité et une implémentation associée.
Un bouton ne se limite pas à trois couleurs. Il faut préciser libellé, importance, focus, survol, activation, chargement, désactivation, largeur, icône et réaction à un texte long. Une modale exige déclencheur, focus initial, fermeture, retour du focus, comportement clavier et alternative si le contenu devient dense.
Le GOV.UK Design System combine tests automatisés, manuels et recherche avec des personnes handicapées. Cette combinaison est la bonne unité de qualité : le composant documenté, implémenté et éprouvé — pas son rectangle dans Figma.
Livrables utiles : fondations visuelles, bibliothèque de composants, documentation d’usage, prototype haute fidélité, spécifications responsive et inventaire des exceptions.
4.5. Niveau 5 — Vérifier le service après la mise en ligne
Le lancement permet enfin d’observer le comportement réel, la performance terrain et l’effet opérationnel. Il faut avoir créé un état de référence avant la refonte et instrumenté des événements signifiants.
Trois familles de mesures protègent des conclusions faciles :
- résultat : achat, demande qualifiée, activation, résolution, délai ou coût ;
- expérience : réussite de tâche, progression, erreurs, retour, satisfaction contextuelle ;
- garde-fous : accessibilité, performance, tickets, annulations, fraude, charge support.
Un taux de clic plus élevé n’est pas un succès si les demandes deviennent moins pertinentes. Une conversion apparente peut résulter d’un changement de trafic. Pour attribuer un effet, utilisez selon le volume comparaison avant/après contextualisée, test A/B, déploiement progressif ou recherche qualitative répétée.
Livrables utiles : plan de mesure, tableau de bord de parcours, backlog d’amélioration, revue mensuelle et registre des décisions.
5. Tests, erreurs et prototype : la revue qui évite une fausse validation
La revue ne demande pas « aimez-vous cette page ? ». Elle donne une tâche. Elle observe un résultat. Elle consigne les hésitations.
Avant une validation de direction, montrez au moins un cas heureux, une donnée longue, une absence de résultat, une erreur récupérable et une erreur bloquante ; cette sélection révèle beaucoup mieux la maturité du parcours que trois variantes esthétiques de la page d’accueil.
Le journal de décision distingue ensuite le fait observé, l’interprétation, l’arbitrage et le risque accepté. Court, mais décisif. Cette trace empêche une préférence exprimée tardivement de se présenter comme un apprentissage utilisateur et donne au développement le contexte nécessaire lorsqu’un compromis technique apparaît.
6. Adapter la méthode au risque, pas au prestige du projet
| Contexte | Recherche minimale crédible | Niveau de prototype | Validation avant lancement |
|---|---|---|---|
| Page éditoriale à faible risque | Analytics, recherche, contenu et quelques entretiens ciblés. | Contenu/wireframe responsive. | Relecture, accessibilité, SEO et performance. |
| Génération de leads B2B | Analyse des leads, appels commerce, tests de proposition. | Parcours complet avec erreurs et confirmation. | Tâches, tracking, CRM, qualité des demandes. |
| Checkout e-commerce | Données funnel, support, sessions, benchmark contextuel. | Mobile haute fidélité avec paiement et reprise. | Utilisabilité, accessibilité, performance, paiement et fraude. |
| Application métier quotidienne | Observation du travail, exceptions et coûts d’erreur. | Prototype interactif sur cas réels. | Pilote, droits, données, continuité et formation. |
| Service réglementé ou critique | Recherche inclusive, expertise juridique et analyse de risque. | Simulation de chemins heureux et dégradés. | Tests formels, audit, traçabilité, sécurité et reprise. |
La méthode légère n’est pas une méthode absente. Elle choisit les preuves les moins coûteuses capables de réduire le risque dominant.
7. Coûts, délais et responsabilités
Le budget UX/UI dépend moins du nombre d’écrans que du nombre de situations à comprendre, de rôles, d’états, de systèmes reliés, de langues et de niveaux de preuve. Une page complexe mais statique peut demander moins de travail qu’un formulaire court avec dix exceptions métier.
Une estimation complète sépare : recherche, architecture/contenu, prototypage, tests, direction UI, composants, spécifications, accompagnement du développement, design QA et mesure. Elle précise aussi qui recrute les participants, fournit les données, tranche les règles, valide l’accessibilité et maintient le système.
Repères Logiks, non statistiques : deux à trois semaines peuvent suffire à cadrer un parcours compact lorsque la connaissance existe ; quatre à huit semaines conviennent souvent à un cycle recherche-prototype-test ; un produit complexe demande plusieurs cycles au fil du delivery. Comprimer le calendrier est possible en réduisant le périmètre testé, pas en prétendant que la recherche ou la recette ont eu lieu.
| Acteur | Responsabilité décisive | Preuve d’achèvement |
|---|---|---|
| Sponsor / product owner | Résultat, priorité, règles et arbitrages. | Décisions rapides, mesure et critères d’acceptation. |
| UX / recherche | Problèmes, parcours, tests et synthèse. | Observations traçables et recommandations reliées à une preuve. |
| Content design | Compréhension, ordre, messages, erreurs et aide. | Contenus testés dans les vrais composants. |
| UI / design system | Hiérarchie, états, cohérence et spécifications. | Composants documentés et vérifiés en implémentation. |
| Développement | Comportement réel, performance et compatibilité. | Version testable, états complets, instrumentation et corrections. |
| Data / CRO | Mesure, qualité des événements et attribution. | Baseline, taxonomie, QA et lecture contextuelle. |
| Accessibilité | Méthode, tests manuels et couverture assistive. | Résultats, écarts, priorités et contre-tests. |
8. Ce qu’une bonne prestation UX/UI doit livrer
Méfiez-vous de deux extrêmes : le dossier de cent pages jamais relu et les maquettes sans raisonnement. Les livrables doivent permettre une décision ou une production.
À la fin, l’équipe devrait disposer d’un problème formulé, de parcours prioritaires, de contenus représentatifs, d’un prototype couvrant erreurs et reprises, de résultats de tests, d’un système UI proportionné, de critères d’acceptation, d’un plan de mesure et d’un backlog ordonné. Les fichiers sources, droits, conventions et responsabilités de maintenance doivent être transmis.
La qualité se vérifie dans le produit intégré. Le design QA compare comportement, contenu, responsive, focus, performance et états — pas seulement l’alignement au pixel.
9. Conseils Logiks : reconnaître la fausse UX
- L’équipe parle de « l’utilisateur » au singulier sans montrer une observation récente.
- La recherche commence après le choix de la solution.
- Le prototype ne contient ni erreur, ni attente, ni donnée longue.
- Tous les problèmes sont résolus par une nouvelle fonctionnalité.
- Le design system grandit alors qu’aucune équipe ne le possède.
- L’accessibilité est confiée à un plugin ou à un audit juste avant lancement.
- Le succès se réduit au taux de conversion sans qualité commerciale ni garde-fou.
- Le prestataire livre Figma mais pas les décisions, résultats de tests et règles d’usage.
Notre position : demandez moins d’écrans de démonstration et davantage de preuves sur les moments où une personne hésite, se trompe ou abandonne.
10. Plan d’action sur 60 jours
10.1. Semaines 1 et 2 — Construire le dossier de friction
- choisir une tâche et une mesure métier ;
- rassembler données, support, commerce et contenu ;
- observer ou interroger les profils prioritaires ;
- cartographier parcours, contraintes et exclusions ;
- nommer les inconnues les plus risquées.
10.2. Semaines 3 et 4 — Tester la structure
- prototyper avec de vrais messages ;
- inclure erreurs, états vides et reprise ;
- tester les tâches sur mobile et clavier ;
- arbitrer les règles avec produit et opérations ;
- documenter ce qui change et pourquoi.
10.3. Semaines 5 à 8 — Mettre le système à l’épreuve
- finaliser hiérarchie et composants nécessaires ;
- accompagner l’implémentation ;
- exécuter design QA, accessibilité et performance ;
- recetter les événements de mesure ;
- ouvrir progressivement et lancer la boucle d’amélioration.
11. FAQ
11.1. Quelle différence entre UX design et UI design ?
L’UX organise le service, les parcours, l’information, les efforts et les preuves. L’UI matérialise la hiérarchie et les interactions dans un système visuel. Les deux se chevauchent et doivent travailler avec le contenu et le développement.
11.2. Combien coûte une mission UX/UI ?
Le coût varie selon la recherche, le nombre de situations et rôles, le niveau de prototype, les tests, le système UI et l’accompagnement du développement. Comparez des prestations sur leurs preuves et leur couverture, pas sur un prix par écran.
11.3. Combien d’utilisateurs faut-il tester ?
Il n’existe pas de nombre universel. Quelques sessions peuvent révéler des problèmes majeurs dans un cycle qualitatif ; elles ne mesurent pas leur fréquence dans la population. Répétez les tests sur les profils et risques distincts, puis utilisez des données quantitatives lorsqu’une estimation est nécessaire.
11.4. Un design system est-il toujours nécessaire ?
Un ensemble cohérent de styles et composants est nécessaire. Une plateforme complète avec gouvernance dédiée ne l’est pas toujours. Commencez par les éléments réellement utilisés, documentez les règles et ne créez une infrastructure plus lourde que lorsque plusieurs équipes en tirent un bénéfice.
11.5. Comment mesurer le ROI du design ?
Reliez une friction à une métrique métier, créez une baseline, déployez un changement traçable et surveillez résultat, expérience et garde-fous. Le design contribue au résultat avec le trafic, l’offre, le prix, la technique et les opérations ; évitez de lui attribuer seul toute variation.
11.6. L’accessibilité limite-t-elle la créativité ?
Elle impose des critères d’usage, pas une esthétique uniforme. Contraste, focus, structure, alternatives et contrôle des animations obligent à concevoir plus précisément. Une direction créative reste possible si le système prévoit ses usages réels.
12. Conclusion
L’UX/UI design de fond ne livre pas seulement une apparence. Il transforme des suppositions en parcours testés, des choix visuels en comportements documentés et des objectifs en mesures vérifiables.
La valeur apparaît lorsque l’équipe sait expliquer quelle friction elle réduit, pour qui, avec quelle preuve et sans déplacer le coût ailleurs. L’interface devient alors un outil de décision, pas un décor validé en comité.
13. Sources principales
- Baymard Institute — Cart abandonment rate statistics, mise à jour septembre 2025.
- Baymard Institute — Reasons for cart abandonment, données 2025.
- Baymard Institute — How to reduce cart abandonment, consulté le 13 juillet 2026.
- GOV.UK Service Manual — How the discovery phase works, consulté le 13 juillet 2026.
- GOV.UK Service Manual — Start by learning user needs, consulté le 13 juillet 2026.
- GOV.UK Design System — Accessibility strategy, consulté le 13 juillet 2026.
- WebAIM — The WebAIM Million 2026, février 2026.
- web.dev — How the Core Web Vitals thresholds were defined, mis à jour en mai 2025.
- HTTP Archive — Web Almanac 2025, Performance, publié en 2026.
- W3C — Web Content Accessibility Guidelines 2.2, recommandation W3C.