Design system ou UI kit : quelle méthode pour vos maquettes ?

Design system ou UI kit: quelle méthode pour vos maquettes?

À première vue, les deux semblent répondre au même besoin: disposer de boutons, de champs, de typographies, de couleurs et de grilles déjà prêts afin de ne pas recommencer chaque écran depuis zéro. Puis la confusion s’installe. On appelle parfois « design system » une simple bibliothèque de composants bien rangée, comme si quelques variantes de boutons suffisaient à instituer une politique de design.

Ce n’est pas un détail de vocabulaire. Un UI kit accélère surtout la production visuelle d’une maquette web. Un design system organise la manière dont une marque conçoit, documente, développe et fait évoluer ses interfaces. Le premier fournit des pièces. Le second tente de régler la fabrique entière.

La différence entre design system et UI kit tient donc moins à la quantité de composants qu’à leur statut, à leur gouvernance et à leur capacité à survivre au-delà d’un fichier de conception.

UI kit: l’accélérateur visuel pour vos maquettes

Un UI kit est d’abord une collection d’éléments graphiques réutilisables. Dans Figma, Sketch ou Adobe XD, il peut réunir des boutons, des champs de saisie, des cartes, des menus, des icônes, des styles de texte, des palettes de couleurs et des grilles. Chaque élément est généralement décliné en variantes: état normal, survol, activation, désactivation, erreur, chargement.

Pour une équipe qui doit produire rapidement plusieurs écrans, le gain est immédiat. Le designer ne dessine pas cinq fois le même bouton; il l’insère, le paramètre et passe à la question suivante. Certains éditeurs de UI kits annoncent des accélérations qui peuvent aller de dix à cent fois pour la mise en page. Il faut évidemment prendre ces promesses avec une distance raisonnable: elles décrivent surtout le temps économisé sur les opérations répétitives, pas celui consacré à comprendre le problème, à arbitrer une hiérarchie de contenu ou à tester une interaction.

Un UI kit est une boîte à outils. Une boîte à outils peut être très bien conçue, mais elle ne dit pas nécessairement quelle maison il faut construire.

Dans une conception d’interface, cette nuance compte. Un kit peut présenter un bouton primaire bleu, un bouton secondaire gris et une série de champs impeccablement alignés sans expliquer:

• dans quelle situation le bouton primaire doit être utilisé;
• quelle action mérite visuellement la priorité;
• comment distinguer une erreur de validation d’un simple message d’information;
• jusqu’où une carte peut s’étendre sur mobile;
• quelle longueur de texte reste compatible avec la hiérarchie typographique;
• comment le composant se comporte avec un clavier, un lecteur d’écran ou une connexion lente.

Le UI kit formalise principalement l’apparence et une partie de la structure. Il ne porte pas nécessairement la logique d’usage.

Un UI kit répond à la question: « De quoi avons-nous besoin pour dessiner plus vite? » Un design system pose une question moins confortable: « Pourquoi dessinons-nous cela de cette manière, et qui en répondra demain? »

Cette efficacité visuelle est précieuse pour un prototype, une landing page, un projet éditorial ou une première version de produit. Elle permet de tester plusieurs maquettes web sans dépenser de temps dans des détails qui seront peut-être abandonnés. Pour une petite équipe, commencer par un UI kit est souvent plus rationnel que de bâtir une architecture documentaire grandiose avant même d’avoir validé le produit.

Mais un kit ne devient pas automatiquement un système parce qu’il contient beaucoup de composants. L’accumulation n’est pas une méthode. C’est parfois simplement une forme très organisée de désordre.

Le design system comme écosystème de gouvernance numérique

Un design system comprend généralement les éléments visuels d’un UI kit, mais il les inscrit dans un ensemble plus large: principes de design, règles d’usage, documentation, composants techniques, extraits de code et processus de contribution. Il relie donc la maquette, le développement front-end, l’expérience utilisateur et la cohérence de marque.

