Les arguments en faveur d'un design system ouvert

Les fonctionnalités mentionnées dans cette publication nécessitent un forfait Organisation Figma. En savoir plus.

Cet article est le troisième d'une série en trois parties visant à explorer en profondeur l'expérience de Workday en matière de développement, de production et, finalement, de diffusion de son design system. Consultez la Partie I, Les design systems : l'affaire de tous, et la Partie II, Créez votre propre design system.

Fondamentalement, tout design system repose sur la communauté créée autour de lui. Définie par la transparence et l'inclusion, celle-ci constitue le cœur, le moteur du Design system Canvas de Workday. En d'autres termes, nous nous efforçons d'être ouverts.

Dans cet article, nous vous expliquerons ce que « être ouverts » signifie pour nous, en tant que vision, mais aussi concrètement au quotidien au sein de Workday.

En mouvement vers l'ouverture

Notre design system n'a pas toujours été un concept « ouvert », et nous pouvons affirmer qu'à ses débuts, un design system ne devrait en général pas l'être. Certains concepts et idées doivent être protégés et développés jusqu'au moment opportun. Concernant Canvas, un gros travail en coulisses a d'abord dû être effectué pour sa mise en œuvre (pour en savoir plus à ce sujet, vous pouvez consulter la partie 2 de notre série). Puis, au vu de son adoption croissante, nous avons eu besoin d'être plus transparents dans nos décisions et avons décidé d'ouvrir le système à nos utilisateurs et à leurs suggestions.

Notre chemin vers une ouverture totale est continu. Bien que nous ayons entrepris cette démarche il y a peu, nous avons néanmoins retenu trois leçons que nous aimerions partager avec vous :

1. L'accessibilité entraîne le progrès
2. Travailler de manière ouverte favorise la communication et la prise de responsabilités
3. Ralentir dans un premier temps permet d'accélérer par la suite

L'accessibilité entraîne le progrès

Vous arrive-t-il parfois de rester bloqué sur une idée ? Que ce soit pour le codage ou la création de designs, un simple changement de perspective peut se révéler très productif. Il peut s'agir d'un client dont la vision fait apparaître un nouveau point de vue concernant un vieux problème. Ou encore d'une remarque pertinente de la part d'un collègue de confiance. Ou tout simplement d'une promenade dans la nature (vraiment !). S'ouvrir à des perspectives nouvelles peut véritablement relancer notre cerveau.

Dans notre cas, la recherche de nouvelles perspectives est passée par un élargissement de notre design system. Il a eu lieu en deux grandes étapes : nous avons tout d'abord migré nos outils de design de produits vers Figma, une plateforme basée sur le cloud ; dans un deuxième temps, nous avons migré nos bibliothèques de développeurs (Canvas Kit) vers Github.com afin de rendre notre code source accessible à tous et à tout moment. En conséquence, un plus grand nombre d'équipes peut aujourd'hui voir ce que nous faisons, et leurs perspectives nous permettent de faire d'incroyables progrès, très rapidement.

D'une manière générale, un trop grand nombre d'avis peut ralentir un processus. Nous avons remarqué que les feedbacks nous ont aidé à prendre de meilleures décisions, plus rapidement. Étant donné le large éventail d'utilisateurs et de produits que comprend notre suite, les cas limites, l'accessibilité, et les optimisations des composants nécessite un important effort de recherche et de diffusion. Ces besoins sont maintenant intégrés à notre processus et apparaissent comme des résultats naturels de l'augmentation de l’accessibilité de notre système.

Les imperfections se changent en améliorations

Autre conséquence bénéfique de l'élargissement de l'accès de votre design system, vos imperfections se changent en améliorations. Même les design systems les plus éprouvés comportent des imperfections. Chez Workday, nous avons dû traiter des problèmes de composants manquants ou incompatibles dans nos bibliothèques Figma et résoudre des bogues de compatibilité entre les navigateurs dans le code base. À chaque fois qu'une personne attire notre attention sur ce type de problèmes, nous nous améliorons. Depuis la mise en open source de Canvas Kit, en juillet 2019, nous avons résolu plus de 90 bogues dans notre code base. Un grand nombre d'entre eux ont été solutionnés par des contributeurs ne faisant pas partie de notre équipe. En outre, depuis notre migration vers Figma, la taille de notre communauté Canvas sur Slack a plus que doublé. Chaque semaine, ses membres nous signalent au moins un problème de compatibilité au sein de notre design system. En tant que concepteurs, nous avons souvent tendance à vouloir masquer nos imperfections, afin de présenter un produit impeccable. Ne cédez pas à cette tentation. Cela ne fonctionne pas pour les design systems, car ils font office de fondation pour le design de produits. Plus nous découvrons ses imperfections rapidement, plus nous sommes à même d’améliorer rapidement la plateforme dont notre communauté a besoin.

