Créer votre propre design system

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

Cet article est le deuxième volet d'une série en trois parties visant à explorer en profondeur l'expérience du développement, de la production et, finalement, de la diffusion du design system de Workday. Consultez la Partie I, Les design systems : l'affaire de tous.

Acceptez la complexité

Les design systems sont le secret du secteur pour proposer des expériences utilisateur d'entreprise à grande échelle. En fonction de la taille et de la complexité de votre entreprise, un design system peut aller d'un autocollant à un produit entièrement développé. Chez Workday, nous avons choisi de traiter le nôtre comme un produit.

Depuis la création de notre design system il y a trois ans, Workday a connu une croissance fulgurante. Aujourd'hui, nous comptons plus de 12 000 collaborateurs, ainsi que des centaines d'applications de produits uniques. Ils ont pour objectif commun de soutenir des clients qui emploient plusieurs milliers, voire plusieurs centaines de milliers de personnes. Qualifier notre écosystème de complexe serait donc un euphémisme.

Le canevas du design system de Workday a été conçu pour s'adapter pleinement à notre taille et à notre complexité. Il a été développé pour fonctionner comme un produit autonome, afin de faire ce que les design systems font le mieux : permettre aux utilisateurs de créer efficacement des expériences cohérentes et de haute qualité.

Dans cet article, nous expliquons comment notre design system est devenu un « produit pour les produits » et ce que cela signifie pour nous en tant que designers. Nous sommes conscients qu'il n'existe pas de « système universel » dans le monde des design systems d'entreprise, mais nous espérons que notre point de vue et nos enseignements vous aideront à relever les défis et à réussir à concrétiser votre projet de design system.

Traitez votre design system comme un problème de design

Cela semble évident, mais l'un des aspects les plus complexes du design de systèmes en entreprise est l'identification et la hiérarchisation tous les utilisateurs et parties prenantes de votre système. Contrairement aux équipes qui se concentrent sur un produit ou un utilisateur spécifique, notre design system implique un grand nombre d'utilisateurs dispersés. Parmi les différents groupes d'utilisateurs figurent les employés qui utilisent Workday, les professionnels qui travaillent au sein de Workday, les développeurs internes qui conçoivent Workday et les développeurs externes qui créent une application unique en dehors de Workday.

Afin d'identifier et de hiérarchiser

les groupes d'utilisateurs les plus importants, notre équipe a cartographié les parties prenantes. Ensemble, nous avons dressé la liste de tous les rôles, équipes et organisations concernés par le canevas de Workday ou pouvant influer sur le système. Nous avons ainsi découvert que les designers et les développeurs constituent nos groupes d'utilisateurs les plus importants. Nous avons donc mené des recherches qualitatives et quantitatives auprès de ces groupes afin de mieux comprendre les éléments de notre système qui leur convenaient et ceux qui ne leur convenaient pas.

Ces recherches ont permis de créer un registre d'informations par thèmes spécifiques aux design systems, tels que la communication, la documentation et l'enseignement, qui, aujourd'hui, influencent directement nos priorités. Elles nous permettent également de nous recentrer lorsque nous nous dispersons ou remettons en question notre objectif, ou encore lorsque nous recevons des demandes ad hoc qui dépassent le cadre défini de notre équipe.

Points clés :

• Abordez votre design system comme un problème de design axé sur l'humain.
• Pensez à cartographier les parties prenantes afin de déterminer qui sont vos utilisateurs prioritaires et d'identifier les personnes concernées par les changements apportés à votre système.

Privilégiez les ressources spécialisées

Nous avons également transformé notre système en produit en engageant des ressources dédiées à la gestion des produits et à l'ingénierie pour collaborer avec notre équipe de designers. En tant qu'équipe disposant de nouvelles ressources, notre première initiative a été de proposer des kits de développement en open source pour notre design system. (Nous aborderons ce sujet plus en détail dans la troisième partie de cette série).

Notre chef de produit a mis au point des artefacts comme des feuilles de route et des backlogs et a mis en place des rituels tels que la planification de sprints, les présentations quotidiennes et les rétrospectives. Nos designers ont réalisé un processus de création de composants internationaux, accessibles et réutilisables, puis ont travaillé en étroite collaboration avec notre équipe de développeurs pour définir et coder notre système, consolidant ainsi le statut de source fiable d'informations en constante évolution du canevas de Workday.

Il s'agissait de notre première tentative en tant qu'équipe de produit entièrement interfonctionnelle et cela s'est avéré être un véritable succès. La planification de sprints nous a aidés à rester concentrés et à prioriser nos efforts, les présentations quotidiennes nous ont responsabilisés et permis de rester informés, et les rétrospectives nous ont donné le temps de réfléchir, de nous améliorer et de célébrer nos victoires.

Dans le monde des systèmes d'entreprise, tout peut facilement sembler complexe. La mise en place du processus, de la structure et des ressources adaptés a prouvé les capacités de réussite de notre équipe.

Points clés :

• Si vous envisagez d'utiliser votre design system comme un produit, vous aurez besoin d'ingénieurs, de designers et de chefs de produit dédiés.
• Instaurez des routines et des processus afin de donner à votre équipe des priorités et des objectifs concrets.

Développez votre service de conseil

Si vous travaillez sur des design systems, vous avez probablement l'habitude de recevoir des messages du type « Bonjour ! Je souhaiterais utiliser ce nouveau composant bouton que j'ai créé pour mes cas d'utilisation spécifiques »

