Figma : Design Systems, Auto-layouts et Composants

September 8, 2020

Introduction

Comme beaucoup de startups, designers et entrepreneurs, vous avez commencé à utiliser Figma pour votre application. Après les quelques mois de prise en main, vous commencez à vous poser des questions : 

  • Comment utiliser les composants pour simplifier les mises à jour de votre appli, sans devenir très compliqué ? 
  • Comment adapter des écrans du web au mobile sans vous casser la tête tout en gardant une cohérence forte entre les expériences ? 
  • Comment organiser vos fichiers pour réaliser vos designs plus rapidement, permettre à tous de les lire, et ne pas utiliser toute la RAM de votre ordi ? 

Chez Sirup lab, cela fait plus de 2 ans que nous utilisons Figma intensément sur plus de 15 produits. Nous avons affiné nos méthodes au fur et à mesure pour réaliser de meilleurs designs : plus simples à utiliser, à maintenir et à développer.

Dans un premier article nous parlons des principes base pour prendre en main Figma. Ici, nous allons sur les choses avancées qui vous feront aller beaucoup plus vite. 

Voici notre retour d’expérience. 

Comment gérer les états ?

Problématique

Chaque composant et chaque écran vont avoir plusieurs états.

  • Actif / inactif / hover
  • En chargement / vide / en erreur / en scroll / complet

Ces états doivent être maintenus en cohérence.
Si on modifie un bouton dans l’état complet, on doit s’assurer que c’est aussi le cas dans tous les autres états.
Sur la moindre application, nous observons rapidement une 50 aines d’états.
Les maintenir en cohérence sans organisation prend beaucoup de temps.

Solution

Utiliser un composant qui les contient tous

Chaque écran est un composant.

Il contient tous les états sur différents layers qui seront cachés suivant la situation.

Nous utilisons les autolayouts pour que les mises en page s’adaptent lorsque des éléments sont cachés.

Créer un composant pour les états clés

Nous encapsulons les états clés dans un nouveau composant.
Cela nous permet de les mettre à jour rapidement si nous les utilisons dans un prototype.
Cela nous permet aussi d’utiliser la surcharge, notamment sur un composant.
Les écrans sont organisés en colonne. Cela nous permet de vérifier qu’une modification fonctionne bien dans tous les états.

Résultat

Si cette solution demande plus d’effort à la composition, elle permet toutefois des mises à jour très rapides.
Nous avons régulièrement plus d’une centaine de petites modifications.
Nous pouvons les faire en quelques heures au lieu de quelques jours.
Un design très cohérent et une réduction des corrections lors du développement.

Comment gérer les tailles d’écran ?

Problématique

Nous travaillons régulièrement sur des applications qui s’adaptent du plus grand au plus petit écran.

Nous utilisons pour ça les recommandations de Material Design.

Ces écrans peuvent s’afficher sur un nombre variable de colonnes. 

Ils peuvent rester centrés (grille fixe) ou s’adapter sur la largeur (grille flexible).

Solution

2 layouts et des composants pour les panels

L’écran contient 2 mises en pages.

Une première à 2 colonnes qui sera utilisée pour les grands écrans.

Une seconde à 1 colonne pour les plus petits.

Ces colonnes contiennent les mêmes composants.

Cela permet de modifier à un seul endroit toutes les versions.

Nous créons ensuite une instance pour chaque taille d’écran.

Et nous n’affichons que la bonne mise en page en fonction de la taille.

Un autolayout global pour gérer le padding

Les contenus sont inclus dans un autolayout.
Par défaut, l’autolayout prend toute la place disponible (scale) et son contenu est centré.
Il s’agit d’une grille fixe.

Dès que l’écran est trop étroit, nous changeons les règles.
Le contenu de l’autolayout se contraint pour prendre la place disponible.
Tout le contenu s’organise automatiquement.
Les espacements deviennent plus compacts et les textes sont adaptés.
Cela reste néanmoins la même instance. Il est donc possible de modifier pour le web et pour le mobile à un seul endroit.

Voici le Figma contenant ces exemples🎁.

