Zoom sur : qu’est-ce qu’un Product Designer ?
Product Designer, UX Designer, UX/UI Designer … Est-ce la même chose ? On vous aide à y voir plus clair dans cet article !
Vous avez très certainement entendu parler de design system récemment, puisque ces derniers fleurissent un peu partout depuis quelques années.
Souvent rendu accessible au grand public par les sociétés à l’origine de leur conception, certains sont devenus de véritables références, comme celui d’IBM avec
ou encore
pour Google.
Et pour cause, l’utilisation d’un design system apporte plusieurs bénéfices :
Dans un premier temps, nous allons nous intéresser à la mise en place de l’espace de travail. Définir quels sont les fichiers essentiels pour disposer de fondations pertinentes, avant de s’intéresser à leurs contenus.
Dans un second temps, nous verrons comment établir une documentation complète pour les utilisateurs du design system.
Celui-ci est divisé en deux sections.
Au cœur se trouve la partie design ; elle contient les éléments intervenants dans la composition des produits digitaux.
Ces derniers sont ensuite récupérés dans la partie documentation, afin d’y définir un cadre d’utilisation et les comportements liés aux différents types d’interactions. C’est là l’une des différences majeures avec un UI kit. La notion de documentation est ici extrêmement importante et doit être intégrée au produit dès son lancement.
S’il est possible de faire cohabiter ces deux sections sur un logiciel dédié au design, il est toutefois recommandé d’adopter des outils spécifiques plus appropriés. Cela permet d’optimiser votre productivité, mais également d’avoir une meilleure gestion des accès.
💡 Figma, récemment racheté par Adobe, est à ce jour l’outil de conception le plus adapté à la création d’un Design System et s’accorde parfaitement avec Zeroheight et Storybook pour la partie documentation.
Avant d’entrer dans le vif du sujet, il est primordial de s’attarder un instant sur la notion de design moléculaire sur laquelle repose le design system.
Cette méthodologie largement adoptée depuis la publication en 2016, du livre Atomic Design de Brad Frost remet en question l’approche traditionnelle de conception écran par écran, en inversant le processus établi. Partir des éléments fondamentaux appelés “atomes”, avant de les combiner à d’autres éléments pour former des molécules, organismes ou encore templates, afin d’atteindre l’objectif de création d’une interface.
L'idée sous-jacente est qu’en travaillant à partir des éléments de base, il est possible de créer des designs plus flexibles qui évoluent avec les besoins du produit. En utilisant ce système de conception modulaire, les équipes peuvent gagner en agilité et en efficacité.
Encore un peu de patience, ne faites pas l’erreur de vous lancer tête baissée dans la création de vos composants !
Un design system reste avant tout un produit, il est donc indispensable de définir les besoins à satisfaire. L’un des objectifs du design system est de rationaliser et de mutualiser les ressources.
Une fois ce cadre défini, il est important d’organiser au mieux son espace de travail. Anticiper tant que possible le développement du produit et par conséquent sa segmentation. L’intérêt est d’offrir une structure efficace et de vous prémunir de potentiels ralentissements causés par des fichiers trop volumineux.
La première brique du design system ! Cette section, à ne pas négliger, contient les fondations communes à l’ensemble des fichiers. Il s’agit d’une librairie de composants destinés à harmoniser la structure des fichiers et à guider l’utilisateur. On y retrouve fréquemment les templates Getting started, Overview, Release patch note, ainsi que des illustrations dédiées à la documentation.
La pièce maîtresse ! C’est ici que l’ensemble des composants seront répertoriés.
Cette section contient également les guidelines, qui définissent les principes graphiques appliqués aux différents produits (couleurs, grilles, espacements, iconographie, ombre, flou, typographie, etc)
Ces règles sont essentielles pour cadrer le travail des designers et conserver un écosystème harmonieux tout au long du cycle de vie des produits.
Souvent réduites à une notion purement esthétique, les guidelines représentent bien plus. Puisqu’une mauvaise exécution de ce document entraînera à coup sûr une dette design conséquente, ralentira la production et la collaboration des équipes.
Enfin ! Il est temps de concevoir les premiers composant du design system. Les plus fins observateurs auront sans doute remarqué le fichier Master. Celui-ci comporte les composants “sources”, qui seront employés dans Component pour décliner les différentes variantes.
L’objectif des composants master est de paramétrer les caractéristiques communes aux variantes du composant, comme par exemple les propriétés de l’auto-layout. L’intérêt de cette pratique est de pouvoir opérer des changements rapides sur des composants disposant d’un grand nombre de variants. Ainsi, un changement de radius sur l’élément master se répercutera automatique sur l’ensemble des composants issus de ce dernier.
Le composant master finalisé, il est dupliqué et de nouveau déclaré comme étant un composant (instance “Primary”). Ainsi, l’ensemble des variants issus de cette instance seront affectés par les changements effectués sur le master.
Il est temps de donner vie à vos composants. Les prototypes permettent d’en évaluer la pertinence via des tests utilisateurs, mais également de faciliter la compréhension des comportements et des interactions attendues auprès des équipes de développement.
Il est important de décrire les différents états d’un composant et de définir les interactions pour les atteindre. C’est l’objectif du fichier Component, décrire l’ensemble des comportements pour chacun des composant du design system.
Il n’est pas rare d’avoir des éléments qui sont amenés à évoluer au sein d’un ensemble pour être pertinent. Le fichier Flow permet de contextualiser et d’illustrer des cas d’usage concret en détaillant le comportement d’un organisme ou d’une page.
S’ils constituent l’essentiel des fichiers de votre Workplace et comblent la majeure partie de vos besoins, il est possible d’enrichir cet espace avec d’autres fichiers :
💡 Dupliquez certains de ces projets pour mieux gérer les accès entre les différents parties prenantes. Effectuez régulièrement des releases sur la base du fichier source en documentant tous les changements réalisés.
Une fois votre espace de travail organisé, attardons-nous sur la structure des fichiers.
La mise en place d’un design system prend du temps, il est donc recommandé d’introduire chaque fichier par quelques pages d’onboarding (référencer les templates utilisés dans la toolbox permet d’effectuer des changements rapides sur l’ensemble du design system et d’harmoniser les fichiers), pour faciliter la prise en main du produit par de nouveaux intervenants.
Chaque page correspond à un composant. Cependant certaines exception comme les tableaux peuvent nécessiter d’être diviser en plusieurs pages pour préserver les performances.
Le tri des pages n’est pas soumis à une règle d’optimisation particulière. Libre à chacun de trier comme bon lui semble, la plupart des design system adoptent un simple tri alphabétique.
En revanche, l’attribution d’un code couleur permet d’avoir de la visibilité sur le statut de production des composants :
💡 En pratique, la meilleure façon d’opérer un changement est de l’isoler via le système de branch de Figma. Cela permet de garantir l’intégrité des éléments existants pendant toute la durée de l’intervention. Attention toutefois à ne pas effectuer un trop grand nombre de modification sur une seule et même branch, ou de tarder à publier cette dernière, au risque d’être confronté aux limitations techniques de l’outil.
S’il est préférable d’adopter des outils spécifiques, avoir une copie de la documentation sur le fichier de design permet de centraliser l’information, mais également de conserver une source en cas de changement du support de documentation.
Il y a plusieurs avantages à utiliser une documentation.
Tout d'abord, elle permet une meilleure collaboration entre les différents départements de l'entreprise en fournissant un cadre commun de référence. De plus, elle assure la cohérence de la marque en s'assurant que tous les produits respectent les standards établis.
Pour ce faire, il est possible de combiner différents types de documentation, chacun ayant son propre objectif et son public cible. Les deux outils les plus courants sont Zeroheight et Storybook.
Zeroheight est une plateforme de documentation qui fournit une vue d'ensemble de tous les composants de design utilisés dans un système de design. Cette documentation est souvent utilisée pour fournir une référence visuelle des différents éléments de design. Elle permet également aux designers de voir comment ces éléments s'assemblent pour former des pages et des écrans complets.
Storybook, quant à lui, est un outil de documentation et d'affichage interactif pour les composants. Il permet aux développeurs de visualiser les différents états et interactions dans un environnement de développement isolé. Cela permet aux développeurs de s'assurer que les composants fonctionnent comme prévu et de tester rapidement sans besoin d’intégration.
La documentation constitue donc d’un élément crucial pour une entreprise ou une organisation soucieuse de l'expérience utilisateur et de la cohérence de la marque en étant accessible à un large éventail d'utilisateurs.
Il est courant d’introduire la documentation par les fondations sur lesquels reposent votre design system. Ils définissent les valeurs et la démarche de l’entreprise en matière de design. Il peut y être décrit l’organisation du design system, les différents produits impactés, l’équipe mise à contribution et les objectifs à plus ou moins longs termes.
L’intérêt de Zeroheight est de disposer d’un environnement dissocié de l’outil de conception pour approfondir les notions relatives à l’usage. Il faut savoir adopter le point de vue d’un utilisateur dont la mission est de concevoir une interface et qui ne possède aucune connaissance en matière de design system. L’objectif est donc de contextualiser au maximum (en utilisant le fichier illustration pour représenter différents cas d’usage).
Il s’agit des règles qui définissent la façon dont les composants doivent être utilisés, construits et personnalisés. Il est courant d’introduire la fiche d’un composant par une courte description et de référencer les acronymes qui lui sont associés. Les éléments qui composent le composant ou les différentes variantes de ce dernier sont ensuite détaillés pour donner les premières indications aux utilisateurs.
Les différents variants du composant sont ensuite listés et accompagné d’une description, de façon à ce que l’utilisateur puisse facilement déterminer le variant le plus adapté à son cas d’usage.
Le bouton étant l'un des éléments les plus couramment utilisés dans les interfaces, voici un exemple de ce que pourrait donner la description des variants les plus communs :
Primary : le bouton primaire est utilisé pour les actions principales dans l'interface. Il est conçu pour être facilement repérable et est souvent associé à la couleur principale.
Secondary : le bouton secondaire est utilisé pour les actions secondaires dans l'interface. Il est conçu pour être moins visible que le bouton primaire, mais toujours facilement repérable. Il est souvent associé à une couleur secondaire.
Tertiary : le bouton tertiaire est utilisé pour les actions mineures dans l'interface. Il est conçu pour être le moins visible des trois types de boutons, mais toujours facilement repérable. Il est souvent associé à une couleur de la marque qui n'est ni la principale ni la secondaire.
Danger : le bouton danger est utilisé pour les actions qui ont des conséquences négatives pour l'utilisateur ou l'application. Il est conçu pour être facilement repérable et est souvent associé à une couleur rouge.
Text : le bouton texte est utilisé pour les actions qui n'ont pas besoin d'un bouton aussi visible que les autres types de boutons. Il est conçu pour être le moins visible de tous les types de boutons et est souvent utilisé pour les actions telles que l'annulation ou la fermeture d'une boîte de dialogue.
Respectivement les états enable, hover, active, focus et disable du variant primary d’un bouton.
Évoqué précédemment, les usages servent à décrire le contexte dans lequel le composant va évoluer et à donner des exemples concrets d'utilisation. Par exemple, une liste de produits, un formulaire de contact, une barre de navigation, etc.
Les do and don'ts sont les règles d'utilisation des composants qui décrivent ce qui est recommandé et ce qui est à éviter. Par exemple, il peut être recommandé d'utiliser un bouton pour effectuer une action, plutôt qu'un lien, et il peut être déconseillé de modifier la couleur d'un bouton pour des raisons d'accessibilité. Les do and don'ts sont généralement basés sur les meilleures pratiques en matière de conception d'interface utilisateur et d'accessibilité.
Un exemple de do & don’ts qui recommande l’usage de texte concis dans les bouton.
Pour conclure la documentation d’un composant, il est courant de rediriger vers des composants qui sont étroitement liés ou dépendants de celui précédemment documenté (par exemple, une barre de navigation peut inclure des sous-menus).
Storybook permet aux développeurs et aux designers de visualiser et de tester facilement des composants de façon indépendante sans avoir à exécuter l’application complète. L'un de ses avantages est qu'il permet aux équipes de travailler de manière plus efficace en facilitant la collaboration entre les développeurs et les designers.
De plus, cet outil permet aux équipes de documenter et de maintenir les composants de manière efficace. En utilisant Storybook, vous pouvez créer une bibliothèque de composants qui peut être utilisée comme référence par toute l'équipe.
C’est ici l’occasion d’aborder une notion liée aux guidelines, celle du Design Token.
Les tokens et les atomes sont deux concepts liés à la méthodologie de conception atomic design, qui vise à organiser les éléments visuels d'une interface utilisateur en utilisant une hiérarchie de niveaux d'abstraction.
Si les atomes décrivent les composants basiques d'une interface, les tokens sont des variables qui décrivent les propriétés visuelles d'une interface, comme la couleur, la typographie, les espacements, etc. Ils permettent de maintenir une cohérence visuelle à travers une interface en définissant des règles de style qui peuvent être utilisées dans tous les composants.
Il y a plusieurs avantages à utiliser des design tokens :
Il existe plusieurs façons de définir les tokens dans un projet.
Voici quelques étapes couramment suivies pour les définir et les gérer :
La documentation du design system est essentielle pour garantir que tous les membres de l'équipe comprennent et appliquent la convention de nommage. Celle-ci doit être mise à jour régulièrement pour refléter les évolutions du design system.
En conclusion, l'organisation d'un design system est cruciale pour garantir une expérience utilisateur cohérente et une mise en œuvre efficace des produits.
L'organisation de l'espace de travail aide à maintenir la qualité et les performances, notamment en mettant en place une segmentation claire et efficace des fichiers. La documentation complète et cohérente des différents composants du design system est également essentielle pour permettre une collaboration efficace entre les différents départements de l'entreprise et pour garantir la conformité aux standards de conception.
Investir du temps pour organiser correctement le design system aura des répercussions positives à long terme sur l'efficacité du développement de produits et leur cohérence. En fin de compte, une organisation bien conçue peut aider à accélérer davantage le processus de développement, à améliorer la qualité des produits et éviter tant que possible la création de dette design.
Une dernière chose ! Pour conclure cet article, il est essentiel de mettre en avant l'importance de suivre et de mesurer les performances de votre design system en définissant des indicateurs de performance clés (KPI), comme par exemple le temps de production. Mettre en place un processus de tracking sur l’utilisation des composants et d'autres métriques clés vous permettront d’évaluer son efficacité afin de prendre des décisions informées pour l'améliorer.
—
Tu souhaites lire plus d'articles sur le Design ?
Retrouve tous nos articles de Product Design sur notre blog !
Nous croyons en un nouveau modèle de consulting où l’excellence commence par l’écoute, le partage et une vraie vision