Systèmes de conception : Les leçons de Vivid

Notre spécialiste CSS Rachel Tannenbaum a donné une conférence étonnante lorsque Vonage a accueilli la conférence sur l'utilisation de la technologie CSS. Pull Requestune rencontre de la communauté open-source. Elle a parlé des systèmes de conception, son domaine de prédilection depuis trois ans. Mais tout le monde devrait apprendre les systèmes de conception, pas seulement ceux qui ont la chance d'assister à un meetup. C'est pourquoi je vais partager dans cet article ce que j'ai retenu de son intervention, en répondant aux questions suivantes :

Qu'entendons-nous par "système de conception" ? Pourquoi les organisations ont-elles besoin d'un système de conception ? Les systèmes de conception relèvent-ils de la responsabilité de l'équipe de conception ou de l'équipe de développement ? Comment les systèmes de conception sont-ils mis en œuvre ?

Qu'est-ce qu'un système de conception ?

Tout a commencé avec des livres !

Le livre de la marque était la seule source de vérité pour maintenir l'intégrité et l'uniformité de la marque.

coca-cola-brand-book.png

Il y a bien longtemps, à l'époque où l'homme pouvait survivre sans Internet, les entreprises disposaient d'un livre de marque. Ce livre contenait la philosophie de la marque de l'entreprise : couleurs, polices de caractères, imagerie, etc. Il définissait différents styles en fonction du contexte, par exemple une publicité dans un journal par rapport à une publicité sur un panneau d'affichage. Le livre de la marque Coca-Cola, par exemple, contenait même des lignes directrices pour la forme de ses bouteilles en verre ! Ce livre a permis de maintenir la marque et sa visibilité, quel que soit l'éditeur du produit final.

Les livres de marque passent au numérique : Guides de style

Mais aujourd'hui, les gens ne peuvent plus se passer de l'internet. Les sites web à page unique se sont transformés en applications web tentaculaires avec des sous-sites. Il n'est plus possible pour un seul concepteur de gérer l'application d'une entreprise. Alors que les équipes de conception s'agrandissent pour relever ce défi, une nouvelle ressource est apparue pour donner un sens à ce chaos. Alors que le monde analogique disposait d'un livre de marque, le monde numérique dispose d'un guide de style.

vonage-style-guide-example.png

Un guide de style est la source de vérité pour les actifs numériques d'une marque. Ces ressources comprennent des éléments fondamentaux tels que les couleurs, les icônes, la typographie et des éléments tels que les boutons. Ils comprennent également des éléments plus complexes tels que les sélecteurs de date, les menus, etc. Bien entendu, les éditeurs de logiciels qui conçoivent des outils de conception se livrent également à des expériences.

Mais quel est le rapport entre les guides de style et les systèmes de conception frontale ? Imaginez que le processus de développement d'un frontend ressemble à une construction avec des Legos. Les guides de style prennent des idées abstraites comme les couleurs et les formes et les transforment en un livre d'instructions. Les systèmes de conception prennent ces instructions et les transposent dans le monde réel, en combinant les briques pour en faire des objets. L'avantage d'un système de conception par rapport à un guide de style est qu'il contient des sections de code, appelées composants, qui peuvent être rapidement réutilisées à l'infini dans une application. L'utilisation de composants garantit l'uniformité de la marque et permet d'économiser un temps de développement précieux. En outre, les systèmes de conception sont facilement évolutifs et dynamiques. Ainsi, avec les systèmes de conception, vous ne construisez plus le code comme un artisan, mais comme une usine industrielle à haute puissance de jolis legos.

Pourquoi utiliser un système de conception ?

Tout produit numérique a besoin d'un système de conception UX !

Ok, peut-être pas tout produit produit numérique n'a pas besoin d'un système de conception. La question que vous devez poser à votre organisation est la suivante : sommes-nous une Ford ou une Ferrari ?

La mise en place et la maintenance des systèmes de conception peuvent prendre beaucoup de temps. L'investissement initial important n'en vaut la peine que pour les projets de grande envergure où vous gagnerez du temps à long terme. Votre équipe doit tenir compte du nombre de développeurs qui utiliseront le système de conception, de la portée de votre ou de vos produits, ainsi que des normes et de la communication de votre équipe de développement.

