Design system

Q: Quelle est la différence entre un design system et un design kit ?

Le design kit est une bibliothèque statique de composants, un instantané qui accompagne des écrans livrés. Le design system est une bibliothèque vivante qui sert de base à tout ce qui sera conçu ensuite. C'est un produit de l'entreprise, avec sa gouvernance, sa maintenance et l'exigence d'une correspondance stricte entre ce qui est dessiné et ce qui est développé.

Q: Quels sont les exemples de design system ?

Les design systems se sont généralisés, et beaucoup sont aujourd'hui consultables en ligne. Certains font référence par leur ampleur ou leur influence, comme le Material Design de Google ou les Human Interface Guidelines d'Apple, qui cadrent la conception sur leurs plateformes respectives. Dans le secteur public français, le Système de design de l'État (DSFR) impose un socle commun à l'ensemble des sites de l'État, jusqu'aux composants et aux règles d'accessibilité. Pour explorer la variété des approches, l'association Design Systems France maintient un répertoire des design systems conçus en France, du grand groupe à la startup, avec pour chacun ses outils, sa technologie et son type d'équipe. Il est publié sur designsystems.fr.

Q: Ai-je besoin d’un design system ?

Tout dépend du contexte. Pour un site vitrine, un design kit suffit. Si ce site s'inscrit dans un écosystème plus large, plusieurs produits d'une même organisation, plusieurs équipes qui contribuent en parallèle, un design system devient pertinent pour centraliser composants et règles, site vitrine compris. Le critère n'est pas la taille de la structure mais le nombre de produits à tenir cohérents et le nombre de personnes qui y touchent. Il suppose en revanche un investissement réel, à la conception comme dans la durée.

Q: Puis-je faire évoluer mon design kit en design system ?

C'est possible si le fichier de départ est bien structuré. Le passage ne tient pas au fichier mais à ce qu'on met autour, une équipe dédiée, un processus de contribution et un rythme de revue. Sans cette organisation, le kit reste un kit avec une nouvelle étiquette.

Q: Ai-je besoin d’un design system alors que je génère tout mon code avec de l’IA ?

C'est plutôt l'inverse. Un système bien structuré et bien documenté est ce qui permet à un agent de générer du code conforme au produit plutôt qu'une interface générique. Quand le code se produit à la chaîne, les résultats se ressemblent, et la différenciation vient de ce qu'on donne à lire à la machine.

Livrable

Une bibliothèque de composants, dynamique et qui sert de référence aux designers et développeurs

Le design system décrit de manière exhaustive les composants graphiques du produit conçu (police, couleurs, taille des éléments, états des éléments : hover, focus, cliqued, etc…). Il peut être perçu comme une bibliothèque de composants. Ce kit est amené à évoluer au fur et à mesure des besoins et des nouvelles fonctionnalités. Le design system permet de faciliter le travail entre les équipes de designers et de développeurs, les deux partis ayant un référentiel commun et partageable. Du côté utilisateur, ce kit assure une cohésion globale de votre plateforme/service et permet ainsi une meilleure expérience. Attention cependant, le design system demande à répertorier chaque composant existant et à hiérarchiser/classer correctement tous vos éléments. S'il est mal fait, il peut entraîner des doublons et vous faire rapidement perdre en cohérence.

Découvrir notre offre design system

À quoi sert un design system ?

Donner aux équipes design, développement et produit un référentiel commun, où un composant a la même définition des deux côtés
Assurer la cohérence de l'ensemble des écrans d'un produit, et de plusieurs produits d'une même organisation
Propager un changement global en modifiant un token, une couleur primaire ou une typographie qui se répercute partout
Raccourcir le passage en production, les composants étant déjà arbitrés et documentés quand le développement commence
Vérifier l'accessibilité et la robustesse une fois au niveau du composant, plutôt qu'à chaque écran

Pourquoi faire un design system ?

Constater qu'un produit a perdu sa cohérence, quand les écrans ont divergé au fil des versions et des équipes
Lancer un service à forte volumétrie, beaucoup d'écrans, beaucoup de composants, plusieurs personnes qui contribuent en parallèle
Unifier plusieurs produits d'une même organisation sous un socle commun
Rapprocher les équipes design et développement autour d'une base de travail partagée

Un design system est un produit, et un produit sans équipe s’arrête. Une équipe dédiée de designers et de développeurs recueille les retours techniques et les retours utilisateurs. Le référent design organise des revues où se décide l’ajout d’un composant ou la reprise d’un existant.

