UI design

L’UI design (User Interface Design, ou design d’interface) est la conception de tout ce qui apparaît à l’écran et réagit au doigt ou à la souris : boutons, menus, formulaires, icônes, typographies, couleurs, espacements, transitions. C’est la couche que l’utilisateur manipule directement, et la seule qu’il voit vraiment.

On résume souvent la discipline par une image : l’UX design décide qu’il faut une porte et où la placer, l’UI design dessine la poignée. La formule est parlante, mais elle laisse croire à un ordre de passage propre, la structure d’abord et l’habillage ensuite. Dans la pratique, la poignée change la porte. Décider qu’une action se fait dans un panneau latéral plutôt que sur une nouvelle page, c’est un choix d’interface qui modifie le parcours. Les deux disciplines avancent ensemble ou elles se contredisent.

UI design et UX design : où passe la frontière

La distinction utile n’est pas « esthétique contre fonctionnel ». Les deux sont fonctionnelles. Une couleur de bouton n’est pas un goût, c’est une instruction de lecture.

La frontière tient plutôt à ce qu’on peut trancher seul. Les questions d’UX se règlent avec des utilisateurs : quel besoin, quel parcours, quelle information à quel moment. Les questions d’UI se règlent avec des règles et des références : contraste, échelle typographique, densité, conventions de plateforme. Un designer UI peut décider seul qu’un libellé passe en gras. Il ne peut pas décider seul qu’une étape du tunnel d’inscription disparaît.

Dans une équipe de trois personnes, c’est souvent le même profil qui fait les deux, et ce n’est pas un problème. Ça en devient un quand le produit grossit et que personne ne sait plus qui arbitre quoi.

De quoi une interface est faite

La hiérarchie visuelle

Tous les éléments d’un écran n’ont pas le même poids, et le regard doit le comprendre avant la lecture. La taille des textes, la graisse des caractères, les contrastes et les espacements créent cet ordre de priorité. Un titre passe avant un paragraphe, un bouton principal se distingue d’un bouton secondaire, un message d’erreur sort du flux.

C’est le levier le plus rentable de l’interface. Sur une page d’inscription ou de paiement, remettre de l’ordre dans la hiérarchie (une seule action visible, les rassurances près du bouton, le superflu en retrait) déplace le taux de conversion plus sûrement que n’importe quel changement de palette.

L’espace

L’espace vide n’est pas de l’espace perdu. C’est lui qui regroupe ce qui va ensemble et sépare ce qui n’a rien à voir. Deux champs collés se lisent comme une paire, même si leur contenu n’a aucun rapport.

C’est souvent ce qui sépare une interface professionnelle d’une interface amateur, et presque jamais une question de richesse graphique. Les écrans qui paraissent mal finis sont rarement trop pauvres. Ils sont trop serrés.

La cohérence

Un bouton qui change d’apparence d’un écran à l’autre oblige l’utilisateur à réapprendre l’interface à chaque page. La cohérence (mêmes styles, mêmes comportements, mêmes emplacements) rend le produit prévisible, et un produit prévisible demande moins d’attention.

C’est ce besoin qui justifie un design system : un jeu de composants dont l’apparence et le comportement sont définis une fois, puis réutilisés partout.

Les mots

Les libellés de boutons, les messages de confirmation, les textes d’erreur et les états vides font partie de l’interface au même titre que les pixels. On appelle ça le microcopy, et c’est le détail le moins cher à corriger.

Un bouton « Valider » ne dit pas ce qui va se passer. « Envoyer ma candidature » le dit. Même logique pour les erreurs : « Une erreur est survenue » laisse l’utilisateur bloqué, « Ce mot de passe doit contenir au moins 8 caractères » le débloque.

L’accessibilité n’est plus optionnelle

C’est le changement le plus concret de ces dernières années, et il tombe presque entièrement sur l’UI design. L’European Accessibility Act est entré en application le 28 juin 2025. Il impose des exigences d’accessibilité à de nombreux services numériques commercialisés dans l’Union européenne, y compris à des PME au-delà des seuils prévus. Autrement dit, des ratios de contraste et des tailles de cible qui relevaient du bon goût sont devenus des seuils opposables.

Le référentiel de référence reste les WCAG, version 2.2. Trois exigences concernent directement les maquettes :

Le contraste du texte doit atteindre 4,5:1 pour le texte courant et 3:1 pour le grand texte. C’est ce qui condamne le gris clair sur blanc, très répandu dans les interfaces à la mode.

Le contraste des éléments d’interface doit atteindre 3:1. Un bouton, une bordure de champ ou une icône porteuse de sens doivent se détacher de leur fond, pas seulement le texte qu’ils contiennent.

Les cibles tactiles doivent mesurer au moins 24 par 24 pixels CSS. C’est un plancher, pas un objectif : les guides d’Apple recommandent 44 points et ceux de Google 48 dp.

S’ajoute une règle qui ne se mesure pas avec un outil : la couleur seule ne doit jamais porter l’information. Un champ en erreur signalé uniquement par une bordure rouge est invisible pour une partie des utilisateurs daltoniens. Il faut une icône, un texte, ou les deux. L’accessibilité web coûte peu quand elle est intégrée aux composants dès le départ, et très cher quand elle arrive en audit six mois après la mise en ligne.

Du wireframe à l’écran livré

Le design d’interface ne commence pas par la palette de couleurs.

Il commence par le wireframe, un schéma en gris qui fixe la disposition des éléments sans se préoccuper du style. L’intérêt de cette laideur assumée est qu’elle empêche de discuter des couleurs tant que la structure n’est pas réglée.

