Système de conception basé sur la composition dans Figma —

Travailler en tant que concepteur sur un système de conception pour un grand produit m'a appris à quel point le temps que vous passez sur une seule tâche/composant est précieux. Les choses avancent vite et j'essaie de continuer à faire en sorte que cela fonctionne à la fois pour les concepteurs et les développeurs. Ce n'est pas une tâche facile.

J'ai remarqué qu'une bonne partie de la productivité des membres de l'équipe est consacrée à des conversations sans fin telles que :

« Est-ce que cela devrait être un composant distinct ? »

« Est-ce que ça doit être une variante ? »

« À quoi doivent ressembler les options de configuration ? »

…et ainsi de suite.

Ces types de conversations sont très répétitives, et même lorsqu'une décision est prise, ils n'ont pas l'impression que le temps passé avec l'équipe est bien utilisé. Il y a tellement de questions auxquelles il faut répondre.

Pourquoi optimisez-vous ? Est-ce pour la cohérence, l'évolutivité, la créativité ou la maintenabilité ? Vous pouvez optimiser pour tant de choses – et n'en choisir qu'une en sacrifie souvent une autre.

Il est difficile de définir un ensemble de règles qui mettraient fin à ces réunions à l'avenir. Ce qui a aggravé ce problème était un élément d'interface qui se démarquait en raison de sa grande réutilisabilité et de ses variations : élément de liste.

Si l'élément de liste Title-Subtitle est un composant, alors :

• L'image (chevron) indique-t-elle un nouveau composant ou une variante de celui-ci ?
• Et s'il ne s'agit pas d'une navigation chevron à la fin mais une icône (info) à la place ?
• Et s'il y avait une image en tête devant ?
• Et s'il y avait un interrupteur ?

Aa et en même temps, ils partagent des états (sélectionné, enfoncé, désactivé, etc.). Essayez d'appeler l'équipe iOS, Android et les concepteurs pour prendre une décision à ce sujet. 🤯

Heureusement, j'ai été entouré de personnes ouvertes à la collaboration entre les équipes. Après avoir fait équipe avec des développeurs, j'ai commencé à reconnaître les termes et les modèles des développeurs dans l'outil de conception.

En même temps, Figma a jeté un coup d'œil par-dessus les épaules des développeurs pour les outils de création de mise en page (comme la mise en page automatique, variantes avec des propriétés, des contraintes, etc.) L'immersion de ces modèles m'a permis de construire les composants avec presque les mêmes règles dans Figma (en vous regardant, les paramètres de largeur/hauteur min et max).

Présentation de la « composition » pour les systèmes de conception : contenu composable Et les conteneurs

Regardons ce composant élément de liste :

La façon dont nous les avions dans notre projet était juste une collection de tous les éléments de liste possiblesc'est-à-dire avec une grande icône, une petite icône, un sous-titre, une bascule, un texte de fin, etc. Ils ont tous été définis séparément avec leurs antécédents et nommés numériquement (à partir des éléments de liste 1 à 8).

Ainsi, nous n'avions aucune sémantique en place définissant nos éléments de liste d'une manière plus significative, ainsi comme aucun moyen optimisé de maintenir les mises à jour du style et de la mise en page d'arrière-plan définis. Ce qui a commencé à se produire, c'est que de nouveaux états incohérents ont commencé à apparaître dans certains fichiers :

1. Un élément de liste de choix aurait un arrière-plan teinté dans un fichier de conception (indiquant la sélection), mais juste une coche sur le côté droit dans un autre ;
2. Les remplissages seraient différents selon les fichiers de conception.

Raisonnablement, les arrière-plans des éléments de liste devraient rester cohérents sur tous les écrans et être flexible pour s'adapter à différents contenus à l'intérieur. Alors, comment appliquons-nous cela à travers un système de conception dans toutes les équipes  ?

Il existe plusieurs façons, alors soyons un peu technique ici. Une approche est Variation.

Variation

Tout d'abord, définissez tous les list items qui existent dans l'interface et identifiez leurs variantes :[19659036]Différents éléments de liste dans l'interface. »/>

Ensuite, ajoutez tous les états d'éléments de liste définis (secondaire, accent, etc.) en tant que variantes pour chaque élément de liste. Cela doublera chaque composant/variante d'origine par état et vous serez en mesure de prendre en compte tous les états possibles qu'un élément de liste pourrait avoir.

C'est ainsi que nous avons d'abord pensé aborder le problème, mais vous pouvez clairement voir les problèmes avec cela : augmenter le nombre de variantes qui doivent être maintenues là où vous avez une répétition inutile de l'arrière-plan et d'autres éléments.