Résultat

Encore une fois cette solution demande plus de rigueur sur la composition. Une fois le mécanisme compris, la déclinaison sur toutes les tailles d’écran est très rapide.

Ce système est très proche de ce qui est fait techniquement. Cela donne donc aussi l’avantage d’être simple à transposer et plus rapide à développer.

Comment maintenir un design system à jour sans trop d’effort avec la bonne organisation ?

Problématique

Pour une agence de design, chaque produit est un design system différent.
Nous travaillons sur des applications qui font plus de 50 pages écrans et qui doivent rester cohérentes.
Ces applications ajoutent de nouvelles fonctionnalités régulièrement.
Nous avons expérimenté différentes organisations pour faire face à ceci.
Voici notre retour d’expérience.

Solution

Un Figma contenant un design system simple

La shared library contient les composants et le thème de l’application.
Il ne contient pas de choses complexes comme des écrans.
Maintenir les composants est coûteux et on se focalisera donc sur ce qui n’en change pas d'un projet à un autre.

Nous travaillons actuellement sur un design system encore plus minimaliste pour faciliter la composition.

Un Figma par version de l’application

Pour chaque nouvelle version d’une application, nous créons un nouveau Figma. Organiser ceci par version permet d’éviter les problèmes de chronologie. Par exemple, travailler sur 2 évolutions qui modifient le même écran.

Nous lions la shared library pour réutiliser le thème et les composants.

Nous commençons en général par un audit de la zone à modifier.

Il y a parfois des déviations entre les derniers designs et ce qui est réellement disponible.

Parfois nous n’avons pas de Figma pour la zone étudiée. 

Nous utilisons une page de travail incluant :

Les flots utilisateurs organisés en prototype

Une zone d’exploration pour les designs en attente de validation

Les composants propres à ces flots. Nous créons un composant à chaque fois qu’une partie de l’interface se répète.

Tous les écrans organisés en colonnes.

Tout avoir sur une même page permet de vérifier plus rapidement l’impact d’une modification. Voici un de nos fichiers qui utilise cette structure 🎁. 

Nous ne déplaçons pas systématiquement les composants d’une version dans le système. Notre design system est cependant corrigé et modifié en continu. Nous utilisons le même fichier sur plusieurs projets. Nous continuons de l’améliorer encore aujourd’hui.

Résultat

Nous utilisons maintenant ce système depuis plus d’1 an sans modification majeure.
Nous avons plusieurs versions de notre Design System, qui s’améliore en parallèle sur chaque produit. Nous essayons de garder la version la plus aboutie comme nouvelle base pour la suite.

Avant ça nous avons exploré beaucoup d’options plus difficiles à maintenir.
Notamment, il faut rester très vigilant sur la taille du Figma. De gros fichiers contenant beaucoup d’images peuvent utiliser toute la mémoire de votre ordi et sont longs à ouvrir.

Changer d’organisation peut demander beaucoup d’effort.
Notamment il est difficile de déplacer une arborescence de composants d’un fichier à un autre.

Conclusion

3 choses à retenir :

  • Utiliser un composant pour chaque écran pour pouvoir mettre à jour ces états et les prototypes à un seul endroit.
  • Utiliser les autolayouts et la surcharge pour décliner les versions web et mobile.
  • Garder un petit système, qui sera plus simple à maintenir et plus facile à utiliser

La prochaine fois nous parlerons de … 

  • Comment s’assurer qu’un design utilise tous les raccourcis de la technologie tout en restant innovant ?
  • Comment corriger son design efficacement en utilisant les commentaires ?
  • Comment utiliser Figma pour ses spécifications techniques ?

Besoin d’aide sur Figma ? Contactez-nous 💌.

Nous proposons de l’encadrement et des forfaits de designs accessibles aux startups.


S'inscrire à notre newletter

Nous envoyons une fois par mois nos nouveaux articles, tutoriaux et notre veille technologique

Merci ! Nous avons bien reçu votre inscription.
Oups ! Quelque chose n'a pas marché lors de l'envoi.