Votre équipe est-elle une Ferrari ? Si vous êtes une Ferrari, vous avez une gamme de produits relativement petite, avec peu de composants reproductibles. Vos produits ne sont pas conçus à grande échelle et, par conséquent, les économies d'échelle réalisées dans vos conceptions ne permettraient pas à votre organisation de réaliser des économies substantielles.

Ou êtes-vous un Ford ? Avez-vous de nombreux produits, de nombreuses équipes et de nombreuses conceptions qui intègrent un grand nombre de pages et de fonctionnalités ? Un bon test consiste à vous demander si vous devez mettre à jour le design de tous vos boutons : la tâche serait-elle gargantuesque ou simplement ennuyeuse ? Si c'est une tâche gargantuesque, vous êtes probablement une Ford.

Avantages des systèmes de conception : Ordre et efficacité

En d'autres termes, une bonne conception améliore l'expérience de l'utilisateur et maintient la cohérence de la marque grâce à l'ordre et à l'efficacité.

1. Commande

   • Commander en UI: Établit une conception fixe, un modèle fixe de comportements, de gestes, d'interactions, etc.

   • Commande dans le développement : Permet de mettre de l'ordre dans le désordre, de nettoyer le code et d'éviter la duplication du code.

2. Efficacité

   • Développement efficace: Réduit le temps de développement, permet aux concepteurs de prendre de meilleures décisions, ce qui permet à votre organisation d'économiser du temps et de l'argent.

   • Mises à jour efficacesLes mises à jour de l'ensemble du système se font en un clin d'œil.

gmail-ui-uniformity-example.png

Gmail est un excellent exemple de systèmes de conception créant de l'ordre et des gains d'efficacité. Quel que soit l'appareil utilisé, l'utilisateur sait clairement qu'il s'agit d'un produit Google. Les composants de l'interface utilisateur indiquent clairement à l'utilisateur le type d'interactions auxquelles il peut s'attendre. En ce qui concerne l'efficacité, vous souvenez-vous lorsque Google est passé de Material Design 2 à Material Design 3 ? Imaginez chaque endroit où les barres de navigation rouges et violettes devaient être modifiées, chaque endroit où les coins devaient être arrondis exactement de la même manière. Au lieu de créer d'énormes maux de tête dans l'ensemble de ses produits, un système de conception a permis à Gmail, Google Docs, Google Slides et à tous les autres produits d'être exactement identiques grâce à des composants réutilisables.

Les leçons de Vivid

vivid-vonage-design-system-cover.png

Mettre en œuvre un système de conception par itérations

Ne construisez pas d'abord un système de conception UX ! Pensez aux systèmes de conception UX d'une manière LEAN. Vous voulez construire les composants les plus utiles et les plus évolutifs. Vous devez donc savoir quels composants sont réellement utilisés par votre équipe de conception. Cela signifie que votre organisation devrait d'abord construire son ou ses produits, puis évaluer quels sont les composants les plus réutilisés. Les systèmes de conception ne sont pas destinés à la V0.1 de votre produit, mais uniquement à la V1.0 et aux versions ultérieures.