Maintenant. , imagine ça. Essayons de modifier les éléments suivants :

• L'arrière-plan secondaire (gris) pour avoir une couleur/un rayon d'angle différent ;
• Ou le style de police du titre ;
• Ou l'espacement entre le titre et le sous-titre ;
• Ou la taille de l'image.

Vous devrez accéder à chaque variante (32 au total dans notre cas) et mettre à jour chacune manuellement afin d'aligner ces changements. 😨 Cela devient un moyen assez inefficace de maintenir ces composants, à la légère.

Passons ensuite à une meilleure approche : Composition.

Composition

Nous commencerons par composer un conteneur 🔴. Ici, nous définissons le style et le remplissage de l'arrière-plan (peut également inclure le rayon des angles, les ombres, etc.)

Nos éléments de liste contiendront quelques éléments d'amélioration 🔶, tels qu'une coche, un chevron de navigation, un commutateur ou un bouton. Puisqu'ils pourraient s'appliquer à n'importe quel arrière-plan défini et à tout le contenu générique, nous aurions besoin de composer un autre conteneur pour ces éléments. l'instance d'espace réservé est à nouveau imbriquée à l'intérieur pour le contenu.

Ensuite, définissons les éléments de liste contenu ⚫️ (par exemple Élément de liste multiligne) que votre interface a sans arrière-plan (uniquement du texte et des images) :

Maintenant, nous devons penser à partir du sol (axe Z en premier) pour que nous assemblons l'élément de liste nécessaire :

• Prenez le récipient 🔴 et sélectionnez un état nécessaire ;
• Échangez le espace réservé 🔷 à l'intérieur avec l'élément de liste content ⚫️ vous avez défini >> ☑️
• Ou si vous avez un élément d'amélioration dans un élément de liste (comme un commutateur, un bouton, etc.) :
  • Échangez le espace réservé 🔷 avec le conteneur d'éléments 🔶,
  • Puis échangez à l'intérieur du espace réservé 🔷 avec un élément de liste contenu ⚫️ >> ☑️.

Au final, ce n'est pas seulement que nous alignons les approches de conception et de développement en utilisant la composition, mais en plus, ce serait le la manière la plus optimisée de construire de tels composants dans conception et code pour la cohérence et la maintenabilité. Maintenant, notre composant de conception est devenu presque un pseudo-code pour les développeurs.

En parlant de code…

Voyons à quoi ressemblent les choses en développement. Voici du code et un aperçu iOS rendu pour quelques composants de composition SwiftUI :

Certaines de ces combinaisons sont stupides, mais elles mettent en valeur la puissance de l'approche. Remarquez comment le composant switch (toggle) est en fait natif/système pour iOS et comment il se connecte à notre composition avec nos composants personnalisés de manière totalement transparente, à la fois dans le code et visuellement.

En effet, les frameworks frontaux modernes tels que SwiftU pour iOS et Jetpack Compose pour Android (sans blague, il a littéralement « Composer » dans son nom 😉) reposent sur la même approche de composition que nous décrivons – et ce que Figma permet maintenant aussi.

Pourquoi même créer des composants composables ?[19659023]Eh bien, il y a au moins cinq bonnes raisons pour lesquelles nous voudrions créer des composants composables :

1. Cohérence

En plaçant tous les modèles d'arrière-plan au même endroit pour être réutilisés, nous nous assurons que ces états d'arrière-plan sont représentés de manière cohérente à travers les fonctionnalités et les équipes, en tant que source unique de vérité. Lorsque ces états ne sont pas vraiment définis, vous obtenez des conceptions visuellement différentes pour ces états à travers les écrans — plus il y a de concepteurs dans l'équipe, plus il y aura d'incohérences.

2. Conception à l'épreuve des erreurs

Nous éliminons complètement la possibilité pour un concepteur d'abuser des états, de se tromper de remplissage, d'introduire quelque chose qui existe déjà, etc. À moins que vous ne détachiez l'instance…

3. Flexibilité absolue

Avez-vous besoin d'imbriquer un autre composant dans votre élément de liste ? Voilà ! Nous n'avons pas besoin de limiter un élément de liste pour héberger un contenu spécifique uniquement. Vous pouvez mettre n'importe quel contenu à l'intérieur. Voyons comment nous pouvons mettre le contenu que nous avons utilisé pour liste items dans un conteneur card de manière absolument transparente.

Habituellement, la cohérence est obtenue au détriment de la flexibilité, mais pas dans cette affaire.

4. Réduit les variantes