Cette dimension collective est le véritable sujet. Le design system ne sert pas uniquement à produire une interface homogène; il crée un langage commun entre designers, développeurs, product managers, rédacteurs et parfois équipes marketing. Chacun ne travaille plus seulement à partir d’une impression visuelle ou d’un fichier transmis par courriel. Les décisions sont explicitées, discutées et, idéalement, maintenues.

Le Nielsen Norman Group décrit le design system comme une collection de normes destinée à gérer le design à grande échelle, à réduire la redondance et à créer un langage commun. La formulation peut sembler institutionnelle, mais elle pointe un problème très concret: à mesure qu’un produit numérique grandit, chaque nouvelle équipe a tendance à réinventer les mêmes solutions sous des formes légèrement différentes.

Un bouton devient alors un autre bouton. Puis un troisième, qui ressemble au premier mais possède une marge différente, un rayon différent et un comportement différent au clavier. Visuellement, la variation paraît presque insignifiante. Dans le code et dans l’expérience utilisateur, elle produit une fragmentation progressive.

Un design system complet peut documenter:

• les principes qui orientent les choix d’interface et la personnalité de la marque;
• les couleurs, les typographies, les espacements, les rayons, les ombres et les règles de contraste;
• les composants réutilisables et leurs propriétés;
• les états interactifs, les comportements responsive et les cas limites;
• les consignes d’accessibilité et de rédaction des messages;
• les correspondances entre composants Figma et composants de code;
• les modalités de contribution, de validation et de publication;
• les versions successives et les conditions de migration.

On voit ici pourquoi la comparaison « design system vs UI kit » ne peut pas se réduire à une liste de fonctionnalités. Le UI kit est souvent un artefact de production. Le design system est une infrastructure de décision.

Cela ne le rend pas supérieur dans toutes les situations. Un design system demande de la maintenance, des responsables, des arbitrages et une capacité à accepter que les règles ne soient pas éternelles. Une équipe qui transforme chaque choix en procédure finit par produire une bureaucratie esthétique: tout est cohérent, rien n’est vraiment pensé.

La cohérence n’est pas une valeur absolue. Une interface peut respecter parfaitement ses composants et rester confuse, lente ou socialement indifférente. Un système trop fermé peut aussi empêcher une réponse pertinente à un contenu particulier. La normalisation facilite la production; elle ne remplace jamais le jugement.

La frontière technique: de la bibliothèque Figma au code front-end

La distinction devient plus nette lorsqu’on quitte le fichier de maquette. Un UI kit vit principalement dans un outil de conception. Il est partagé sous forme de bibliothèque, avec des composants que les designers peuvent insérer dans leurs écrans. Le design system, lui, fait le pont entre cette bibliothèque visuelle et les technologies utilisées pour construire le produit: React, Vue ou d’autres bibliothèques front-end.

Ce pont n’est pas une traduction automatique. Il faut définir ce que signifie un composant dans le navigateur, quelles propriétés il accepte, comment il gère son contenu, quels événements il déclenche et comment il reste accessible. Le bouton de Figma n’est pas encore le bouton du site. Il en est la représentation, parfois assez fidèle, parfois surtout décorative.

C’est à cet endroit que les projets découvrent les limites des bibliothèques de maquettes. Un composant peut être parfait à l’écran et impossible à maintenir dans le code. Ses variantes peuvent refléter des différences purement graphiques alors que le développeur a besoin d’une logique plus simple. À l’inverse, une implémentation technique peut imposer des contraintes que la maquette n’avait jamais anticipées.

La question n’est donc pas seulement de savoir si le design system contient le même composant dans Figma et dans le code. Il faut déterminer s’ils partagent une même intention.

Dans une petite équipe, la synchronisation entre design et code peut rester légère. Il suffit parfois d’un ensemble de composants clairement nommés, de quelques règles écrites et d’un échange direct entre les personnes concernées. Inutile de singer les grandes organisations avec une plateforme documentaire disproportionnée.

