Bâtir un design system quand on est seul : la méthode d'un dev-designer
Un design system n'est pas un luxe d'entreprise. C'est l'outil qui m'a permis de livrer 40+ projets sans devenir fou. Voici ma méthode complète, testée sur Cowri, Fleurielle et Éclat Couture.
Quand on développe seul, chaque décision de design est un coût. Choisir une couleur, une taille de bouton, une animation — répété 200 fois sur un projet — c'est autant d'énergie qui ne va pas à la valeur métier. Le design system n'est pas un luxe : c'est ce qui rend le solo scalable.
1. Tokens d'abord, composants ensuite
La plus grosse erreur que je vois chez les débutants, c'est de commencer par les composants (Button, Card, Input) sans avoir défini les tokens sous-jacents. Résultat : chaque composant a sa propre couleur, sa propre ombre, son propre radius. Impossible de faire évoluer le design cohéremment.
Je commence toujours par les tokens :
- **Couleurs** : primary, secondary, foreground, background, muted, destructive. Six suffisent. - **Espacements** : une échelle 4 / 8 / 12 / 16 / 24 / 32 / 48 / 64 px. Pas de 13 ni de 17. - **Typographies** : deux familles maximum (une display, une body), quatre tailles (xs, sm, base, lg, xl). - **Radius** : sm, md, lg, full. C'est tout.
Ces tokens vivent dans mon fichier `styles.css` sous forme de variables CSS, exposées à Tailwind via `@theme`. Un seul endroit à modifier pour changer toute la charte.
2. Composants minces, jamais gras
Un Button ne doit pas gérer 12 variantes, 5 tailles et 3 icônes optionnelles. Il doit gérer 3 variantes maximum (primary, secondary, ghost) et 2 tailles. Le reste est de la composition côté page.
Cette rigueur oblige le designer (moi) à réutiliser plutôt qu'à inventer. Elle oblige aussi à documenter chaque exception — et une exception documentée est souvent une exception qui n'aurait pas dû exister.
3. Le dark mode dès le premier jour
Ajouter le dark mode après coup, c'est doubler le travail. Ajouter le dark mode dès le début, c'est zéro effort supplémentaire à condition d'utiliser des tokens sémantiques (`background`, `foreground`, `primary`) et jamais de couleurs codées en dur (`bg-white`, `text-black`).
4. Documenter au fil de l'eau
Pas besoin de Storybook pour un projet solo. Une page `/design-system` dans votre app, qui liste tous les composants avec leurs variantes, suffit. Vous la consultez en développant, vous la partagez au client si besoin, elle vit avec le code.
5. Ne pas sur-standardiser
Un design system ne doit pas empêcher la créativité. Il doit la canaliser. Pour Fleurielle (site de copywriter), j'ai utilisé mes tokens habituels mais j'ai ajouté des animations spécifiques au projet, non standardisées. Ces animations vivent dans le projet, pas dans le système. C'est sain.
En résumé
Un design system solo n'a pas besoin d'être parfait. Il a besoin d'être **utilisé**. Six couleurs, huit espacements, quatre tailles de texte, trois radius — voilà 90 % de ce qu'il vous faut pour livrer des produits cohérents pendant les cinq prochaines années.