Conception de produit et UI/UX

Systèmes de design

Une source partagée unique pour l'apparence et le comportement de votre produit. Tokens, composants et documentation qui maintiennent la cohérence entre le design et le code à mesure que votre produit et votre équipe grandissent.

Parlons de votre projetDiscutez de votre design system

Qui a besoin d'un système partagé

Une simple modification, comme une nouvelle couleur de marque ou un meilleur style de focus, doit être effectuée écran par écran dans chaque produit, car le design et le code ne partagent plus les mêmes parties. Un système de design offre à chaque équipe le même ensemble maintenu de parties à partir duquel construire.

  • Les organisations où plusieurs équipes livrent l'interface du même produit en même temps
  • Les entreprises qui regroupent des produits acquis ou construits séparément en une seule famille de produits
  • Les équipes de plateforme frontend chargées de transformer l'interface partagée en un package versionné et maintenu

Une cohérence partagée par vos designers et vos développeurs

Lorsque chaque équipe construit ses propres boutons, formulaires et modales, les produits dérivent : écrans incohérents, travail répété et corrections d'accessibilité effectuées à un endroit mais pas à un autre. Nous construisons des design systems qui relient le design et le code : tokens, bibliothèques Figma, composants codés et documentation, avec une gouvernance pour que le système reste à jour. Il convient aux produits SaaS en croissance, aux entreprises comptant plusieurs produits et aux équipes migrant vers un nouveau frontend. Nous pouvons livrer le volet design seul ou le système complet du design au code.

Audits assistés par l'IA, standards détenus par des experts

Comment l'IA assiste

  • Inventorie vos écrans et votre base de code, en répertoriant les composants dupliqués ainsi que les couleurs et espacements codés en dur.
  • Rédige la documentation des composants, les consignes d'utilisation et des exemples de code que les designers et les ingénieurs peuvent examiner.
  • Génère la structure des composants codés, des stories Storybook et des tests à partir des designs approuvés, sous revue d'ingénierie.
  • Signale les couleurs, espacements et composants hors système dans les pull requests, afin que les écarts soient détectés lors de la revue de code.

Ce dont nos experts sont responsables

  • Les designers et les ingénieurs maîtrisent l'architecture des tokens, le nommage et la stratégie de thématisation.
  • Les ingénieurs définissent l'API, le comportement et les états de chaque composant, et examinent chaque modification assistée par IA.
  • L'accessibilité est vérifiée pour chaque composant : comportement au clavier, focus, rôles ARIA, contraste et sortie des lecteurs d'écran.
  • Les personnes maîtrisent la gouvernance : ce qui entre dans le système, le versionnage, la dépréciation et les règles de contribution.

Ce que contient chaque couche du système

Couches typiques d'un système web multi-produits ; votre audit détermine ce qui entre dans chacune.

  • Tokens et thèmes

    • Valeurs de base pour la couleur, l'échelle typographique, l'espacement et le rayon des coins
    • Alias sémantiques tels que surface, bordure et danger que les composants utilisent
    • Thèmes clair, sombre et de marque créés en permutant les valeurs d'alias
    • Tokens de mouvement pour la durée et l'accélération, partagés avec les spécifications d'interaction
    • Exporte vers des variables CSS, et vers les formats iOS et Android lorsque nécessaire

  • Composants et états

    • Boutons, champs de saisie, sélecteurs, fenêtres modales et tableaux construits uniquement à partir de tokens
    • Une spécification par composant : propriétés, variantes, états et comportement clavier
    • Des noms de variantes Figma qui correspondent aux propriétés du composant codé
    • Des éléments composites tels que les sélecteurs de dates et les listes déroulantes combinées, assemblés à partir de composants plus petits

  • Modèles, recommandations et gouvernance

    • Des modèles qui combinent des composants : mises en page de formulaires, filtrage, actions groupées, intégration
    • Des recommandations sur quand utiliser chaque modèle, et quand ne pas le faire
    • Parcours de contribution : proposition, revue de design et de code, puis une publication versionnée
    • Statut des composants, du brouillon à l'obsolescence, avec des notes de migration pour les changements incompatibles

Comment nous construisons un système de design

  1. 01

    Audit

    Nous inventorions votre interface et votre code actuels avec une analyse assistée par IA, puis nous convenons des priorités : ce qu'il faut standardiser en premier et ce qu'il faut retirer.

  2. 02

    Fondations

    Des tokens pour la couleur, la typographie, l'espacement et le mouvement, avec des règles de nommage et de thématisation convenues entre les designers et les ingénieurs.

  3. 03

    Composants

    Des composants conçus dans Figma et, lorsque cela entre dans le périmètre, construits en code, chacun étant examiné pour son comportement et son accessibilité au moment de sa mise en place.

  4. 04

    Documenter et adopter

    Documentation, règles de contribution et présentation guidée avec vos équipes, puis un accompagnement à la migration à mesure que les produits adoptent le système.

Deux façons de travailler avec les outils d'IA

L'IA aide à synthétiser les recherches autorisées et à explorer les conceptions. Choisissez où elle peut traiter vos recherches et vos fichiers.

Vous hésitez ? Nous vous en recommanderons un lors du cadrage. Comparer les options de livraison avec IA

Ce que vous recevez

