Comment créer un design system accessible et livré en 30 jours pour une startup sans designer senior

J'ai souvent entendu la remarque : "On n'a pas de designer senior, on n'a 30 jours, est-ce réaliste de livrer un design system accessible ?" Ma réponse : oui — si on accepte un scope MVP, une méthodologie pragmatique et une discipline pour prendre les bonnes décisions rapidement. Voici comment j'ai procédé plusieurs fois avec des startups : process, livrables, outils et pièges à éviter pour sortir un design system utile, utilisable et conforme aux bases de l'accessibilité en un mois.

Définir l'objectif et le périmètre MVP

La première erreur est de vouloir tout couvrir. Un design system peut devenir un monstre si on cherche à intégrer chaque composant et variante dès le début. Je propose de viser un MVP qui réponde aux besoins immédiats de l'équipe produit et technique :

• Les composants critiques : boutons, champs de formulaire, messages d'erreur, cartes, en-têtes et footer.
• Tokens de base : couleurs, typographie, espaces et ombres.
• Principes d'accessibilité essentiels : contraste, focus visible, labels pour les formulaires.
• Documentation minimale : comment utiliser, variantes, bonnes pratiques d'implémentation.

Avec ce périmètre, l'objectif devient atteignable en 30 jours, même sans designer senior — à condition d'impliquer au moins une personne technique (développeur front) et une personne produit.

Jours 0–3 : audit rapide et alignement

On commence par un audit express : collecter les écrans clés (landing, onboarding, dashboard, formulaires importants). Je passe en revue 10 à 15 écrans représentatifs pour identifier les patterns récurrents et les écarts.

• Recenser les composants existants et noter les duplications.
• Mesurer les contrastes avec un outil comme Accessible Colors ou l'extension Chrome axe.
• Prioriser les composants selon fréquence d'utilisation et criticité.

Ensuite, atelier rapide (1h) avec PO et dev : valider le périmètre MVP et identifier la personne qui sera "tutrice" du design system côté produit et côté dev.

Jours 4–10 : tokens, palette et typographie

Les tokens sont la colonne vertébrale. Je définis d'abord la typographie (familles, tailles, poids, interlignage) puis la palette :

• Couleurs primaires et secondaires avec variantes (hover, active).
• Couleurs neutres pour surfaces et textes.
• Couleurs d'alerte (success, info, warning, error).

Important pour l'accessibilité : vérifier le contraste texte/fond pour toutes les combinaisons normales et états désactivés. J'utilise Color Contrast Analyzer et j'ajuste les couleurs pour atteindre au minimum le standard WCAG AA pour le texte normal, et AAA si possible pour les textes clés.

Livrables : fichier tokens JSON (ou format design token standard comme Style Dictionary), page documentation sommaire dans Figma ou Notion.

Jours 11–18 : composants atomiques et règles d'usage

On construit les composants en commençant par les plus simples. Ma séquence préférée :

• Boutons (primary, secondary, ghost) + états (hover, focus, disabled).
• Input text, select, checkbox, radio — avec labels et messages d'erreur.
• Cards, modals et barres de navigation.

Pour chaque composant, je documente :

• Variantes disponibles.
• Quand l'utiliser (do) / quand ne pas l'utiliser (don't).
• Notes d'accessibilité : rôle ARIA, comportement du focus, ordre tab.

Techniques : je travaille dans Figma pour la bibliothèque visuelle et je crée un repo Storybook (React ou Vue) pour les composants techniques. L'idéal est d'avoir une correspondance 1:1 entre les composants Figma et les composants dans Storybook.

Jours 19–24 : accessibilité pratique et tests

Plutôt que des principes vagues, j'implémente des règles testables :

• Focus visible : outline non supprimé et design cohérent.
• Labels explicites pour tous les champs ; attribut aria-describedby pour erreurs.
• Ordre tab logique et tests au clavier (toutes les interactions doivent être réalisables sans souris).
• Tests d'écran lecteur avec NVDA ou VoiceOver sur les pages clés.

Je mets en place des checks automatisés dans CI : axe-core ou Pa11y sur les stories critiques. Ces outils évitent la régression accessibilité à chaque PR.

Jours 25–28 : documentation pragmatique

La documentation n'a pas besoin d'être encyclopédique : elle doit être claire et actionnable. J'organise :

• Une page "Getting started" : comment installer les tokens (npm, CDN), importer la librairie CSS ou le composant React.
• Guides rapides : "Créer un bouton", "Formulaire accessible".
• Checklist accessibilité à appliquer avant chaque release.

Outils pratiques : Notion pour la documentation interne, Storybook pour démontrer les composants et Figma pour les spécifications visuelles exportables. J'intègre des snippets de code copiables et des exemples d'usage dans le contexte de l'application.

Jours 29–30 : revue, transfert et plan de gouvernance

Le dernier jour, je fais une revue croisée : designer (même junior), dev front, PO et QA passent en revue les composants et validations d'accessibilité. On corrige les points bloquants et on priorise ce qui doit être amélioré après la livraison.

Je livre :

• Repository components + tokens + Storybook déployé.
• Fichier Figma partagé et organisé en library.
• Documentation "How to contribute" et une petite roadmap (itérations 2 et 3).

Enfin, on met en place une gouvernance légère : un canal Slack/Teams dédié, une règle de revue de PR pour tout nouveau composant et un rythme de revue mensuel pour garder le système cohérent.

Checklist rapide pour tenir les 30 jours

Quelques conseils que j'applique systématiquement :

• Prioriser la consistance plus que la perfection visuelle.
• Documenter les décisions (pourquoi cette couleur, pourquoi ce padding) afin d'éviter les débats récurrents.
• Automatiser les tests d'accessibilité pour attraper rapidement les régressions.
• Livrer tôt et itérer : un design system vivant est plus utile qu'une "bible" parfaite mais inutilisée.

Si vous voulez, je peux vous fournir une checklist adaptée à votre cas (stack tech, mentalité de l'équipe) ou un template Figma/Storybook minimal pour démarrer. Travailler sans designer senior est un accélérateur de décisions — à condition d'avoir des règles claires et une volonté commune d'améliorer progressivement l'expérience pour tous.