Dans une organisation comportant plusieurs produits, plusieurs équipes ou plusieurs marchés, le coût de l’absence de système devient en revanche visible. Les interfaces divergent, les décisions sont répétées, les corrections se propagent mal et les utilisateurs rencontrent des conventions contradictoires d’un service à l’autre. Le problème n’est alors plus esthétique. Il touche à la lisibilité de l’écosystème numérique.

Ce que la documentation change réellement

La documentation est souvent présentée comme l’appendice sérieux du design system. En réalité, elle en constitue la mémoire critique. Elle doit expliquer non seulement ce qu’est un composant, mais aussi quand il ne faut pas l’utiliser.

Prenons un composant de notification. Une bibliothèque visuelle peut proposer quatre couleurs et trois niveaux d’icônes. Une documentation utile précise la différence entre une information, un avertissement, une erreur bloquante et une confirmation. Elle indique la durée d’affichage, la possibilité de fermer le message, sa lecture par les technologies d’assistance et son comportement sur un petit écran.

Sans ces indications, les équipes interprètent le composant selon leur propre culture professionnelle. Le système devient alors un décor commun posé sur des usages divergents.

Atomic Design: structurer la complexité sans la fétichiser

La méthodologie Atomic Design, créée par Brad Frost, est souvent mobilisée pour organiser les composants d’un design system. Elle propose de penser l’interface par niveaux: les éléments simples, les groupes de composants, les structures plus complexes puis les pages. L’intérêt de cette approche est de donner un vocabulaire à la composition et de rendre visible la relation entre les pièces.

Elle répond à une difficulté très pratique de la conception d’interface: à partir de quel moment un élément cesse-t-il d’être un détail isolé pour devenir une unité réutilisable? Un champ de formulaire, une ligne de recherche, un bloc de filtres et une page de résultats ne doivent pas être gérés de la même manière. Les confondre crée soit des composants impossibles à modifier, soit des abstractions si générales qu’elles ne servent plus à personne.

Mais Atomic Design n’est pas une religion du morcellement. Une interface n’est pas une boîte de molécules neutres. Les composants prennent leur sens dans une tâche, un contenu, un contexte de navigation et une relation avec l’utilisateur. Découper tout ce qui peut l’être ne produit pas nécessairement une meilleure architecture; cela peut simplement multiplier les niveaux de lecture pour les personnes chargées de la maintenir.

Le modèle est utile lorsqu’il aide à répondre à des questions concrètes:

1. Quel élément se répète réellement?

Si un composant n’apparaît qu’une seule fois et ne possède pas de logique commune avec le reste du produit, sa généralisation peut être prématurée.

2. Quelle propriété doit rester flexible?

Un composant trop rigide oblige les équipes à le contourner. Un composant trop ouvert devient une coquille qui accepte toutes les incohérences.

3. Où se situe la responsabilité?

Le composant doit-il gérer seulement son apparence, ou aussi son comportement, son accessibilité et ses messages d’erreur?

4. Quelle relation entretient-il avec le contenu?

Une carte conçue pour une phrase courte ne peut pas être considérée comme universelle si elle se désagrège dès qu’un titre dépasse deux lignes.

5. Comment sera-t-il maintenu?

Un composant partagé sans responsable finit souvent par devenir une relique: toujours présent dans la bibliothèque, mais plus vraiment fiable.

L’Atomic Design aide donc à structurer la complexité, à condition de ne pas confondre structure et intelligence. Les interfaces ne sont pas plus pertinentes parce que leur nomenclature est plus sophistiquée.

Choisir entre agilité immédiate et cohérence à grande échelle

La décision dépend moins de la taille abstraite de l’entreprise que de la répétition réelle des problèmes. Un projet peut être porté par une grande marque et ne nécessiter qu’un UI kit limité pour une campagne ponctuelle. À l’inverse, une jeune entreprise peut avoir besoin très tôt d’un système si elle développe plusieurs parcours numériques destinés à évoluer rapidement.