Un système pour le design et le code

  • Audit et inventaire de l'interface

    Un catalogue des composants, modèles et styles dont vous disposez déjà, avec les doublons, incohérences et lacunes d'accessibilité priorisés.

  • Tokens de design

    Tokens de couleur, de typographie, d'espacement, de rayon, d'élévation et de mouvement, avec des thèmes clair, sombre ou de marque, exportés pour le web, iOS et Android selon les besoins.

  • Bibliothèque de composants Figma

    Des composants avec variantes, propriétés et chaque état d'interaction, construits sur les tokens et nommés pour correspondre au code.

  • Composants codés

    Des composants en React ou votre framework, avec des props typées, des tests et un comportement accessible, publiés sous forme de package versionné lorsque cela entre dans le périmètre.

  • Site de documentation

    Storybook ou un site de documentation personnalisé avec des exemples en direct, des consignes d'utilisation, les bonnes et mauvaises pratiques, et des notes d'accessibilité pour chaque composant.

  • Gouvernance et versionnage

    Des règles de contribution, des étapes de revue, des notes de version et un processus de dépréciation, pour que le système évolue de manière contrôlée.

Demandes typiques de système de design

Scénarios types que nous cadrons, et non des études de cas clients.

  • Un changement de marque sur plusieurs produits

    Une entreprise disposant d'une application web, d'une application mobile et d'un outil d'administration change ses couleurs de marque. Nous déplaçons d'abord les couleurs dans des tokens thématisés, afin que chaque produit récupère la nouvelle palette depuis le même endroit.

  • Figma et le code désalignés

    Les designers maintiennent une bibliothèque Figma que les développeurs ont cessé d'utiliser, tandis que les composants React portent leurs propres espacements et couleurs. Nous auditons les deux, convenons de la version de chaque composant qui devient la référence, et alignons les noms afin que le design et le code correspondent.

  • Une correction d'accessibilité pour chaque produit

    Une revue d'accessibilité révèle des problèmes de focus et de clavier dans le sélecteur de date, la fenêtre modale et le menu déroulant utilisés dans plusieurs produits. Nous les corrigeons une seule fois dans les composants partagés, documentons le comportement clavier attendu et publions une version que chaque produit peut adopter.

Ce que cette mission ne couvre pas

  • La conception des écrans individuels de votre produit ne fait pas partie de ce travail ; l'interface écran par écran relève de Figma & Design Visuel, qui peut s'appuyer sur le système.
  • Les tokens de mouvement sont inclus ; la conception des transitions, des gestes et de la chorégraphie qui les utilisent relève du Design d'Interaction.
  • Le déplacement des écrans existants de chaque produit vers le système relève du développement produit, cadré séparément ; le système est livré avec des notes de migration et le support que nous convenons.
  • Un système a besoin d'un responsable désigné de votre côté après la remise, ou d'un accord de maintenance convenu avec nous ; sans cela, les écarts réapparaissent.

Comment le système soutient le développement, le QA et les versions

  • Les ingénieurs construisent à partir de parties partagées

    Les développeurs composent les écrans à partir de composants et tokens testés au lieu de les reconstruire, et les modifications de design se traduisent directement en code.

  • Le QA au niveau des composants

    Les composants portent leurs propres vérifications de régression visuelle et d'accessibilité, afin que les tests de version puissent se concentrer sur les parcours et les règles métier.

  • Versions de système contrôlées

    Les packages versionnés, les journaux de modifications et les notes de migration permettent à chaque produit d'adopter les mises à jour du système de manière délibérée, et non par surprise.

  • Maintenu à mesure que vous grandissez

    Nous pouvons maintenir le système après le lancement : ajouter des composants, examiner les contributions et garder le design et le code alignés.

FAQ

Questions fréquemment posées

Avons-nous déjà besoin d'un système de design ?

Cela porte généralement ses fruits lorsque plusieurs personnes conçoivent ou construisent le produit, lorsque les mêmes composants sont reconstruits de différentes manières, ou lorsque vous gérez plus d'un produit ou d'une plateforme. Pour un produit en phase initiale, nous pouvons recommander un démarrage plus léger : des tokens et des composants de base, étendus à mesure que le produit grandit.

Pouvez-vous construire sur nos composants existants ?

Oui. Nous auditons ce que vous avez, gardons ce qui fonctionne, standardisons le reste et comblons les lacunes. La migration peut être progressive, afin que le travail produit ne s'arrête pas pendant l'introduction du système.

Construisez-vous la bibliothèque codée, ou uniquement la partie Figma ?

L'un ou l'autre. Une mission uniquement de design vous donne la bibliothèque Figma, les tokens et des consignes d'implémentation pour vos développeurs. Si vous souhaitez également des composants codés, nos ingénieurs les construisent et les testent dans votre stack. L'hébergement du site de documentation est convenu séparément.

Où notre code est-il traité lorsque l'IA aide à construire des composants ?

Cela est convenu avant le début du travail. Avec l'ingénierie IA privée / locale, le traitement IA s'exécute sur des modèles hébergés en privé au sein d'un périmètre convenu. Avec l'ingénierie Claude Code / OpenAI Codex, les agents de codage commerciaux travaillent selon des paramètres convenus de compte, de traitement des données et de conservation. Dans les deux cas, les ingénieurs examinent chaque modification.

Construisez un système que vos équipes utiliseront

Parlez-nous de vos produits, de vos équipes et de votre interface actuelle. Nous vous recommanderons par où commencer, d'un audit jusqu'à un système complet du design au code.

Parlons de votre projetPlanifiez votre système de design