Le développement se diversifie

La création d'un design system réellement évolutif est une tâche quasiment impossible pour une seule équipe, étant donné la profonde expertise nécessaire à la conception, au développement, à l'accessibilité, à l'internationalisation et aux tests. Le moins que l'on puisse dire est que cela peut être décourageant. Il est important pour nous de tirer profit des connaissances des différents experts qui nous entourent, afin de créer un design system entièrement fonctionnel pour tout le monde. Et c'est par l'ouverture qu'il est possible d'atteindre cet objectif. Par exemple, nos experts en accessibilité effectuent régulièrement des audits sur des composants nouveaux et existants, sachant qu'ils ont accès à tout moment à notre code le plus récent et le plus abouti.

En aucun cas nous ne considérons que le simple fait qu'un design system soit plus ouvert suffise à résoudre les problèmes par le crowd-sourcing. Nous pensons néanmoins que, en tant que système ouvert, son développement se diversifie. La véritable valeur ajoutée d'un tel système se reflète par la manière dont nous sommes capable de multiplier l'impact des différents points de vue au sein du design system. Les équipes qui n'avaient qu'un accès limité aux experts en la matière voient maintenant l'expertise de ces derniers s'ajouter indirectement à leurs produits via les composants du design system, les bibliothèques Figma et la documentation.

Plus de surveillance, pour davantage de durabilité

Si le fait d'être « plus ouvert » semble synonyme d’être davantage surveillé, c'est parce que c'est le cas. Mais, dans un design system ouvert, plus de surveillance signifie davantage de durabilité. En ouvrant notre design system au monde, nous nous ouvrons à d'autres points de vue concernant la manière dont nous travaillons, notamment pour identifier les points à améliorer. Et ainsi faire changer les choses.

Pour cela, nous avons pris de nombreuses mesures d'assurance qualité, tels que des tests de régression visuelle pour tous les navigateurs pris en charge, ainsi que des processus formels de documentation, essentiellement parce que de nombreuses équipes scrutent le moindre de nos gestes. Cependant, cette surveillance joue en notre faveur et nous avons fait de gros progrès, notre design system étant aujourd'hui mieux documenté et plus durable.

Le degré d'ouverture de votre design system dépend principalement des objectifs de votre organisation. Cependant, nous recommandons de vous efforcer d'être ouvert à un maximum de perspectives. Nous avons constaté que prendre le temps de créer et développer une communauté, sous le signe de la transparence et de l'ouverture, favorisait la contribution. Cela crée un sentiment de propriété et signifie également qu'un plus grand nombre de personnes participe à la croissance du design system, ce qui est tout aussi important. Certaines équipes qui contribuent le plus à notre code base aujourd’hui sont celles avec lesquelles nous avons étroitement communiqué et collaboré.

Travailler de manière ouverte favorise la communication

Si la communauté constitue le cœur d'un bon design system, le développement ouvert peut être considéré comme les veines et les artères : il garantit la circulation des principes essentiels à une bonne communication, tels que la transparence, la clarté et la responsabilité. Lorsque nous parlons de « développement », il ne s'agit pas seulement de notre code base sur Github. Cela inclut également nos spécifications relatives au design ainsi que la documentation sur des plateformes telles que Figma et Confluence. Tout le monde est également bienvenu sur nos canaux Slack et invité à participer à nos démos de sprint.

Notre ouverture signifie non seulement que nous dévoilons notre code, mais aussi la manière dont nous travaillons en tant qu'équipe. Les démos bimensuelles que nous organisons pour notre kit d'ingénierie passent en revue les modifications à venir ou les fonctionnalités récemment publiées. Nous expliquons pourquoi ces modifications ont été effectuées et tout commentaire est le bienvenu. Cette ouverture permet aux utilisateurs de notre design system de comprendre les raisons et les bénéfices de ces modifications. C'est un peu comme présenter votre copie après un devoir de mathématiques. Si votre professeur voit que votre approche du problème était correcte bien que vous n'ayez pas trouvé la bonne solution, il comprendra votre raisonnement et vous accordera peut-être une partie des points.

