Aller au contenu

UX et UI : quelle différence dans un vrai projet ?

Deux termes souvent employés ensemble, pour deux questions distinctes. La confusion coûte cher : elle fait chercher des solutions graphiques à des problèmes de structure.

Publié le
Rubrique
Web
Format
Repère
Lecture
05 min
Référence
FSJ-W05
Photo d’un wireframe gris posé à côté d’une maquette colorée, vue du dessus

Les deux sigles sont devenus une formule toute faite : « UX/UI ». Pratique dans une offre d’emploi, trompeuse dans un projet. Car lorsqu’un site ne fonctionne pas, la première chose à déterminer est précisément laquelle des deux questions est en cause — sinon on repeint un couloir mal placé.

Schéma
UXEst-ce que ça marche ?
  • Intentions et parcours
  • Architecture de l’information
  • Priorités et étapes
  • Cas d’erreur
UIEst-ce que c’est clair ?
  • Hiérarchie visuelle
  • Typographie et couleurs
  • États des composants
  • Contrastes et densité
Même projet, deux questions — et deux moments.

Ce que fait l’UX

L’expérience utilisateur s’intéresse au chemin. Qui vient, avec quelle intention, quelles étapes doit-il franchir, dans quel ordre, où hésite-t-il, de quelle information a-t-il besoin pour décider, et que se passe-t-il quand quelque chose échoue.

Elle produit des structures : une arborescence, un enchaînement d’écrans, une hiérarchie d’informations, des règles de priorité. Ses livrables ressemblent rarement à des images finies — ce sont des schémas, des listes, des tracés gris. C’est justement leur intérêt : à ce stade, discuter du parcours sans être distrait par les couleurs.

Ce que fait l’UI

L’interface s’intéresse à la surface : ce qui est vu, lu, compris, cliqué. Hiérarchie visuelle, typographie, espacements, couleurs, états d’un bouton — normal, survolé, actif, désactivé, en cours de chargement —, contrastes, cohérence des composants d’un écran à l’autre.

Elle ne se contente pas de « rendre joli » : elle rend le parcours lisible, signale ce qui est cliquable, distingue le principal du secondaire, et donne son ton à la marque. Une interface réussie se remarque peu — on remarque surtout qu’on n’a pas eu à réfléchir.

Reconnaître de quel problème il s’agit

  1. 01Symptôme UI« Je n’avais pas vu le bouton », « je ne savais pas que c’était cliquable », « le texte est illisible sur mon téléphone ».
  2. 02Symptôme UX« Je ne savais pas quoi faire ensuite », « je n’ai pas trouvé le tarif », « j’ai abandonné au troisième formulaire ».
  3. 03Symptôme de contenu« Je n’ai pas compris ce que vous faites » — ni l’une ni l’autre : le texte est en cause.
  4. 04Symptôme technique« C’était trop lent », « ça a planté quand j’ai validé » — aucune maquette ne réglera ça.
Si le problème disparaît en changeant une couleur, c’était de l’UI. Sinon, c’était ailleurs.

Comment elles se rencontrent

Dans un vrai projet, elles ne s’enchaînent pas proprement. On dessine un parcours, on le met en forme, et c’est en le voyant qu’on s’aperçoit qu’une étape est de trop. On revient en arrière, on simplifie, on redessine. Cet aller-retour n’est pas un défaut de méthode : c’est la méthode.

Ce qui compte, c’est de savoir à tout moment quelle question on est en train de traiter, et de ne pas laisser une discussion sur les couleurs trancher un sujet de parcours. C’est aussi pourquoi je travaille tôt dans le navigateur : certaines hésitations ne se voient que lorsque le projet bouge vraiment.

Un exemple concret

Prenons un formulaire de contact que personne ne remplit. La réponse réflexe est graphique : agrandir le bouton, changer sa couleur, ajouter une flèche. Parfois cela suffit — si le bouton était réellement invisible.

Mais souvent le problème est ailleurs : le formulaire demande douze informations là où trois suffiraient ; il apparaît avant que le visiteur ait compris ce qu’on lui propose ; il ne dit pas ce qui se passera ensuite ni sous quel délai ; il exige un numéro de téléphone alors que la personne ne veut pas être appelée. Aucune de ces causes ne se corrige au crayon de couleur.

La méthode est la même dans tous les cas : décrire le parcours réel, repérer l’endroit exact où l’on renonce, puis se demander si c’est l’écran qui gêne ou la demande elle-même.

Ce que ça implique dans un projet

Une conséquence pratique : ne demandez pas des maquettes avant d’avoir validé une structure. Une belle maquette fige les discussions — une fois que tout le monde a vu les couleurs, plus personne ne veut rouvrir le parcours. C’est pourquoi les premières étapes se présentent volontairement en gris.

Une autre : testez avec des personnes extérieures, même trois ou quatre. Elles ne vous diront pas quoi faire, mais elles vous montreront où elles hésitent, et l’hésitation est l’information la plus utile d’un projet.

À retenir

L’essentiel en 4 points.

  • 01L’UX répond à « est-ce que ça marche pour la personne ? ».
  • 02L’UI répond à « est-ce que c’est clair et juste à l’écran ? ».
  • 03Un problème d’UX ne se corrige pas en changeant les couleurs.
  • 04Dans un vrai projet, les deux avancent en aller-retour, pas en cascade.
Tout le Journal →