Vient ensuite le design visuel, c’est-à-dire l’application de l’identité graphique sur cette structure. Puis le prototype interactif, construit le plus souvent dans Figma, qui permet de cliquer dans le produit avant qu’une ligne de code existe. C’est là qu’on repère les transitions manquantes, les retours en arrière impossibles et les écrans qu’on a oublié de dessiner.

Les écrans qu’on oublie sont d’ailleurs presque toujours les mêmes : le chargement, la liste vide, l’erreur réseau, le compte expiré. Ils représentent une part importante du temps réel passé dans un produit et une part minuscule des maquettes livrées.

Faire tenir le design dans le code

Un design n’a de valeur que correctement implémenté, et l’écart entre la maquette et l’écran livré se creuse vite quand les deux mondes parlent des langues différentes.

Les design tokens résolvent une bonne part du problème. Ce sont des variables partagées qui nomment les couleurs, les espacements, les rayons et les échelles typographiques (color-primary, space-4), et que consomment à la fois l’outil de design et le code. Quand la valeur change, elle change des deux côtés. Combinés à une décomposition en composants à la manière de l’Atomic Design, ils donnent aux designers et aux développeurs frontend un vocabulaire commun. Nous détaillons cette mécanique dans notre guide sur la construction d’un design system SaaS.

Le responsive design ajoute une contrainte que les maquettes masquent : un composant n’a pas une apparence, il en a plusieurs. Dessiner trois largeurs d’écran ne suffit pas si personne n’a décidé de ce que fait le tableau à 400 pixels de large.

Ce que la génération d’interfaces par IA a changé

Produire un écran crédible coûte désormais quelques minutes. Figma Make, les générateurs de composants React et les assistants de code sortent des interfaces propres à partir d’une description. Le goulot d’étranglement s’est déplacé.

Ce qui devient rare, ce n’est plus la capacité à dessiner un écran, c’est la capacité à décider lequel dessiner et à imposer des contraintes. Une IA à qui on demande dix écrans produit dix dialectes visuels : dix nuances de bleu, quatre tailles de bouton, trois façons de gérer une erreur. Chacun est acceptable isolément, l’ensemble est incohérent. C’est exactement le problème que résolvent les tokens et une bibliothèque de composants, qui passent du statut de documentation à celui de garde-fou.

Notre lecture est que l’accessibilité et la cohérence deviennent les vrais différenciateurs, précisément parce que ce sont les deux choses qu’un générateur ne fait pas spontanément bien. Ce basculement s’inscrit dans des mouvements plus larges que nous analysons dans notre article sur les tendances UI/UX et product de 2026.

Les erreurs fréquentes

Concevoir pour soi. Le designer connaît chaque recoin du produit, l’utilisateur le découvre. Cinq tests d’utilisabilité suffisent à révéler l’essentiel des problèmes d’interface, et coûtent moins cher qu’une refonte.

Multiplier les styles. Trop de couleurs, trop de polices, trop de variantes de boutons produisent du bruit. Une palette réduite et un nombre limité de styles donnent des interfaces plus nettes, pas plus pauvres.

Ignorer les cas limites. Un bouton tient avec trois mots et déborde avec quinze. Un tableau parfait sur écran large devient illisible sur mobile. Un nom allemand fait exploser une carte dimensionnée sur des prénoms français.

Livrer le design puis disparaître. Une maquette transmise « finie » sans échange pendant le développement produit toujours un écart. Une revue conjointe sur le vrai navigateur, à mi-parcours, coûte bien moins que les corrections après livraison.

Oublier le poids. Des animations lourdes, des polices mal chargées et des images non optimisées dégradent l’expérience autant qu’un mauvais design. Une interface magnifique qui s’affiche en quatre secondes est une mauvaise interface.

FAQ UI design

Quelle est la différence entre UI design et UX design ?

L’UX design définit la logique du produit : à qui il sert, quels parcours, quelle organisation de l’information. L’UI design donne une forme concrète à cette logique : couleurs, typographies, composants, espacements, animations. Un bon UX mal habillé donne un produit utile mais repoussant. Un bel UI sur une logique bancale donne un produit joli et frustrant.

Faut-il un designer UI pour un MVP ?

Pas systématiquement. Pour un premier produit destiné à valider un besoin, une bibliothèque de composants existante et une palette sobre suffisent souvent. Deux cas justifient un designer dès le départ : un produit dont l’interface est l’argument de vente, et un produit soumis aux obligations d’accessibilité, où repasser derrière coûte plus cher que bien faire tout de suite.

Peut-on se contenter d’un template ?

Oui pour démarrer, et beaucoup de bons produits ont commencé ainsi. La limite arrive vite : un template couvre les écrans standards et vous laisse seul sur les écrans spécifiques, ceux qui font justement la valeur de votre produit. Le résultat typique est une interface cohérente sur les pages génériques et bricolée sur le cœur de métier.

Comment Polara Studio aborde l’UI design

Chez Polara Studio, l’UI design n’est pas une phase amont qu’on referme avant de coder. Nos designers travaillent dans Figma sur un design system dont les tokens et les composants correspondent à ceux qui existent réellement dans la base de code React, pas à une bibliothèque parallèle.

Nous appliquons deux règles. La première : les contrastes et les tailles de cible sont vérifiés dans la maquette, avant le développement, parce qu’un écran refusé en audit se répare rarement sans toucher à la structure. La seconde : aucun écran n’est considéré comme terminé tant que ses états de chargement, d’erreur et de liste vide n’ont pas été dessinés. Ce sont les moins gratifiants à produire et ceux que les utilisateurs rencontrent le plus souvent.