En faisant preuve de transparence, nous favorisons la collaboration avec la communauté et les développeurs utilisant notre code base. Avant de devenir open source, cette approche nous a également permis d'instaurer une certaine confiance au sein de notre organisation.

Favoriser l'ouverture et l'inclusion produit un effet intéressant : le développement ouvert nous force à être responsables. Plus nous avons d'équipes qui dépendent de Canvas, plus nous nous sentons responsables de répondre à des demandes et des attentes toujours plus nombreuses, et de fournir des résultats concluants. Cela peut paraître effrayant. Mais la peur, si elle reste raisonnable, est loin d'être une mauvaise chose en soi ! En 2019, la plus importante requête que nous avons reçue nous demandait d'établir une feuille de route et un agenda des mises à jour. Nos utilisateurs veulent savoir ce qui arrive, et quand. Pour y répondre, nous avons donc créé un canal Slack en lecture seule permettant aux personnes de s'informer de notre actualité.

Ralentir dans un premier temps permet d'accélérer par la suite

Comme tout autre produit, les design systems ne sont pas à l'abri d'une dette technique.

Plus votre système évolue, plus votre base d'utilisateurs doit elle aussi évoluer. Une fois que vous avez un système dont vous êtes satisfaisant, son évolution doit respecter un équilibre entre vitesse et qualité. Nous savons qu'il est important de constamment itérer pour donner de l'importance à vos utilisateurs. Cependant, considérer l'impact d'une modification sur vos utilisateurs et le système lui-même l'est encore davantage.

Pour notre design system, modifier la façon dont un composant interagit avec les autres est un exemple concret de « breaking change ». Il doit être soigneusement géré et documenté. Cela concerne les modifications techniques, mais aussi visuelles. Changer la couleur d'un bouton ou augmenter la taille d'une police peut avoir des conséquences plus vastes. Par exemple, cela pourrait modifier la mise en page ou l'application dans son ensemble, ce qui risquerait ensuite d'affecter les composants et leurs interaction, les tests, voire nécessiter une mise à jour de la documentation. Au sein d'un design system, ces modifications peuvent créer des frictions. Elles sont inévitables, mais une gestion de la cadence de publication des versions peut aider à les atténuer.

Nous avons mis en place des mécanismes de communication concernant les modifications planifiés via des journaux de modifications. Nous notons tout, depuis la mise à jour de la dépendance à une bibliothèque jusqu'à un « breaking change » visuel. Nous utilisons le versionnage sémantique pour gérer les « breaking changes » apportés à une version majeure. Cela nous permet d'informer aisément nos utilisateurs des modifications.

Si nos processus sont en place, nous affinons toujours notre approche des « breaking changes » visuels. Notre objectif est de faire en sorte que nos modifications soient bien comprises. Afin de réduire les frictions qu'elles engendrent, nous envisageons la création d'une procédure de mise à niveau des équipes couplée à des canaux de communication adéquats.

Nous continuons à travailler sur la fréquence de diffusion des version majeures. Nous réfléchissons à la manière d'aligner l'évolution visuelle sur la publication des produits Workday, qui a lieu deux fois par an. En nous alignant sur cette cadence, il nous est possible d'utiliser des processus internes relatifs à la gestion des modifications pour nos clients. En revanche, un alignement des « breaking changes » techniques sur cette cadence n'est pas nécessaire.

L'ouverture amplifie l'impact d'un design system

Certes, la création d'un design system ouvert mérite une attention particulière. Mais en ce qui nous concerne, les avantages d'un tel système nous ont permis de développer une communauté autour du design ouvert.

En ralentissant le rythme des modifications, nous avons pu augmenter l'impact de notre design system, à mesure que nous progressons.

L'ouverture entraîne la transparence. Tout le monde sait comment et pourquoi nous faisons les choses. Cette transparence nous permet de boucler la boucle. Elle nous permet d'augmenter notre vitesse d'itération et d'apporter une valeur ajoutée aux équipes utilisant notre design system afin qu'elles puissent offrir aux utilisateurs une expérience cohérente et de qualité.