Structurer le design dans un contexte de contraintes techniques fortes

J'ai rejoint Tixeo comme product designer sur les interfaces B2B de visioconférence sécurisée. Rapidement, il est devenu clair que le vrai défi n'était pas de designer de nouvelles features, mais de structurer le design dans un environnement où aucun système cohérent n'existait et où les contraintes techniques (sécurité, souveraineté, stack legacy) imposaient des limitations fortes.

L'interface accumulait des incohérences visuelles et comportementales au fil des itérations. Aucune hiérarchie claire n'existait entre les composants de base et les patterns complexes, ce qui rendait impossible de savoir quels éléments réutiliser et comment les combiner. Chaque designer travaillait en silo, chaque développeur implémentait ses propres patterns. Cette fragmentation ralentissait le design et multipliait les allers-retours.

Les contraintes techniques (architecture legacy, stack spécifique, limitations liées à la sécurité) rendaient impossible l'adoption de solutions standards. L'enjeu était de créer une architecture de tokens hiérarchisée et une organisation claire des composants tout en restant pragmatique. L'objectif n'était pas la perfection immédiate, mais de poser des fondations solides qui permettent l'adoption et l'itération.

J'ai initié et structuré les fondations du design system Tixeo en collaboration étroite avec l'équipe de développement. Mon rôle combinait audit de l'existant, définition de la structure système, et création des premiers composants documentés.

01 Audit de l'existant et identification des patterns Inventaire complet des composants utilisés dans l'interface, identification des incohérences, et détection des patterns réutilisables. Analyse des contraintes techniques pour comprendre ce qui était techniquement faisable.

02 Définition de la structure tokens Création d'une architecture de tokens (couleurs, typographie, espacements) adaptée aux contraintes techniques et alignée avec les possibilités d'implémentation. Collaboration dev pour valider la faisabilité.

03 Création et documentation des composants Design des premiers composants réutilisables (boutons, inputs, modales, états) avec variants, états, et cas d'usage. Documentation des guidelines d'usage avec do's & don'ts.

04 Intégration dans le workflow Scrum Intégration du design system dans les sprints 3 semaines. Collaboration quotidienne avec les développeurs pour valider l'implémentation, itérer sur les composants, et assurer l'adoption progressive.

05 Maintenance et évolution Mise à jour continue du système en fonction des besoins produit, des retours dev, et des nouvelles contraintes techniques identifiées.

Partir de l'existant, pas d'une page blanche

Plutôt que de tout reconstruire from scratch, l'audit de l'existant a permis d'identifier les patterns déjà utilisés et de les formaliser. Cette approche a facilité l'adoption : les développeurs reconnaissaient des composants qu'ils utilisaient déjà, simplement mieux structurés et documentés.

Les incohérences identifiées (variations de boutons, espacements arbitraires, couleurs non-systématiques) ont été consolidées progressivement. Chaque sprint incluait des tâches de nettoyage et de migration vers les nouveaux composants.

Construire avec les contraintes techniques

L'architecture de tokens a été pensée en collaboration directe avec les développeurs pour s'assurer qu'elle s'intégrait naturellement dans la stack existante. Les limitations techniques ont guidé les choix de design plutôt que de les bloquer.

Chaque composant a été conçu avec ses variants et états (default, hover, active, disabled, error) pour couvrir les cas d'usage réels. La documentation incluait des do's & don'ts pour éviter les mauvaises utilisations et faciliter l'autonomie des designers et développeurs.

La collaboration rapprochée dans le cadre Scrum a permis d'itérer rapidement : design d'un composant, validation technique, implémentation, test, ajustement. Cette boucle courte garantissait que le design system restait aligné avec la réalité du code.

Un design system est une infrastructure organisationnelle

Pour moi, un design system n'est pas une bibliothèque de composants. C'est une infrastructure qui permet aux équipes de bouger plus vite ensemble, tout en maintenant la cohérence. Mon objectif était que le système réduise la dette de design plutôt que d'en créer, accélère la livraison sans sacrifier la cohérence, et crée un langage partagé entre design et développement.

Un design system doit être pragmatique

Mieux vaut un design system imparfait mais adopté qu'un système parfait que personne n'utilise. L'adoption et l'itération comptent plus que la perfection initiale. Commencer petit, avec les composants les plus utilisés, et construire progressivement est plus efficace que vouloir tout définir d'un coup.

Les contraintes techniques façonnent le système

Travailler dans un environnement contraint (sécurité, stack legacy) force à co-construire avec les développeurs dès le début. Ce n'est pas une limite, c'est une opportunité de créer un système qui s'intègre naturellement dans la réalité technique. Le design system ne peut pas exister en silo.

La documentation est aussi importante que le design

Un composant non documenté est un composant qui ne sera pas utilisé correctement. La documentation (guidelines, do's & don'ts, cas d'usage) est ce qui permet l'adoption et l'autonomie des équipes. C'est autant un livrable que les composants eux-mêmes.