Il n'est plus nécessaire d'inclure les états list item dans chaque composant list item. Vous l'avez défini à un seul endroit et réutilisé en tant que conteneurde même pour les éléments que l'élément de liste peut héberger, comme des commutateurs, des boutons, des icônes, etc. au. Aide à la maintenabilité et à l'évolutivité des composants.

Maintenant, mettez cela à l'échelle à un système de conception complet. Vous pouvez voir pourquoi je considère que l'approche de la variation n'est pas viable.

5. Rassemble les équipes

Construire des composants dans la conception de la même manière que dans le code supprime les frictions dans la documentation et les spécifications, et permet de partager le même processus et le même langage entre les concepteurs et les développeurs.

Et devinez quoi, cela peut être appliqué. à de nombreux autres composants qui partagent une structure composable similaire. Les composants les plus évidents que nous proposons comme candidats pour cette mise à niveau sont :

• cartes : réutilisation des arrière-plans comme actif, surligné, désactivé,
• personnalisé feuilles inférieures : réutilisation du conteneur et mettre n'importe quel contenu à l'intérieur.

Quand l'utiliser et quand ne pas l'utiliser ?

Vous pouvez probablement déjà voir que cette structure optimise le plus la réutilisation cohérente et la maintenabilité, mais n'allez pas trop loin avec elle. Voici une règle générale sur le moment où vous pouvez utiliser la composition :

Vous utilisez la composition lorsque vous pouvez (raisonnablement) découper un composant (sur l'axe X/Y/Z) en 2 parties « Contenu générique » et « éléments d'amélioration » où :

• « contenu générique » est la tranche (zone) d'un composant qui héberge tout contenu de l'interface utilisateur.
• « éléments d'amélioration » incluent le éléments d'interface utilisateur constants (comme le commutateur, le chevron, l'arrière-plan) et le comportement d'interaction (animations) d'un composant.

Cette règle laisse beaucoup de place à l'interprétation car les tranches peuvent être vues différemment par différentes personnes, mais c'est bien car elle démontre le la flexibilité et la puissance de cette approche où vous avez plusieurs façons d'atteindre votre objectif.

Gérer le pouvoir

Si vous décidez d'adopter la structure composable dans votre système de conception, je vous recommande de diviser vos composants en couches hiérarchiques dans Figma :

1. Container-backgrounds
   Ces composent sur l'axe Z et définir uniquement :
   • style : couleur de fond, rayon de coin, ombre, etc.
   • disposition générale : remplissages, la position du contenu.
2. Conteneurs d'éléments d'amélioration
   Conteneurs pouvant inclure des éléments supplémentaires tels que chevron, commutateur, bouton, icône, etc.
3. Contenu
   Composants qui sont de véritables implémentations de contenu générique . Ils constituent le nœud final de l'arbre de composition.

Vous pouvez voir comment vous avez maintenant le pouvoir de composer n'importe quoi. Et tout comme les pièces de lego, vos composants sont capables de combinaisons infinies qui peuvent en fait être idiotes dans la pratique, comme dans l'exemple ci-dessous.

Ainsi, vous pouvez décider de limiter les combinaisons d'utilisation de vos composants composables. Comme dans l'exemple de combinaison de coche et de commutateur, nous ne voulons clairement pas imbriquer ces deux éléments dans un élément de listedonc ce que nous pouvons faire à la place est de coupler enhancing-container avec container-backgrounds applicable comme nouveau composant.

Dans l'élément de liste de navigationvous couplez container-background (avec 2 variantes, par défaut et pressé) avec enhancing-container (chevron). De cette façon, vous définissez toutes les variantes possibles de ce composant. De plus, même si vous pouvez toujours y mettre du contenu, vous ne pouvez pas utiliser un autre état (comme en surbrillance) ou y ajouter d'autres éléments tels que des bascules.

Notes finales

Jusqu'à présent, mon équipe et moi avons adopté des composants composables pour les cartes et les éléments de liste pour les deux plates-formes mobiles, iOS et Android — et nous l'adorons.

Les développeurs et designers se sont rapidement attachés à cette approche. Bien que la construction des composants soit de plus en plus complexe, tout le monde voit que cela rend notre système de conception plus élaboré et plus élégant.

En général, si vous le laissez vivre uniquement dans un système de conception sans le synchroniser dans le code, ce sera déjà assez bénéfique. . Vous devez faire des efforts pour le construire, mais cela rapporte bien avec moins de maintenance, tout autant que pour les systèmes de conception.

Cet article a été écrit en collaboration avec mon mari développeur iOS. Merci, Petar Kanev.

(vf, yk, il)