Cela ressemble beaucoup à une demande de fonctionnalité, n'est-ce pas ? Avant que notre design system soit considéré comme un produit, ce type de demandes aurait fait soupirer notre équipe à l'unisson, consternée par une demande aussi insolente. Mais, d'un point de vue réaliste, il nous semblait impossible d'évoluer aussi rapidement que prévu avec le nombre de ressources dédiées dont nous disposions. Tenter, pendant de nombreuses années, de garder un contrôle total sur notre design system était une erreur.

Notre ego et l'idée de vouloir à tout prix être conformes rendaient l'évolution de notre système difficile. Nous avons alors réalisé que nous devions laisser nos utilisateurs prioritaires, nos designers de produits et les besoins de leurs utilisateurs guider l'évolution de notre design system à notre place. Cette prise de conscience nous a fait changer d'état d'esprit : au lieu de contrôler l'évolution de notre système, nous l'avons facilitée et guidée avec la contribution des designers et des développeurs.

Au cours du projet open source, nous avons commencé à encourager le design et le développement de notre kit en open source par le biais d'une approche fédérative. En effet, grâce à la contribution extérieure des équipes de développement et de design qui souhaitaient participer à la construction ou à la réutilisation de nos composants, nous avons pu répartir la charge de travail et favoriser une adoption plus large au sein de l'entreprise.

Afin de pouvoir gérer les demandes de « fonctionnalité », nous avons mis en place un processus de réception ayant pour première étape d'écouter nos utilisateurs. Nous avons appris à poser les bonnes questions comme « Dans quel cas l'utiliseriez-vous ? », « En quoi les composants existants ne répondent-ils pas à vos besoins ? » et « Quelles doivent être les variables et les propriétés de ce composant pour qu'il réponde à vos besoins ? » . Les échanges de ce type permettent de partager la responsabilité et la propriété du système, et donnent à l'utilisateur la possibilité d'avoir un impact direct sur son amélioration.

Dans le même temps, nous nous sommes demandé « Dans quelle mesure cela pourrait-il profiter aux équipes chargées des applications et des produits ? », car il est tout aussi important de penser de manière globale et d'établir des liens entre tous nos produits et toutes nos plateformes que d'être à l'écoute de nos utilisateurs.

Points clés :

• Soyez à l'écoute et posez toujours des questions.
• Faites des designers et des développeurs des équipes produits vos principaux contributeurs.
• Soyez capable de déterminer quand tirer parti de la pensée systémique.

Définissez votre processus de gestion du changement

Comme lors de la création d'un produit, concevoir notre design system a nécessité de nombreuses parties prenantes. C'est en janvier 2019 que nous avons commencé à œuvrer pour faire de notre design system un système en open source, et la réalisation de cet objectif nous a ouvert les yeux sur les impacts du changement dans l'écosystème complexe de notre entreprise. Alors que de plus en plus d'utilisateurs commençaient à utiliser notre système pour créer des produits, nous avons constaté que cela aurait des conséquences, notamment sur la maintenance de l'intégrité de notre système en constante évolution.

Lorsque nous élaborions et développions notre design system pour en faire un système en open source, nous n'avons pas tenu compte de la façon dont les changements proposés impacteraient l'ensemble de l'entreprise. Par exemple, pour une question d'accessibilité, nous avons choisi de changer la couleur des boutons principaux, passant de l'orange au bleu. Nous avions conscience que ce type de changements auraient des conséquences importantes pour les designers et les développeurs, mais nous n'avions pas pris en compte l'impact plus large qu'il aurait sur les équipes. Notre équipe chargée de l'enseignement, par exemple, a constaté un impact important sur le matériel pédagogique qu'elle a créé.

Pour que notre équipe fonctionne comme un produit soutenant d'autres produits, il était important d'adopter une gestion du changement volontaire et de porter une attention particulière aux nouveaux ajouts du système. La mise en œuvre de mesures de gestion du changement nous a contraints à créer des environnements de test afin de vérifier les contributions avant de les intégrer à notre bibliothèque principale, puis à communiquer régulièrement avec toutes les parties prenantes concernées. La gestion du changement nous aide à gérer la qualité de notre bibliothèque principale de composants et réduit les problèmes liés au manque de communication et aux erreurs de production mineures, mais fatales. Tout comme la plupart des expériences douloureuses, celle-ci nous a beaucoup appris et nous a permis de nous améliorer en tant qu'équipe.

Points clés :

• Quelle que soit la taille de votre design system, trouvez un moyen d'évaluer les conséquences de chaque changement.
• Mettez au point un processus d'assurance qualité et des environnements de test avant l'intégration à votre bibliothèque principale.

Continuez à vous développer

Chez Workday, nous sommes conscients du défi que représente la création d'un système fiable capable d'évoluer et de s'adapter au changement. En 2016, notre entreprise était en pleine expansion et nous recherchions un moyen de garantir la cohérence et la qualité. Nous avons tâtonné pendant des années avant de trouver le processus adéquat. Au fil de notre évolution, nous continuerons à agir ainsi, car les design systems changent constamment, et c'est ce qui nous passionne. Les avantages de la transformation de notre design system en produit a donné lieu à des résultats concrets. Nous avons pu identifier et hiérarchiser nos groupes d'utilisateurs les plus importants, créer des routines et des artefacts pour nous guider, mais aussi en apprendre davantage sur l'impact de nos décisions. Et à présent, qu'allons-nous faire ? En tant que produit, les prochaines étapes consistent à approfondir la recherche et la validation, à développer l'enseignement et la formation, et à continuer à donner à nos utilisateurs les moyens de créer des expériences cohérentes et de haute qualité, tout en facilitant un peu plus leur travail.

Dans la troisième et dernière partie de cette série, nous verrons comment Workday a plaidé en faveur d'un design system ouvert et a diffusé ses kits de développement. Vous pouvez retrouver la Partie I, Les design systems : l'affaire de tous, ici.