← Tous les articles

Systèmes de design pour startups : comment j'ai construit le mien à l'envers

J’ai construit mon système de design à l’envers. La plupart des conseils disent « attendez le product-market fit ». J’ai commencé avec des CSS custom properties dès le premier jour parce qu’un bug de CLS sur mon site personnel m’a enseigné le coût de l’absence de tokens : un Cumulative Layout Shift de 0,493 qui a nécessité deux sessions de débogage pour remonter jusqu’à une valeur d’espacement incohérente. La correction a pris 15 minutes. L’investigation a pris 3 heures. Les tokens auraient entièrement empêché le bug.1

TL;DR

Les systèmes de design résolvent des problèmes de coordination. Les développeurs solo avec un seul projet n’ont pas de problèmes de coordination entre personnes, mais ils ont des problèmes de coordination entre leur moi passé et leur moi futur. Après avoir construit le système de design tokens pour blakecrosley.com — 10 tokens de couleur, 13 étapes d’échelle typographique, 8 valeurs d’espacement — j’ai appris que la bonne séquence est : tokens immédiatement (dès le premier jour), patterns quand ils se répètent trois fois, système formel jamais (pour les projets solo). L’investissement dans les tokens est rentabilisé dès la première fois qu’une incohérence d’espacement provoque un bug de mise en page.


Mon système de design : des tokens et rien d’autre

La non-palette de couleurs

L’ensemble de mon site fonctionne avec 10 CSS custom properties sans aucune couleur de marque :

:root {
  --color-bg-dark:        #000000;
  --color-bg-elevated:    #111111;
  --color-bg-surface:     #1a1a1a;
  --color-text-primary:   #ffffff;
  --color-text-secondary: rgba(255,255,255,0.65);
  --color-text-tertiary:  rgba(255,255,255,0.4);
  --color-border:         rgba(255,255,255,0.1);
  --color-border-subtle:  rgba(255,255,255,0.05);
  --color-accent:         #ffffff;
}

Quatre niveaux de transparence (100 %, 65 %, 40 %, 10 %) portent l’ensemble de la hiérarchie visuelle. Chaque niveau de texte respecte le contraste WCAG AAA sur le fond #000000. Pas de dégradés, pas de couleurs sémantiques, pas de basculement mode sombre/clair. La contrainte produit un système cohérent qu’une bibliothèque de composants ne pourrait pas améliorer.2

La décision de ne pas utiliser de couleurs de marque était un choix de design, pas un choix technique. Au cours de mes 16 études de design produit, j’ai remarqué que les produits que je respectais le plus (Linear, Vercel, Raycast) utilisaient des palettes sobres où la typographie assurait le travail de hiérarchie.

Le système d’espacement en 8 points

Chaque valeur d’espacement dérive d’une base de 8 points :

:root {
  --spacing-xs:  0.5rem;  /* 8px */
  --spacing-sm:  1rem;    /* 16px */
  --spacing-md:  1.5rem;  /* 24px */
  --spacing-lg:  2rem;    /* 32px */
  --spacing-xl:  3rem;    /* 48px */
  --spacing-2xl: 4rem;    /* 64px */
  --spacing-3xl: 6rem;    /* 96px */
  --spacing-4xl: 8rem;    /* 128px */
}

Aucune valeur arbitraire. Le système contient huit étapes. Si une mise en page nécessite un espacement qui n’existe pas dans le système, c’est le design qui est faux, pas le système.

Le bug --spacing-2xs

J’ai appris la règle à mes dépens. J’ai utilisé --spacing-2xs pour un margin-top de sous-titre. Le token n’existait pas dans ma définition :root. Les CSS custom properties échouent silencieusement — le navigateur a appliqué aucune marge au lieu de générer une erreur. Le sous-titre s’est collé au titre, la mise en page a bougé au chargement, et mon score de Cumulative Layout Shift a bondi à 0,493.3

Le chemin de débogage : Lighthouse a signalé le CLS. DevTools a identifié l’élément qui se déplaçait. L’inspection des styles calculés a révélé margin-top: 0 là où j’attendais 4px. La recherche de --spacing-2xs dans la feuille de styles a montré une utilisation et zéro définition.

