Le présent article est fourni à titre informatif uniquement et n'est pas destiné à fournir, ni ne doit être considéré comme, un conseil juridique ou financier. Veuillez consulter vos propres conseillers juridiques ou comptables si vous avez des questions à ce sujet.

Chez Flex, nous sommes une petite équipe d'ingénieurs reconnue pour faire beaucoup avec peu, avec une forte propension à l'action. Après quelques années de changements rapides de produits et de pivots, nous avions accumulé une dette UX significative qui commençait à se traduire par une expérience peu fluide. 

Nous devions toujours livrer rapidement, mais avec une exigence de qualité beaucoup plus élevée et une compréhension commune de ce que signifiait réellement la « qualité ». Cependant, quand l'idée de créer un système de design m'a été lancée, j'ai commencé à paniquer un peu.

Ayant déjà construit deux systèmes de design, je connaissais les pièges qu'ils peuvent impliquer : travail personnalisé inutile, discussions interminables sur des futilités, documentation obsolète, etc. Nous n'avions ni le temps ni les ressources pour nous laisser entraîner par le fardeau que peuvent représenter les systèmes de design. 

La Demande

La question est rapidement devenue : « Comment pouvons-nous implémenter un système de design « léger » — un système qui apporte de la valeur sans nous ralentir ? »

La première chose à faire était d'évaluer ce qu'impliquait un système de design complet par rapport au système léger que nous visions de construire.

Systèmes de design normaux et complets

• Composants personnalisés (boutons, modales, tableaux, etc.)
• Outils personnalisés (configurations Storybook, infrastructure interne)
• Processus/gouvernance des changements
• Coûts de maintenance élevés

Systèmes de design légers

• Uniquement les composants et modèles les plus utilisés
• Facile à adopter — la documentation et le code se trouvent là où les développeurs travaillent déjà
• S'appuie sur les bibliothèques existantes au lieu de construire à partir de zéro (si possible)
• Définit des standards pour présenter l'utilisation

Nos Contraintes : Petite équipe, grands objectifs.

Nous avons commencé par une série de designs élégants, allant des composants élémentaires (boutons, champs de saisie, etc.) aux mises en page courantes et aux parcours en plusieurs étapes. 

Tout au long de ce processus, nous avons fait tout notre possible pour ne pas créer de nouveaux composants, sauf en cas d'absolue nécessité. Il était essentiel d'utiliser nos outils existants. Nous sommes une petite entreprise qui produit beaucoup chaque semaine ; la dernière chose que nous voulions était de nous enliser dans les détails de problèmes sur mesure liés à des composants personnalisés.

Si les incohérences visuelles étaient évidentes, un problème plus profond que j'avais remarqué chez Flex était l'absence d'une approche unifiée pour la création d'interfaces utilisateur courantes, comme les formulaires. On pouvait trouver dans le code cinq façons différentes d'implémenter les interfaces de formulaires. Il était clair que nous avions besoin d'une série de normes.

Création d'une série de normes unifiées