Le bon arbitrage se construit autour de quelques situations.

Le UI kit convient lorsque le périmètre reste limité

Pour une maquette web exploratoire, une refonte ponctuelle ou un site composé d’un nombre réduit de modèles de pages, le UI kit offre une réponse directe. Il permet d’harmoniser la production, de partager une direction visuelle et de tester plusieurs scénarios sans lancer un chantier de gouvernance.

Il est particulièrement adapté lorsque:

• une seule équipe produit les écrans;
• le projet possède un périmètre clairement défini;
• le produit n’a pas encore validé ses parcours principaux;
• les composants doivent surtout accélérer le prototypage;
• le code final sera limité ou confié à une petite équipe;
• la marque accepte encore d’explorer son langage visuel.

Dans cette phase, vouloir documenter chaque exception avant d’avoir rencontré le problème revient à construire une carte très détaillée d’un territoire encore imaginaire.

Le design system devient nécessaire quand les écarts coûtent cher

Le design system prend son sens lorsque plusieurs équipes fabriquent des interfaces qui doivent rester reconnaissables comme appartenant au même ensemble. Il devient aussi pertinent lorsqu’un produit évolue pendant plusieurs années, change de technologie, s’étend à de nouveaux marchés ou doit accueillir de nombreux contributeurs.

Il est alors justifié lorsque:

• plusieurs produits partagent les mêmes parcours ou la même identité;
• les développeurs et les designers travaillent sur des cycles parallèles;
• les mêmes composants sont recréés avec des comportements différents;
• les corrections d’accessibilité doivent être propagées à grande échelle;
• les équipes consacrent trop de temps à résoudre des divergences triviales;
• le passage de la maquette au code provoque régulièrement des pertes d’information;
• la marque veut faire évoluer son identité sans réinventer chaque écran.

La rentabilité d’un design system ne se mesure pas seulement au temps gagné sur une maquette. Elle se lit dans la réduction des décisions répétées, dans la qualité des échanges et dans la capacité à corriger une erreur au bon endroit plutôt que dans vingt fichiers différents.

Le design system n’est pas un trophée de maturité numérique. C’est une réponse à une complexité qui existe déjà — ou qui menace de devenir coûteuse.

Le piège du faux système

Beaucoup d’équipes possèdent un fichier Figma appelé « Design System » qui contient une palette, deux typographies, quelques boutons et une page de composants. Ce fichier peut être utile. Il n’est pas forcément un design system au sens complet du terme.

Le problème ne vient pas du nom, mais de ce que ce nom laisse croire. Si les règles ne sont pas documentées, si les composants ne sont pas reliés au code, si personne ne décide de leur évolution et si chaque équipe peut créer une variante sans discussion, le système reste une bibliothèque visuelle enrichie.

Ce n’est pas honteux. Un UI kit bien tenu vaut mieux qu’un design system proclamé mais abandonné. La précision du périmètre est simplement plus honnête: elle permet de savoir ce que l’outil garantit et ce qu’il ne garantit pas.

Commencer petit, mais commencer au bon endroit

Un design system n’a pas besoin de naître sous la forme d’un monument. Il peut commencer par les composants qui produisent le plus de répétition ou les erreurs les plus visibles: boutons, champs, liens, messages, navigation, espacements et règles typographiques.

L’ordre de construction mérite toutefois une attention particulière. Commencer par les couleurs et les ombres est séduisant parce que le résultat est immédiatement présentable. Ce n’est pas nécessairement là que se trouve la difficulté. Les problèmes les plus coûteux apparaissent souvent dans les états, les contenus longs, les erreurs, les transitions entre mobile et desktop ou les situations d’accessibilité.

Une base utile peut s’organiser autour de quatre couches:

• Les fondations, avec les couleurs, la typographie, les espacements, les grilles et les principes de contraste.
• Les composants, avec leurs variantes, leurs états, leurs propriétés et leurs limites.
• Les modèles de parcours, qui montrent comment les composants fonctionnent ensemble dans une tâche réelle.
• La documentation et la maintenance, qui précisent les usages, les exceptions, les versions et les responsabilités.

Cette progression évite de transformer le design system en catalogue de pièces détachées. Une interface ne se juge pas uniquement sur la beauté de ses composants isolés, mais sur la manière dont ils se combinent lorsqu’un utilisateur cherche, comprend, choisit, corrige ou renonce.

Au-delà du choix d’outil, une question de culture de travail

Le choix entre UI kit et design system est souvent présenté comme une décision de méthode ou de logiciel. Figma contre une autre plateforme. Bibliothèque de composants contre documentation. Rapidité contre rigueur. Cette opposition est commode, mais elle rate le cœur du sujet.

Un design system modifie les rapports entre les métiers. Il rend certaines décisions explicites, donc discutables. Il attribue une responsabilité là où le fichier de maquette permettait encore de laisser flotter les ambiguïtés. Il transforme le composant en objet collectif, avec une histoire, des contraintes et parfois des conflits.

C’est aussi pour cela que certains systèmes échouent alors qu’ils sont techniquement bien construits. Leur interface documentaire est impeccable, leur bibliothèque de code fonctionne, leurs noms de composants sont cohérents; pourtant les équipes les contournent. Elles les contournent parce que le système est trop lent, trop éloigné des besoins réels ou trop contrôlé par une équipe centrale qui confond cohérence et autorité.

À l’inverse, un système vivant accepte les demandes, les exceptions et les remises en question. Il ne transforme pas chaque singularité en faute de goût. Il donne aux équipes un langage commun, mais leur laisse assez de marge pour répondre à une situation qui n’avait pas été prévue.

C’est là que le design rejoint la sociologie ordinaire des organisations. Les composants ne circulent jamais seuls: ils transportent des habitudes de travail, des rapports de pouvoir et une certaine idée de ce qui mérite d’être standardisé. La prétendue neutralité du système masque souvent une politique de l’interface. Qui décide qu’un parcours est suffisamment important pour devenir un modèle? Qui définit la bonne manière d’écrire une erreur? Qui peut introduire une exception?

Ces questions ne sont pas des raffinements théoriques. Elles déterminent la qualité quotidienne du produit.

Alors, UI kit ou design system?

Pour choisir, il faut regarder le niveau de complexité plutôt que le prestige du vocabulaire.

Un UI kit est le bon outil lorsque l’objectif principal est de produire rapidement des maquettes cohérentes, d’explorer une direction graphique ou de travailler sur un périmètre limité. Il réduit les tâches répétitives et donne une base commune à la conception visuelle.

Un design system est plus adapté lorsque l’interface devient un produit collectif et durable. Il relie les fondations visuelles, les composants, les comportements, le code, la documentation et les règles d’évolution. Il ne promet pas une uniformité magique; il rend les décisions transmissibles et les corrections plus faciles à déployer.

Le choix le plus raisonnable est souvent progressif. Commencer avec un UI kit solide, observer les répétitions, repérer les divergences coûteuses, puis formaliser ce qui mérite réellement de devenir un système. À l’inverse, lancer directement une démarche de design system peut se justifier si plusieurs produits partagent déjà une architecture, une marque et des équipes.

La vraie différence design system / UI kit ne se trouve donc pas dans le nombre de boutons rangés dans une bibliothèque. Elle se trouve dans la capacité de l’organisation à expliquer ses choix, à les transmettre et à les faire évoluer sans perdre le sens de l’expérience.

Reste une question, moins confortable que celle du choix d’outil: à mesure que les interfaces se standardisent, saurons-nous encore distinguer la cohérence qui aide de la conformité qui appauvrit?