Contexte
Un logiciel dont les erreurs se paient sur le plancher d'usine
CONFORMiT développe une plateforme de gestion santé, sécurité et environnement déployée dans les mines, la métallurgie et les pâtes et papiers. Les utilisateurs ne sont pas devant un bureau. Ils remplissent une analyse de risques sur un plancher d'usine, dans le bruit, avec des gants, souvent sans connexion fiable.
La plateforme couvre une dizaine de modules : analyses de risques, procédures, permis, inspections, incidents. Chacun a son propre designer.
Le problème
Quand chacun possède son module, le produit se fragmente sans que personne le remarque
La fragmentation ne se voit jamais d'un seul écran. Elle apparaît quand un utilisateur passe d'un module à l'autre et doit réapprendre où se trouve le bouton d'enregistrement, comment se comporte un champ obligatoire, ce que signifie une couleur d'alerte.
Aucune bibliothèque existante ne réglait ça pour nous. Les cadres du marché sont pensés pour des objets génériques. Une analyse de risques, un cadenassage, un permis de travail à chaud n'ont pas d'équivalent dans un kit d'interface.
Mon rôle
Concevoir le système et diriger les gens qui l'utilisent
CONFORMiT n'a pas de filière de gestion dédiée. Je porte donc le travail de conception de niveau principal, le leadership technique et la gestion de l'équipe design en même temps. Sur ce projet, ça voulait dire définir l'architecture du système, puis passer autant de temps à le faire adopter qu'à le construire.
- Architecture du système, conventions de nommage et documentation
- Répartition du travail entre trois à cinq designers, chacun sur son module
- Critiques de design hebdomadaires pour arbitrer les cas limites
- Partenariat direct avec les développeurs front-end sur l'implémentation
- Suivi du statut de chaque famille de composants, validée ou en chantier, comme une feuille de route plutôt que comme une bibliothèque figée
- Conception et tenue de la base de gouvernance du système, montée à la main
Les contraintes
Ce qui a dicté les décisions
Le terrain
Cibles tactiles utilisables avec des gants, contrastes lisibles en éclairage difficile, états clairs quand la connexion tombe.
La densité
Des formulaires longs et réglementaires. Impossible de simplifier en retirant des champs : chacun existe pour une raison légale.
Deux plateformes
Web et mobile, avec des contextes d'usage opposés. Le bureau pour analyser, le mobile pour saisir sur place.
Quinze développeurs
Un ratio de trois développeurs front-end pour un designer. Le système devait être plus rapide à utiliser qu'à contourner.
Ce qu'on a construit
Plus de cent composants, montés à la main
Pas de cadre préexistant, pas de bibliothèque achetée. Chaque composant a été conçu, documenté et éprouvé sur un cas réel avant d'entrer dans le système. Les objets propres au domaine ont reçu leurs propres patrons plutôt que d'être bricolés à partir de composants génériques.
Structure du système : fondations, composants, patrons de domaine.
À récupérer depuis Figma.
L'accessibilité est portée par le système lui-même. Contrastes, navigation au clavier et lecteurs d'écran sont réglés au niveau du composant. Un designer qui utilise le système obtient un écran conforme sans y penser, et c'est la seule façon que l'accessibilité tienne à l'échelle.
Le terrain descend jusque dans les composants
La contrainte la plus structurante du produit est l'absence de connexion. Elle n'a pas été traitée écran par écran, mais comme un composant du système : un indicateur réseau, décliné pour le web et pour le mobile, qui dit à la fois que la connexion est perdue et que les données ne sont pas encore synchronisées.
Un composant plutôt qu'une fonctionnalité, ça veut dire que tous les modules héritent du même comportement en même temps. C'est la différence entre un produit qui gère le hors-ligne et un produit qui l'a prévu.
Même logique pour les vignettes ISO, les pictogrammes normalisés de sécurité. Aucune bibliothèque du marché ne les fournit, et c'est précisément le genre d'objet qui justifie de bâtir un système propre au domaine.
La gouvernance
Un système qui n'est pas suivi n'est qu'une bibliothèque
Dessiner les composants était la moitié du travail. L'autre moitié a été de savoir, à tout moment, où en est chacun d'eux. J'ai monté à la main une base de gouvernance qui suit le système au-delà de Figma.
Parité web et mobile
Chaque composant existe en deux variantes suivies séparément. Le mobile n'est pas une adaptation, c'est une version à part entière avec son propre statut.
Versionnage
Un numéro de version par variante, pour que designers et développeurs parlent de la même chose quand ils parlent d'un bouton.
Correspondance vers le code
Chaque composant de design pointe vers son équivalent implémenté. Sans ce lien, un système se met à diverger sans que personne le voie.
Statut jusqu'au développement
Un composant livré en design mais pas encore construit reste marqué comme tel. La définition de terminé s'arrête au produit, pas à la maquette.
La base réunit aussi les projets, les versions, la documentation et les tâches. C'est ce qui permet de répondre en quelques secondes à la question qui tue un design system quand on ne peut pas y répondre : est-ce que ce composant existe déjà, et dans quel état ?
L'adoption
La partie que personne ne montre dans un portfolio
Un design system que personne n'utilise est une bibliothèque Figma bien rangée. L'adoption s'est jouée sur des choses peu spectaculaires : être présent au moment où un développeur rencontre un cas non couvert, régler ce cas en heures plutôt qu'en semaines, et documenter la réponse pour que la question ne revienne pas.
Décisions et compromis
Trois arbitrages que je referais
Le domaine avant le générique
Créer des patrons propres à la SST plutôt que d'assembler des composants génériques. Plus long au départ, mais chaque module y gagne ensuite.
Documenter la réponse, pas juste le composant
La documentation dit pourquoi un composant existe et quand ne pas l'utiliser. C'est ce qui réduit les questions répétées.
L'accessibilité en amont
Réglée au niveau du composant plutôt que vérifiée fonctionnalité par fonctionnalité. Le seul modèle qui tient quand vingt personnes livrent en parallèle.
Ne pas alléger les formulaires
La tentation était de réduire le nombre de champs. La bonne réponse était de clarifier la progression, parce que les champs sont exigés par la réglementation.
Ce que j'en retiens
Un design system est un problème d'équipe déguisé en problème de composants
La partie conception a été la plus courte. Le reste a été de la coordination : arbitrer entre des designers qui résolvaient des problèmes voisins, convaincre des développeurs pressés, et accepter que le système bouge à mesure que le produit bouge.
Ce que je ferais différemment. Instrumenter l'usage dès le départ. Nous n'avons pas d'analytique produit, alors je sais que le système est adopté parce que je le vois, pas parce que je peux le mesurer. C'est la première chose que je mettrais en place ailleurs.