La correction : remplacer --spacing-2xs par --spacing-xs. La correction plus large : une adhésion stricte au système de tokens sans aucune exception.

L’échelle typographique

13 étapes de 12px à 80px, utilisant les polices système :

:root {
  --font-family: -apple-system, BlinkMacSystemFont, "SF Pro Text",
                 "SF Pro Display", "Helvetica Neue", Arial, sans-serif;
  --font-size-xs:      0.75rem;   /* 12px */
  --font-size-sm:      0.875rem;  /* 14px */
  --font-size-base:    1rem;      /* 16px */
  --font-size-lg:      1.125rem;  /* 18px */
  --font-size-xl:      1.3125rem; /* 21px */
  --font-size-2xl:     1.5625rem; /* 25px */
  --font-size-3xl:     1.875rem;  /* 30px */
  --font-size-4xl:     2.25rem;   /* 36px */
  --font-size-5xl:     2.7rem;    /* 43.2px */
  --font-size-6xl:     3.25rem;   /* 52px */
  --font-size-7xl:     3.875rem;  /* 62px */
  --font-size-display: 5rem;      /* 80px */
}

Les polices système éliminent entièrement la latence de chargement des polices. Pas de FOIT (Flash of Invisible Text), pas de FOUT (Flash of Unstyled Text), zéro requête réseau pour les polices. Ce choix contribue à mon score Lighthouse de 100/100 en performance.4


Le problème du timing

Trop tôt : le piège de l’abstraction prématurée

Les startups en phase d’amorçage font face à une incertitude extrême quant à ce que le produit deviendra. Un système de design encode des hypothèses sur les patterns d’interaction, la hiérarchie des composants et le langage visuel. Lorsque le produit pivote, le système de design devient un passif qui résiste au changement.5

Une équipe de trois ingénieurs et un designer n’a pas besoin d’une bibliothèque de composants avec documentation, versionnement et une instance Storybook. La surcharge de coordination dépasse le problème de coordination.

Mais les tokens sont différents. Les tokens ne sont pas des abstractions — ce sont des valeurs. Un token de couleur n’impose pas une structure de composants. Un token d’espacement ne contraint pas les patterns d’interaction. Les tokens survivent aux pivots parce qu’ils opèrent en dessous de la couche des composants.

Trop tard : la spirale de dette de design

Les entreprises en Série B avec 30 ingénieurs et aucun pattern de design partagé font face au problème inverse. Chaque équipe fonctionnalité invente ses propres styles de boutons, mises en page de formulaires et valeurs d’espacement. Le produit donne l’impression de trois applications différentes cousues ensemble.6

J’observe le même pattern à plus petite échelle dans mes propres projets. Quand je démarre un nouveau projet sans copier mes tokens :root, les incohérences apparaissent dès la première semaine. Les tokens sont une assurance peu coûteuse contre une spirale de dette qui devient coûteuse à démêler.


Le cadre d’investissement progressif

Étape 1 : Tokens uniquement (jour un, quelle que soit la taille de l’équipe)

Définissez et partagez uniquement les valeurs fondamentales. Mon implémentation :

Catégorie de token Nombre Objectif
Couleurs 10 Fond, texte, bordure, accent
Typographie 13 Tailles de police de xs à display
Espacement 8 Échelle en unités de base de 8px
Border radius 4 sm (8px), md (16px), lg (32px), xl (48px)
Transitions 3 fast (150ms), base (300ms), slow (600ms)
Layout 3 max-width narrow (800px), default (1 400px), wide (1 600px)

41 tokens au total. Zéro composant. Zéro site de documentation. L’objectif est d’empêcher la divergence au niveau des valeurs tout en préservant une flexibilité maximale pour l’expérimentation.7

Étape 2 : Extraction de patterns (quand les patterns se répètent 3 fois)

Quand le même élément d’interface apparaît dans trois fonctionnalités distinctes, extrayez le pattern. Mon site a extrait des patterns pour : - Mises en page de cartes (cartes projet, cartes blog, cartes sociales) : padding, border-radius et états hover cohérents - Soulignements de navigation (liens de nav, fil d’Ariane) : transition scaleX(0) → scaleX(1) au survol - En-tête glassmorphism : backdrop-filter: blur(20px) avec border-bottom

