Scalabilité, UX & Design system : enjeux au cœur des interfaces
Si le design et l’expérience utilisateur est un enjeu clef de votre produit, vous avez intérêt à mettre en place les bons outils pour que vos interfaces puissent croître aussi vite que les autres éléments de votre produit.
Au cours de cet article — a défaut d’une traduction adéquate — je vais utiliser l’anglicisme scale ou scalabilité. Il serait possible d’utiliser le terme d’industrialisation, cependant, dans ce contexte, je le trouve moins adapté.
La scalabilité désigne une logique de mise à l’échelle.
Dans un contexte de croissance il s’agit d’outils et de techniques permettant de faire grandir un produit, service et équipe de façon optimisée — traduit par un gain de temps et de coût — tout en maintenant un niveau de qualité élevé.
Le design ne devrait-il pas être scalable ?
Il semble évident qu’appliquer une logique de scalabilité à tous les outils d’une entreprise en pleine croissance est une bonne idée. Le design ne devrait donc pas en être exclu.
La question du Design system semble aujourd’hui centrale — et à la mode — lorsque le produit atteint une certaine maturité. De nombreux exemples sont là pour le montrer : Airbnb, le Material Design de Google, Altassian, Intercom, Shopify, Microsoft, Salesforce…
Beaucoup de ces entreprises mettent en valeur leur Design system avec deux écueils identifiables :
- Le Design system existe pour résorber une dette graphique ou UX sur des produits ayant connu plusieurs années de développements. Cette dette coûte si cher que les moyens alloués à sa résolution sont énormes.
- Le Design system n’améliore en rien l’UX du produit 😐 Son utilité sert donc les designers. Il ne découle pas d’une volonté d’amélioration aussi à destination des utilisateurs. Cependant l’enjeu de scalabilité et le gain de temps induit par l’approche reste valable.
J’ai la conviction forte que si le design est au centre du produit il doit être scalable au même titre que tous les autres métiers et outils du produit qu’il sert.
J’ai la conviction forte que cet enjeu doit exister lors des balbutiements du produit, il doit accompagner la croissance de notre produit le plus tôt possible.
Et c’est d’ailleurs un de nos paris chez Pretto : la mise en place des outils nécessaires à la scalabilité de nos interfaces le plus tôt possible.
J’ai la conviction forte qu’un Design system doit servir le produit mais aussi — et surtout ! — les utilisateurs et l’UX.
Il était une fois…
…une équipe travaillant sur la nouvelle version mobile de leur application.
Cette équipe a vite rencontré le même problème que beaucoup d’autres avant elle.
- Nous (ré)inventions la roue à chaque écran, chaque jour.
- Nous devions nous poser chaque jour les mêmes questions.
- Nous devions souvent refaire chaque élément ceci à chaque écran pour une variation minime.
- Nous avions une approche “écran” par “écran”, non pas globale.
Ceci est rapidement frustrant car nous savions qu’il n’était peut-être pas nécessaire de repartir de zéro pour chaque ajout à notre interface ni d’y passer autant de temps.
Le résultat ?
Une belle anarchie que nous avons — très rapidement — eu du mal à maintenir.
A ce moment, le constat est simple :
- Nous devions trouver une façon de faire pour simplifier notre travail sur les interfaces ;
- Nous devions simplifier le travail de design et celui de l’équipe technique.
Il n’est pas si évident d’avoir le réflexe, en amont, de créer une interface sous forme de “kit” plutôt qu’un tableau d’ensemble — souvent inconsistant — écran par écran.
Imaginons une maison : nous avons tendance à imaginer de suite l’endroit où nous allons vivre — le résultat final — non pas référencer le nombre de briques et d’éléments divers qu’il faudra pour la construire.
La vision
En appliquant un ensemble de bonnes idées et d’outils il est possible de résoudre beaucoup des problèmes rencontrés, à la fois à court, moyen et long terme.
La finalité d’une logique de scalabilité se porte à long terme et elle ne peut pas s’exonérer de la place de l’UX et de l’utilisateur.
La mise en place d’un Design system doit impérativement répondre à 5 enjeux forts :
- Faciliter la vie des designers : éviter les questions, ne pas réinventer la roue, définir des règles et des bibliothèques graphiques partagées et facile à utiliser par tous ;
- Faciliter la vie des développeurs : la logique de code front-end et de design convergent. Les développeurs mettent également en place les outils pour faciliter et partager des bibliothèques de composants ;
- Faciliter la communication entre les membres des équipes produit : en unifiant notre approche nous unifions notre vocabulaire ;
- Faciliter la vie des utilisateurs : permettre de se concentrer sur l’UX, offrir une interface et une expérience consistante ;
- Aller vite : concevoir et développer des interfaces très rapidement en maintenant un haut niveau de qualité, c’est la finalité à atteindre.
Un bon artisan ne sort jamais sans ses outils
Nous avons à notre disposition plusieurs outils et méthodes de conception qui nous permette de simplifier la création de nos interfaces et la mise en place d’une approche scalable.
Ces outils vont structurer le travail de notre équipe mais aussi permettre de partager :
- Une vision commune ;
- Une terminologie partagée qui va simplifier les échanges.
1. Le styleguides, base de votre Design system
Votre styleguides est la base du Design system : une bible qui va référencer vos éléments graphiques, édicter des règles d’usage, des spécifications…
La deuxième partie pour cette “bible” c’est d’en créer une réplique en front-end (HTML, CSS, REACT…) qui va être maintenue et utilisée par les développeurs.
Vous n’avez donc pas un styleguides, mais deux :
- Un pour vous : dans votre logiciel de création d’interfaces ;
- Un pour les développeurs, maintenu par eux : il va simplifier leur travail sur le front.
Ce n’est pas uniquement des éléments graphiques, vous définissez :
- Les spécifications des éléments : margin, padding, font size ;
- L’utilisation, la valeur et les règles des espaces pour vos éléments ;
- Vos règles d’usage ;
- Vos breakpoint en responsive design ;
- Le comportement de vos éléments ;
- Les animations à utiliser en fonction du contexte…
N’hésitez pas à documenter les éléments importants pour la création de vos interfaces. En les centralisant vous pourrez les retrouver facilement par la suite.
Autre point important : un Design system n’est pas figé.
Il va évoluer au fil du temps, avec votre produit. Sur ce sujet — comme sur de nombreux autres — une méthode itérative me semble la plus productive.
Pour construire un Design system j’utilise plusieurs approches qui facilitent grandement la conception d’interface. Elles aident également à structurer intelligemment notre approche autant pour les designers que pour les développeurs.
2. Atomic Design
Cette méthode de conception d’interface à été mise au point par Brad Frost.
http://bradfrost.com/blog/post/atomic-web-design/
De plus, Audrey Hacq présente très bien cette méthode ici
L’idée directrice consiste à décomposer l’interface en “brique” ayant la plus petite taille possible. Ces briques sont la base de votre interface, elles sont nommés atomes.
Une fois que vous avez une assez grande quantité d’atomes vous pouvez composer vos interfaces.
En associant vos atomes vous pouvez créer des molécules, en assemblant vos molécules vous créez des organismes.
Ces éléments ensemble permettent de créer des templates, composant ainsi les écrans de votre produit.
L’avantage de cette méthode c’est qu’en partant des plus petits éléments il est facile de composer des interfaces très différentes qui répondent bien aux différents problèmes rencontrés.
Il est également plus simple de découper son interface en éléments (atomes) de très petites tailles, cela sera plus souple et facile à maintenir que de créer des ensembles de composants graphique de plus grande taille.
Autre bonne nouvelle
Nous avons à notre disposition 2 outils très performants qui sont à l’aise avec ce concept d’atomes : Sketch et React.
Ces deux outils, chacun dans leur domaine, ont une approche qui permet de découper l’interface en atomes.
3. 8pt Grid System
L’autre grand problème lors de la conception d’interface — mais aussi de la communication des spécifications techniques aux équipes — concerne les espaces.
Les espaces, c’est la cerise sur le gâteau : l’élément qui va créer le rythme de vos interfaces, vous avez passé du temps à les harmoniser avec amour ❤.
Le 8pt Grid System offre l’avantage d’une règle unique — utilisé, par exemple, par Google — permettant de renforcer la consistance de vos interfaces.
Combien de fois avez vous eu cette discussion avec des développeurs :
Êtes vous sûr que les valeurs sur votre maquette sont les bonnes ?
Parfois les espaces sont à 15px, parfois à 12px.
Bien sur, il existe aussi un autre endroit où vous avez mis un espace à 16px.
Oui. C’est. Pénible.
Avec le 8pt Grid System, c’est terminé.
Vous n’avez qu’une règle à retenir et à expliquer : tous vos espaces et vos éléments graphiques sont un multiple de 8.
Fin de l’histoire.
4. Sketch + symboles + librarie
Sketch offre dans deux outils très pratiques : les symboles et les librairies.
Les symboles sont parfaits à utiliser comme des atomes.
Vous constituez votre bibliothèque de symboles/atomes, vous pouvez très facilement piocher dedans pour composer vos écrans.
Avec la récente fonctionnalité Librairie vous pouvez partager ces symboles entre tous vos documents Sketch et les modifier dans un seul fichier, mettant ainsi à jour toutes les occurrences.
5. Code = Design = Code
Une des clefs de la réussite de cette approche c’est la reproductibilité de ces éléments en code front-end.
Si vous arrivez à appliquer ces méthodes pour concevoir vos interfaces dans Sketch, vous avez intérêt que la logique front-end soit le plus possible la reproduction de votre approche de design.
React avec ses composants est un outil puissant et parfait pour cela. Si vous considérez qu’un atome = composant vous pouvez très facilement reproduire votre travail graphique directement en composants React.
Chez Pretto notre styleguides côté front-end se compose d’exemple des éléments d’interface mais aussi de la documentation avec les props et des exemples d’utilisation.
Pour la réalisation de notre styleguides React nous utilisons Styleguidist.
Voici les premiers éléments qui compose notre approche Design = Code, permettant de faire reposer l’ensemble sur une base commune. Bien exploitée cette base peut vous faire gagner beaucoup de temps et vous offrir des gains réels lors de la croissance de votre produit et de vos équipes.
Notre organisation est résumée par le schéma ci dessus.
- Les fichiers Sketch sont versionnés avec Abstract (qui utilise Git).
- Le styleguides contient nos atomes / molécules / organismes…, exemples et règles d’utilisations des composants de nos interfaces.
- Les symboles du styleguides sont organisés dans une librairie Sketch, qui permet la synchronisation avec les différents fichiers de travail.
- Invision & Inspect nous permettent de passer les interfaces aux développeurs en économisant du temps sur les spec graphiques.
- Notre styleguides Sketch permet aux développeurs front-end — en collaboration avec l’équipe design — de créer des composants React et d’alimenter son styleguides.
- Pour finir, ce sont les composants React qui sont utilisés lors du développement front de nos applications.
Des gains, mais pas au casino
Vous gagnez en vitesse et en agilité
Je parle souvent d’agilité et de la nécessité d’une approche itérative pour le design.
L’un des principaux avantages de la mise en place d’une stratégie de scalabilité du design est la vitesse et la simplicité — à terme — avec laquelle vous allez pouvoir créer vos interfaces.
Vous souhaitez tester une idée ? Réaliser un A/B test sur une page ? Ou modifier un écran ?
Grâce à vos atomes, vos styleguides et vos composants React vous allez pouvoir le faire beaucoup plus vite.
Peut-être même sans réaliser de maquettes définitives !
Les développeurs savent déjà quels éléments composent un écran, ils connaissent les règles d’espacement et peuvent s’appuyer sur le styleguides pour comprendre facilement ce que vous imaginez.
Chez Pretto, en quelques heures nous sommes capable de créer et mettre en production un nouvel écran en utilisant nos composants.
Vous avez aussi un langage et une approche commune, vous gagnez donc lors de vos échanges.
Vous êtes capable de travailler plus vite pour concevoir et développer vos interfaces, ceci sans dégrader la qualité finale de votre produit.
Vous améliorez l’expérience de vos utilisateurs
Deuxième gain visible de cette approche c’est l’amélioration de l’expérience utilisateur.
D’abord parce qu’en gagnant du temps sur la conception des interfaces vous pouvez consacrer plus de ressources pour parler à vos utilisateurs, tester votre UX, vos prototypes, vos interfaces et à itérer sur les idées qui peuvent l’améliorer.
L’autre versant de cette approche c’est qu’elle vous permet de gagner en consistance.
Or plus votre interface est consistante — dans le bon sens — plus elle offre une facilité d’utilisation homogène.
Vous gagnez en maintenabilité
Un gain important dans une approche de ce genre est le gain en maintenabilité et la réduction de la dette graphique.
Votre styleguides et vos interfaces sont “vivants”, ils vont évoluer au fil du temps.
En utilisant une approche par composant React vous pouvez modifier un élément — un atome — une seule fois. Le résultat est immédiatement visible et va impacter tous les écrans de votre produit.
C’est également le cas dans Sketch : en modifiant un symbole vous modifiez tous les écrans qui l’utilisent.
Cependant il arrive qu’une modification puisse créer une dégradation graphique. C’est aussi à vous d’anticiper et de bien cloisonner vos atomes, leur aspect graphique et leur comportement dans un template.
Pour palier ce type de problème nous travaillons à faire en sorte de réduire un atome à son strict minimum : sa représentation graphique la plus basique.
Vous pouvez détacher le plus possible l’aspect graphique d’un élément et son placement définitif dans un layout / template.
Vous facilitez la croissance des équipes et la collaboration
Lors des recrutements il sera plus facile de transmettre les éléments et les bonnes pratiques, ils sont rassemblés et documentés au sein de votre Design system.
Les designers et les développeurs front-end peuvent en quelques heures faire le tour et comprendre les éléments qui composent les interfaces sans avoir obligatoirement besoin d’une longue formation.
Nous évoquions aussi plus haut un langage commun. La convergence des approches entre le design et le développement front permet de créer un référentiel pour mieux collaborer. Ainsi nous facilitons la communication métier et alignons les différentes parties des équipes produit.
Quelques conseils, à garder en tête
1. Ayez une vision d’ensemble.
Avoir une vision d’ensemble est très important.
Cette vision représente la finalité de votre travail sur l’interface.
Même s’il est difficile de se projeter tôt dans un projet sans avoir réalisé plusieurs écrans vous ne pouvez pas créer un puzzle en dessinant les pièces une par une. Vous devez obligatoirement visualiser le tableau d’ensemble avant de la découper.
Un conseil pour bien commencer ?
Partez des éléments les plus communs à toutes les interfaces : nuancier, style de texte, boutons, formulaires, card…
Ces éléments sont une bonne base d’interface. Ils n’ont pas l’obligation d’être définitifs et vous pourrez ensuite les améliorer en itérant dessus. Vous allez également en ajouter au fur et à mesure que vos interfaces deviennent matures ou que vous ajoutez des fonctionnalités.
Dernier point : l’expérience vous aide à avoir une vision d’ensemble sans obligatoirement créer toute l’interface.
2. C’est une décision collective
Si vous souhaitez que la sauce prenne vous devez impliquer tout le monde : fondateur, CTO, développeurs, équipe produit…
Il s’agit de votre vision, mais il s’agit surtout de la vision de ce que va devenir le produit, de sa valeur finale pour les équipes et pour les utilisateurs.
Votre premier objectif doit donc être d’embarquer toutes les parties prenantes pour avancer dans la même direction.
3. N’attendez pas qu’il soit trop tard !
De nombreux exemples me laissent penser qu’il est important de placer cette vision de scalabilité du design et la mise en place des bons outils en amont d’un projet.
Un fois que vous avez commencé à développer votre produit, que vous avez réalisé plusieurs écrans, vous avez déjà commencé à créer du chaos, un langage non partagé donc de la dette graphique et technique…
Reprendre tout ce travail plusieurs mois plus tard — ou plusieurs années, comme c’est le cas de Spotifiy — aura un coût beaucoup plus élevé que de mettre en place les bons outils dès le début.
Conclusion
Les gains sont nombreux à mettre en place un Design system au service de la scalabilité de vos interfaces, soyez cependant sûr de résoudre les bons problèmes. Et, surtout, ne réalisez pas un Design system au détriment de votre UX !
Notre approche repose sur plusieurs mois d’expérience, des réussites et des échecs… Comme pour toutes les méthodes, celle-ci peut encore être amélioré de multiples façons pour répondre à vos besoins. La voie est ouverte…
Quelques articles pour aller plus loin
Spotify — design doesn’t scale
Un bon exemple de dette graphique : les interfaces Spotify ont été développées pendant plusieurs années sans guide précis, par beaucoup de designers différents, au fil de leur croissance.
Le résultat : des interfaces inconsistantes et la mise en place de beaucoup de ressources pour résoudre le problème.
Airbnb — DLS
Un Design system au service du produit et de l’utilisateur.
Airbnb travaille également à créer des outils capables de faciliter l’automatisation entre les éléments front-end et design (Sketch).
React Sketch.app est le parfait exemple d’un outil qui pousse encore plus loin l’approche scalable des interfaces.
BlaBlaCar — Stop designing interfaces, Start designing experiences
Une approche similaire — inspirée de l’Atomic Design — mise en place chez BlaBlaCar.