Le design system est le jumeau numérique des versions développées, ce qui permet de s’assurer de la faisabilité des futurs produits et d’accélérer les mises en production. L’exigence est la correspondance stricte entre ce qui est dessiné et ce qui est développé. Le moindre écart entre les deux se paie en temps et en argent au moment de la mise en production, et c’est cet écart que l’équipe existe pour surveiller.

Reste la diffusion, qui décide de tout le reste. Un design system que personne n’utilise redevient une bibliothèque de composants jetables. La documentation doit être accessible, le fichier de la bibliothèque atteignable, et des outils comme Zeroheight ou GitHub servent à présenter le système au-delà du fichier de conception. Le référent signale les mises à jour et propose des créneaux pour accompagner ceux qui s’en servent.

Un dernier argument s’est ajouté récemment. Plus un système est structuré et documenté, plus il est facile à implémenter, y compris par des agents qui lisent la documentation et génèrent du code à partir d’elle.

Poser les fondations en variables

Une fois l'identité visuelle et la charte graphique arrêtées, les couleurs, la typographie, les styles et les espacements deviennent des variables.

Définir les tokens

Les variables alimentent des usages précis. Une couleur blue-primary nourrit background-button-primary, background-icon-primary ou border-card-hover. Changer la couleur des icônes revient alors à réassigner une variable, et la modification se propage à toutes les maquettes.

S'accorder sur une convention de nommage

Les variables fonctionnent de la même façon côté développement. Design et dev s'alignent donc sur les mêmes noms, calés autant que possible sur le framework retenu.

Assembler selon l'atomic design

Les éléments de base, boutons, listes, icônes, gabarits d'images, se combinent en composants, puis en blocs plus complexes. Une modification à la base se répercute sur l'ensemble.

Documenter et diffuser

Règles d'usage, composants, extraits de code, partis pris éditoriaux, tonalité, ce qu'il faut faire et ce qu'il faut éviter.

Votre design system doit également comporter un styleguide. Il s’agit d’une reprise de la charte graphique (couleurs, typos, logos etc) avec les règles d’utilisation de chaque élément. Par exemple, savoir quand doit être utilisé le rouge, quand doit être utilisé votre typographie n°1, etc. Avant d’entamer ce travail, priorisez les éléments qui sont les plus récurrents sur votre produit comme par exemple les boutons, les éléments de navigation (menu, footer). Une fois que votre base sera solide et correctement construite, vous pourrez passer aux déclinaisons et autres éléments. Penser à tester vos “composants parents” (le principal, qui sert de modèle) avant de réaliser des “composants enfants” (déclinaisons du principal)

Quelle est la différence entre un design system et un design kit ?

Quels sont les exemples de design system ?

Ai-je besoin d’un design system ?

Puis-je faire évoluer mon design kit en design system ?

Ai-je besoin d’un design system alors que je génère tout mon code avec de l’IA ?

Les méthodes liées

Charte graphique

La charte graphique rassemble les règles visuelles d'une marque : couleurs, typographies, logo, et les usages autorisés ou proscrits pour chacun.

Design Kit

Le design kit, ou UI kit, rassemble les composants d'un produit dans un fichier de conception : boutons, formulaires, cartes, navigation, icônes.

Architecture de l'information

L'architecture de l'information organise contenu et navigation pour que les utilisateurs trouvent ce qu'ils cherchent. Elle guide le design d'interface

Design d'interface

L'UI design conçoit la couche visuelle d'un produit : mise en page, couleurs, typographie, composants. Il traduit l'expérience en éléments tangibles.

Design pattern

Un design pattern est une solution éprouvée à un problème récurrent : breadcrumb, modal, accordéon. Ces conventions existent parce qu’elles fonctionnent pour les utilisateurs.

Figma

Figma est l'outil de design collaboratif de référence : conception, prototypage, design system et handoff dans un SaaS qui relie designers et développeurs.

Design Ops

Le design ops optimise la pratique du design : outils, processus, handoff, documentation. Il permet aux designers de se concentrer sur la conception plutôt que sur la gestion.

Grille de mise en page

La grille de mise en page structure l'interface en colonnes, gouttières et marges. Elle assure la cohérence visuelle et facilite le responsive design.

Maquettes graphiques

Les maquettes graphiques donnent leur forme définitive aux futurs écrans, à transmettre aux équipes projet en vue de l'intégration.

Atomic design

L'atomic design décompose une interface en 5 niveaux : atomes, molécules, organismes, templates, pages. C’est une des méthodes de référence derrière un design system.

Vous souhaitez en savoir plus sur nous ?

Tout le monde parle experience utilisateur, design de service, ergonomie...
C'est pas très clair, mais vous aimeriez bien découvrir tout ca ou progresser.

Parlons-en