Meilleurs outils de design system pour petites équipes
Votre produit a l’air incohérent. Les boutons ne se ressemblent pas d’un écran à l’autre, les espacements dérivent de page en page, et chaque nouvelle fonctionnalité semble venir d’une autre application. Alors vous cherchez un outil de design system et vous tombez sur une liste de quinze, sans moyen de savoir lequel règle votre cas.
En bref
Si votre équipe fait moins de cinq personnes, vous n’avez presque certainement pas un problème d’outil. Vous avez un problème d’origine : les écrans sont fabriqués par des chemins différents. Dans ce cas, le bon outil est celui que vous n’aurez pas à entretenir.
Les six ci-dessous règlent des choses différentes, et l’essentiel de la frustration avec les design systems vient d’en choisir un qui règle un problème que vous n’avez pas.
Ce qu’un outil de design system doit faire
Un design system a quatre parties, et presque aucun outil ne couvre les quatre :
- les tokens, qui sont les décisions : couleur, échelle typographique, espacement, rayon d’angle ;
- les composants, qui sont ces tokens appliqués à une pièce réutilisable ;
- la documentation, qui dit quand utiliser chaque pièce et, surtout, quand ne pas l’utiliser ;
- la synchronisation, qui fait que le design et le code disent la même chose après la troisième semaine.
La quatrième est là où les design systems meurent. Les trois premières se font en un sprint. La quatrième, c’est pour toujours.
Les catégories, et à qui chacune s’adresse
Atelier de composants
Storybook. Vous développez le composant isolé de l’application, vous voyez tous ses états côte à côte, et la documentation se trouve à côté du composant qui tourne. C’est la seule catégorie où la documentation ne vieillit pas toute seule, parce qu’elle est le code lui-même.
Pour qui : une équipe avec un développeur front-end dédié. Si personne dans l’équipe n’écrit du React ou équivalent, ce n’est pas pour vous.
Outil de design
Figma. C’est là que naît le design system dans la plupart des équipes : les composants, les variantes, les variables de couleur et d’espacement. Ce n’est pas un outil de design system, c’est un outil de design qui a gagné assez de fonctions pour en devenir un.
Pour qui : tous ceux qui ont un designer. La question n’est jamais de savoir si vous utilisez Figma, mais ce que vous utilisez en plus.
Site de documentation
zeroheight et Supernova. Ils prennent ce qui vit dans Figma et dans le code et le publient sous forme de site de documentation navigable, avec gouvernance, versions et validation.
Pour qui : une organisation avec plus d’une équipe produit, où les gens qui consomment le design system ne connaissent pas ceux qui l’ont écrit. En dessous de cette taille, c’est de l’infrastructure pour un problème que vous n’avez pas encore.
Passage du design au code
Zeplin. Il organise la remise du design au développement : spécifications, mesures, ressources, ce qui a changé depuis la dernière version.
Pour qui : les équipes où design et développement sont des personnes différentes avec des rituels différents. Si le même binôme fait les deux, cette couche ne fait qu’ajouter une étape.
Constructeur de site avec système intégré
Framer. Vous montez le site avec des composants et des styles partagés, et le résultat publié est le site. La cohérence sort par construction, parce qu’il n’existe pas de seconde implémentation pour diverger de la première. Retenez ce mécanisme : c’est ce qu’il y a de plus intéressant dans toute cette page, et il revient à la fin, appliqué à un autre type de produit.
Pour qui : site marketing, portfolio, page d’atterrissage. Pas pour une application avec données et connexion, et c’est précisément là que le mécanisme se retrouve sans propriétaire.
Comparaison
| Outil | Ce dont il s’occupe | Convient à |
|---|---|---|
| Storybook | développer et documenter des composants isolés | équipe avec front-end dédié |
| Figma | créer les composants et les tokens | toute équipe avec un designer |
| zeroheight | publier la documentation pour beaucoup de monde | organisation avec plusieurs équipes |
| Supernova | documentation et automatisation des tokens vers le code | organisation avec gouvernance du design |
| Zeplin | passage ordonné du design au code | équipes où design et développement sont séparés |
| Framer | site publié avec cohérence intégrée | sites marketing et pages d’atterrissage |
Coût total : la licence est la part bon marché
Les six ont une offre gratuite ou peu chère pour une petite équipe, et c’est pour cela que la décision paraît facile au moment où vous la prenez. Les tarifs changent souvent et se trouvent derrière les liens en fin de page.
Le coût que personne ne met dans le tableur, c’est l’autre :
Quelqu’un doit l’entretenir. Un design system sans propriétaire pourrit en un trimestre. Quelqu’un relit les composants, tranche les exceptions, met à jour la documentation, discute avec l’équipe qui vient de créer le dixième bouton. C’est une vraie fraction d’une personne, chaque semaine.
Deux vérités divergent. Le composant dans Figma et le composant dans le code sont deux implémentations d’une même idée, et elles divergent. Toujours. Un outil de synchronisation aide sans régler, parce que ce qui diverge n’est pas la valeur de la couleur, c’est une décision sur un état qui n’existe que dans le code.
L’adoption n’est pas automatique. Un design system qui existe et n’est pas utilisé est pire que rien, parce que vous avez désormais deux façons de faire la même chose et un document disant qu’une seule est valable.
Pour une équipe de deux ou trois personnes, ce coût est comparable à celui de construire les écrans. C’est la raison pour laquelle tant d’équipes montent un design system, s’en servent deux mois et l’abandonnent.
Quand il faut un design system, et quand il faut seulement de la cohérence
C’est la distinction que la plupart des listes sautent, et c’est elle qui décide si vous dépensez bien ou mal.
Il vous faut un vrai design system quand plusieurs personnes construisent de l’interface en parallèle, sur des bases de code ou des produits différents, et ont besoin d’un contrat partagé. Le design system est ce contrat. Sans lui, chaque équipe invente le sien.
Il vous faut seulement de la cohérence quand le problème est que vos écrans ne se ressemblent pas. Là, la cause n’est pas l’absence de contrat, c’est l’excès d’origines : chaque écran a été fait à un moment, d’une façon, sur une décision prise sur le coup.
Et la cohérence a une solution moins chère qu’un contrat : une origine unique.
La cohérence par construction, sans l’entretien
C’est ici que nous entrons, et il vaut mieux dire d’emblée que nous sommes juge et partie. L’argument est vérifiable, jugez-le là-dessus.
C’est le mécanisme de Framer, appliqué au type de produit qu’il ne sert pas. Quand toute l’application est générée à partir d’une même bibliothèque, la dérive visuelle n’a pas le temps de commencer. Non parce que quelqu’un surveille, mais parce qu’il n’existe pas de seconde façon de faire un bouton.
Chez Fabapp, l’application générée consomme 57 composants prêts, du tableau paginé au sélecteur de date, champ téléphone avec masque par pays, envoi d’image, graphique et boîte de confirmation. Ce sont les mêmes pièces sur tous les écrans de l’application, avec les mêmes tokens de thème. La liste complète de ce que livre la plateforme est sur fonctionnalités.
Deux conséquences qui parlent à qui a déjà souffert d’un design system :
Le système refuse ce qui sort de la bibliothèque. Avant que l’application ne compile, une vérification statique rejette un composant inexistant et une propriété inventée. Un design system dans un document dépend de quelqu’un qui le lit ; celui-ci dépend du code qui passe.
Le thème est une seule décision. Couleur, typographie et rayon viennent d’un jeu de tokens appliqué à toute l’application. Changer la couleur principale est une modification, pas un balayage.
Et pour qui s’inquiète de la sortie : les composants vivent dans le code de votre application, modifiables, et le code part en ZIP ou en push vers GitHub à partir de l’offre Builder. Vous n’échangez pas l’entretien d’un design system contre une dépendance à la plateforme.
Là où cela ne sert pas. Si votre problème est de coordonner quatre équipes produit sur des bases de code qui existent déjà, rien de tout cela ne vous aide : il vous faut le contrat partagé, et la liste ci-dessus est l’endroit où chercher. Une origine unique règle la dérive, pas la gouvernance.
Changer d’outil, et ce qui survit
Si vous avez déjà quelque chose en place, deux remarques avant de migrer.
Les tokens migrent, les composants non. Couleur, espacement et typographie sont des données et voyagent bien d’un outil à l’autre. Les composants portent des décisions d’implémentation et se réécrivent, ils ne se déplacent pas. Planifiez sur cette seconde moitié.
C’est la documentation qui se perd. Le texte expliquant pourquoi le bouton tertiaire existe n’est dans aucun format exportable. S’il compte, copiez-le avant de résilier.
Construisez l’interface cohérente dont votre produit a besoin
Si ce qui vous a amené ici est un produit qui a l’air fait par cinq personnes différentes, cela vaut la peine de tester le chemin bon marché avant le chemin complet : décrivez l’application que vous voulez et regardez combien de cohérence sort gratuitement quand tous les écrans ont la même origine.
Chez Fabapp, l’offre Free ne demande pas de carte.