Nous avions précédemment commencé à travailler sur une section "aide-mémoire" pour les développeurs afin qu'ils disposent d'une collection de bonnes pratiques à copier/coller. C'est devenu l'endroit idéal pour présenter notre système de design émergent. Nous pouvions utiliser cet espace (renommé plus tard "Playground") pour permettre aux développeurs de consulter et d'utiliser ces normes pour nos interfaces utilisateur les plus courantes afin d'accélérer leur travail, et aussi permettre aux designers de voir que ce qu'ils avaient conçu était réellement utilisé. Enfin, le fait d'avoir cela intégré dans notre propre application web (plutôt qu'en externe, via une plateforme comme Storybook) a contribué à garantir son utilisation.

Cependant, l'histoire ne faisait que commencer. Nous avions quelques défis à relever d'abord :

1. Nous étions bloqués sur une version antérieure de notre bibliothèque d'interface utilisateur choisie et la mise à niveau représenterait un effort assez herculéen. Ce changement s'étendrait à l'ensemble de notre application client et de notre outil interne, Alfred.
2. Nous devions combiner les dépôts pour regrouper nos applications internes et web afin de garantir l'utilisation du système de design sur toutes les applications.

Après avoir franchi ces jalons, nous avons re-thématisé les deux applications pour qu'elles correspondent aux nouveaux designs et la dynamique a commencé à s'installer.

Multiplicateurs de force

Après avoir re-thématisé notre outil interne, Alfred, et l'application web, nous avons commencé à créer une série de bonnes pratiques dans Playground. Au fil du temps, Playground a regroupé le "80/20" de nos cas d'utilisation — un guichet unique pour les composants, les mises en page et les utilitaires partagés.

‍

‍

Bien que nous sachions que Playground serait bénéfique pour les développeurs pour copier/coller des composants et ainsi démarrer leur travail, cette collection de normes s'est avérée parfaite pour que les LLM comprennent comment le code d'interface utilisateur devait être généré.

Voici : Cursor

Peu de temps après que nous ayons commencé à construire Playground, notre équipe frontend a commencé à utiliser Cursor AI. Nous avons créé notre Playground de référence des règles Cursor pour l'utiliser comme point de départ lors de la génération de tout code basé sur l'interface utilisateur :

• Pour des exemples d'utilisation des composants de notre système de conception, consultez le Playground à l'adresse `src/areas/playground`.
• Lors de l'implémentation de nouveaux composants tels que les tiroirs (Drawers), les tableaux (Tables), les assistants (Wizards), les mises en page (Layouts), etc., copiez le fichier tel qu'il est implémenté dans le Playground et utilisez-le comme point de départ dans la zone sur laquelle vous travaillez.
• La plupart du temps, vous ne mettrez pas à jour de fichiers dans `src/areas/playground`, mais utiliserez simplement les composants qui s'y trouvent comme points de départ à copier dans de nouveaux dossiers dans `src/areas`.

Notre précédent effort de refonte thématique s'est avéré extrêmement payant ici, car il a ouvert la voie à Cursor pour construire des interfaces utilisateur cohérentes avec notre système de conception sans avoir à consulter de directives de style.

Pour mieux cerner ce que signifie « la qualité frontend chez Flex », nous avons codifié les normes que nous avions précédemment convenues en tant qu'équipe UI. Cursor s'y réfère en plus des règles du Playground afin que le LLM comprenne non seulement ce qui doit être construit, mais aussi comment le construire en conjonction avec nos divers outils et conventions. Voici un extrait de la façon dont nous faisons référence à notre bibliothèque UI actuelle, Mantine, à partir de notre fichier de règles Cursor :

• Utilisez Mantine comme bibliothèque de composants React de base.
• Utilisez pleinement la bibliothèque Mantine, y compris les composants de `@mantine/core`, les hooks de `@mantine/hooks`, les formulaires avec `@mantine/form`.
• Pour les composants, essayez toujours d'utiliser en premier les composants de nos dossiers `components/core` ou `components/composites`, sinon utilisez les composants Mantine de base chaque fois que possible.
• Évitez d'utiliser le style en ligne ou les classes — essayez toujours d'abord d'utiliser les props Mantine pour styliser les couleurs et les couleurs de fond, l'espacement et les tailles, etc.
• Pour les couleurs, utilisez toujours nos couleurs de thème Mantine (par exemple `theme.colors.yourColorHere[index]`).
• Pour l'espacement et les tailles, utilisez la fonction `rem()` de Mantine plutôt que des valeurs en pixels ou numériques, c'est-à-dire `gap={rem(12)}`

Résultats Flex

L'utilisation de l'IA en conjonction avec notre système de conception a changé la donne à tous les niveaux pour établir et maintenir un niveau d'exigence plus élevé en matière de vitesse et de qualité. Notre récente fonctionnalité de comptabilité clients a été entièrement développée en trois semaines ! 

De même, l'utilisation du Playground comme une solide collection de composants et de modèles a souligné notre niveau d'exigence en matière de qualité, aussi bien pour les développeurs que pour les LLM. En adoptant une approche plus légère pour la construction d'un système de conception, nous avons pu contourner les nombreux pièges souvent associés aux systèmes de conception, tout en préservant les avantages de la cohérence et de l'orientation.

Récemment, nous avons utilisé le Playground comme ressource pédagogique pour montrer comment les développeurs peuvent utiliser des alternatives à un outil de gestion d'état que nous essayons activement de déprécier. Dans un avenir proche, nous visons à intégrer nos standards du Playground à notre build CI pour assurer davantage son adoption.

Enseignements pour les autres équipes

Si vous êtes en phase de démarrage, voici ce que nous recommandons :

• Commencez petit: Concentrez-vous sur vos composants d'interface utilisateur les plus utilisés
• Évitez les développements spécifiques: La plupart des bibliothèques de composants d'interface utilisateur modernes peuvent être utilisées pour lancer rapidement votre projet de système de design. Réservez les développements spécifiques pour les composants et les flux de travail plus complexes.
• Définissez clairement ce qu'est le « bon »: Assurez-vous que votre équipe dispose d'un ensemble de normes convenues concernant les outils d'interface utilisateur et les conventions de codage, afin de pouvoir les codifier avec des outils d'IA.
• Rendez-le évident pour votre équipe: Intégrez votre système de design dans le produit pour vous assurer qu'il est utilisé.
• Rendez-le accessible pour les LLM: Assurez-vous que vos outils d'IA peuvent facilement référencer votre système de design et vos normes pour garantir la cohérence avant de générer du code.

Réflexions finales

Vous n'avez probablement pas besoin d'un système de design personnalisé ou complet. Vous avez besoin d'un système utile.

Chez Flex, notre système de design est devenu un multiplicateur pour l'ingénierie, le produit et le design. Il nous a aidés à avancer plus vite avec un niveau de qualité bien plus élevé.

Pour les équipes en démarrage qui misent sur la vitesse et les outils d'IA, cela pourrait être l'un des investissements d'infrastructure les plus judicieux que vous puissiez faire.

‍