Chaque pattern existe parce que j’ai construit la même chose trois fois et remarqué la duplication. J’extrais les patterns du code de production plutôt que de les concevoir à l’avance. Les patterns de production encodent des exigences réelles.8

Étape 3 : Système formel (25+ ingénieurs, jamais pour les projets solo)

À grande échelle, le problème de coordination justifie des bibliothèques de composants, un miroir Figma, des processus de contribution et des changelogs versionnés. Je n’ai atteint cette étape avec aucun projet personnel et ne m’y attends pas. Pour les développeurs solo, tokens + patterns extraits fournissent suffisamment de structure sans la charge de maintenance d’un système formel.


Ce que je n’utilise pas du tout

Site de documentation

Les sites de documentation de systèmes de design destinés au public consomment du temps d’ingénierie qui ne produit aucune valeur utilisateur pour les projets solo. Ma « documentation » est le bloc :root dans critical.css. Tout développeur (ou agent IA) lisant le fichier comprend immédiatement le système.

Support multi-framework

Mon site utilise du CSS pur. Pas de composants React, pas de wrappers Vue, pas de Web Components. Les tokens fonctionnent dans n’importe quel framework parce que les CSS custom properties sont agnostiques vis-à-vis des frameworks. La couche d’abstraction, c’est CSS lui-même.

Théâtre d’accessibilité prématuré

L’accessibilité compte — mon site atteint un contraste WCAG AAA sur chaque niveau de texte. Mais j’ai d’abord construit le système de contraste (tokens avec des ratios connus) et vérifié la conformité ensuite. Commencer par des tokens qui intègrent l’accessibilité (chaque niveau de texte dépasse un contraste de 7:1) est plus efficace que d’auditer des choix de couleurs arbitraires après coup.9


Points clés à retenir

Pour les développeurs solo : - Définissez des CSS custom properties pour les couleurs, la typographie, l’espacement et les transitions dès le premier jour ; l’investissement de 41 tokens prévient les bugs et les incohérences qui coûtent des heures de débogage par la suite - Évitez les bibliothèques de composants, les sites de documentation et Storybook ; pour les projets solo, la charge de maintenance dépasse le bénéfice de coordination - Extrayez les patterns du code de production quand le même élément apparaît à trois endroits ; l’extraction prématurée gaspille de l’effort sur des patterns qui pourraient ne pas survivre à la prochaine itération

Pour les responsables design en startup : - Commencez par les tokens avant le product-market fit ; les tokens survivent aux pivots parce qu’ils opèrent en dessous de la couche des composants - Résistez au système formel tant que 25+ ingénieurs ne créent pas un véritable problème de coordination ; la formalisation avant ce seuil crée une charge de maintenance qui ralentit l’itération


Références


  1. Expérience de débogage CLS de l’auteur. Cumulative Layout Shift de 0,493 retracé jusqu’au token --spacing-2xs non défini. Documenté dans les entrées d’erreur de MEMORY.md. 

  2. CSS custom properties de l’auteur tirées de critical.css. 10 tokens de couleur, tous dérivés de relations d’opacité blanc sur noir. 

  3. Expérience de débogage de l’auteur. --spacing-2xs utilisé mais jamais défini dans :root. Les CSS custom properties échouent silencieusement, produisant une marge nulle au lieu de la valeur attendue. 

  4. Système typographique de l’auteur. Échelle de police en 13 étapes, pile de polices système. Zéro latence de chargement de polices contribuant au score Lighthouse de 100/100 en performance. 

  5. Cagan, Marty, Inspired: How to Create Tech Products Customers Love, Wiley, 2017. Product-market fit et optimisation prématurée. 

  6. Curtis, Nathan, « Adopting Design Systems », EightShapes, 2018. Mesure de la dette de design dans les entreprises en croissance. 

  7. Inventaire de tokens de l’auteur. 41 CSS custom properties réparties en 6 catégories définies dans critical.css

  8. Frost, Brad, Atomic Design, auto-publié, 2016. Méthodologie d’abstraction progressive de composants. 

  9. Approche d’accessibilité de l’auteur. Contraste WCAG AAA intégré dans les définitions de tokens (primary 21:1, secondary 13,7:1, tertiary 8,4:1).