Comment identifier les composants dont vous aurez besoin ? Vous pouvez toujours commencer par les éléments les plus élémentaires : typographie, couleurs, boutons, etc. Ces éléments seront largement utilisés quel que soit le produit. Ces éléments seront largement utilisés quel que soit le produit. À partir de là, votre système de conception évoluera. Nathan Curtis a publié un excellent article (https://medium.com/eightshapes-llc/the-component-cut-up-workshop-1378ae110517) à ce sujet, intitulé "The Component Cut-Up Workshop", dans lequel vous pouvez voir le processus de division d'un site web en composants qui constituent le système de conception.

vivid-abstract-artwork.png

Chez Vonage, notre système de conception a connu de nombreuses itérations. Le premier projet s'appelait Volta et a largement contribué à la normalisation des CSS. Puis, au fur et à mesure que le projet a gagné le soutien de la direction, il a été baptisé Vivid.

Vivid-2 était basé sur le Material Design. Rapidement, nous avons réalisé que cela était problématique à plusieurs égards :

• trop lourd pour ce dont nous avions besoin

• manque de communication avec la communauté et les demandes de changement/bugs

• non conforme à la spécification

• pas totalement accessible

• ne doit pas servir de base à la création d'un système de conception.

Vivid 3 : Tout repenser

En passant de Vivid 2 à Vivid 3, nous avons décidé de tout repenser. Nous avons donc utilisé le Fast de Microsoft comme base. Nous avons choisi Fast parce qu'elle a été conçue pour servir de base à un système de conception. En même temps, elle est légère et évolue continuellement pour ajouter de nouveaux composants et de nouvelles fonctionnalités. Et surtout, elle est construite en conformité avec le W3C et OpenUI.

Non seulement Vivid-3 a tous les avantages de Fast, mais il les a aussi améliorés :

• couverture des tests - passer de 70% à 100%

• documentation - avec des extraits de code prêts à l'emploi, ce qui permet aux développeurs de copier/coller simplement ce dont ils ont besoin

• l'accessibilité - conformément aux WCAG 2

• l'étiquetage blanc

Construire un pont

L'équipe comme pont

Votre système de conception doit servir de pont. Constituez votre équipe avec les bonnes parties prenantes, qui partageront chacune leur expertise et façonneront le système de conception pour répondre aux besoins de chaque fonction de l'entreprise.

Qui est responsable de la construction du système de conception ? En bref, l'équipe de développement. L'équipe de développement doit être la première responsable de la création du système de conception, mais elle n'est pas la seule. L'un des principaux avantages d'un système de conception est qu'il sert de pont entre les concepteurs et les développeurs. Le système de conception sert de guide et fournit un langage commun pour clarifier la communication entre les développeurs et les concepteurs. Plus les responsabilités sont partagées entre ces équipes et plus les contributions de chacune d'entre elles sont investies dans la création d'un système de conception, plus le produit final sera de qualité et améliorera les synergies au sein de votre organisation.

Pont avec outillage

Parallèlement à notre API, nous maintenons une bibliothèque de composants dans Figma pour les designers. Lorsqu'ils travaillent sur la conception d'une page, d'une application ou de n'importe quoi d'autre, ils peuvent rapidement ajouter la bibliothèque d'actifs de Vivid à leurs composants de conception. De cette manière, ils conservent un design uniforme. Dans le fichier Figma final, les développeurs ont tout ce dont ils ont besoin pour coder : exactement les composants à utiliser et leurs spécifications exactes au pixel près (taille, forme, police, etc.).

vivid-component-library-figma.png

En outre, nous exportons des jetons de conception pour les couleurs, la typographie et les tailles à partir de Figma pour les utiliser dans la bibliothèque de code. Ce qui est intéressant avec les jetons de conception, c'est qu'en changeant la Figma d'un des jetons et en l'exportant, le même changement sera automatiquement effectué dans Vivid.

Identifier les principales préoccupations de votre organisation

identify-main-concerns-investigate.png

Vonage est une très grande entreprise qui compte de nombreuses équipes de développeurs travaillant sur un large éventail de produits. Cela se traduit par un grand nombre de bibliothèques de développement front-end utilisées à travers l'entreprise : Vue.js, React Native, Angular, etc. La mission de Vivid est d'unifier le design de tous ces projets. Pour Vivid, nous avons identifié 3 préoccupations majeures : l'évolutivité, l'uniformité inter-framework, et l'accessibilité. Nous avons besoin que Vivid se mette à jour de manière uniforme à travers un large éventail de produits. Nous avons besoin de nous assurer que le résultat final est indépendant du framework frontal. Enfin, nous devons nous assurer que la solution est conforme aux dernières normes d'accessibilité.

Pour répondre à ce besoin, Vivid est basé sur des composants web.

Qu'est-ce qu'un composant Web ?

Les composants web sont une suite de technologies différentes qui vous permettent de créer des éléments personnalisés réutilisables - dont la fonctionnalité est encapsulée à l'écart du reste de votre code - et de les utiliser dans vos applications web. Fondamentalement, le produit final d'un composant web est constitué de HTML, CSS et Javascript, ce qui signifie qu'il peut s'adapter à n'importe quel environnement de développement. Pour en savoir plus, je vous recommande de lire Premiers pas avec les composants web.

Les composants Web contiennent trois éléments principaux :

1. Élément personnalisé

Il s'agit de l'élément "hôte". Il sera vu dans le DOM et aura généralement un nom unique. Par exemple, dans les composants Vivid, le nom de l'élément personnalisé commence toujours par vwc. Ces initiales signifient Vivid Web Components. La deuxième partie de l'élément est le nom de l'élément qui sert de description de son but. Par exemple vwc-button, vwc-dialog, etc.

1. Domaine de l'ombre

Une sorte de "sous-dom" caché à la vue, il se trouve sous l'élément hôte, l'élément personnalisé. Il permet à un composant d'avoir son propre arbre DOM "ombre", qui ne peut pas être accidentellement accédé depuis le document principal, peut avoir des règles de style locales, et plus encore.

1. Modèle

À l'intérieur du shadow-dom, nous pouvons voir le modèle html qui contient les éléments ou les parties du composant.

Les composants web de Vivid demandent aux utilisateurs de définir les composants en fonction de leurs besoins (texte, icône, etc.), et en retour, ils recevront des composants entièrement fonctionnels et conçus, sans presque aucun codage et sans toucher à la structure HTML du composant lui-même.

Par exemple, pour ajouter une fenêtre modale au projet, tout ce dont vous avez besoin est ceci :

Sous le capot, à l'intérieur de la zone d'ombre, tout ce code sera effectivement ajouté au projet :

<vwc-elevation dp="12">
  <dialog class="base icon-placement-side hide-body hide-footer" open="">
  <slot name="main">
    <div class="main-wrapper">
      <div class="header border">
        <slot name="graphic">
          <vwc-icon class="icon" name="info"></vwc-icon>
        </slot>
        <div class="headline">Dialog Headline</div>
        <div class="subtitle">subtitle content</div>
        <vwc-button size="condensed" class="dismiss-button" icon="close-line">   
        </vwc-button>
      </div>
    </div>
  </slot>
  </dialog>
</vwc-elevation>

Et pour s'assurer que la boîte de dialogue s'ouvre à l'intérieur d'une fenêtre modale, l'ouverture doit être activée par une fonctionhowModal.

<script>
  function openDialog() {
    dialog = document.querySelector('vwc-dialog');
    dialog.showModal();
  }
</script>

Le produit final ressemblera à ceci :

vivid-dialog-component.png

Mangez la nourriture pour chiens

De tous les outils qui aident au développement des systèmes de conception, Storybook est probablement le plus populaire. Mais malgré tous ses avantages, il n'est pas facile de gérer correctement les composants Web. Il n'affiche pas correctement le code des composants et ne génère pas d'extraits de code pour les développeurs.

Pour cette raison, la documentation de Vivid est construite avec...Vivid ! L'utilisation de nos propres composants a permis d'améliorer les composants eux-mêmes et leur documentation.

Il est essentiel d'utiliser les composants en dehors de l'environnement de développement. Cela dit, les développeurs de systèmes de conception doivent toujours se rappeler qu'ils ne sont pas les utilisateurs de la bibliothèque. Ne présumez pas que la façon dont vous utilisez les composants sera la seule ou la bonne, communiquez avec vos utilisateurs.

Conclusion

Maintenant que vous en savez un peu plus sur la façon dont nous avons construit Vivid, vous devriez aller de l'avant et l'essayer ! Jetez un coup d'œil au livre d'histoire ou Github Github. Nous serions ravis de voir ce que vous construisez avec Vivid ou d'entendre parler de vos propres expériences de construction d'un système de conception. Envoyez-nous un message sur la communauté des développeurs de Vonage Slack ou sur Twitter.