6 questions sur les succès et les échecs d’un design system

Ces derniers temps, je participe à la conception initiale d’un design system, et je me pose beaucoup de questions.

À ce sujet, voici quelque chose que j’ai lu la semaine dernière sur UX Collective. Je l’avais traduit pour les membres de l’équipe design system de mon entreprise, et comme ce serait dommage de le garder pour moi, je le partage aussi ici.

Il s’agirait d’un résumé réalisé à partir d’entretiens avec 10 designers travaillant sur des design systems.

Question 1. Comment échouer dans un rôle lié au DS ?

• Se comporter comme la police

• Utiliser le pouvoir du designer (parler politique)

• Unifier les composants sans jamais les utiliser réellement

• Travailler en réaction après coup au lieu d’anticiper les besoins des équipes

• Ne pas écouter ni étudier la voix des utilisateurs (autres designers ou développeurs)

• Créer un DS pour le DS lui-même

• Ne pas maintenir une roadmap et des processus clairs pour le travail à accomplir

• Concevoir une expérience idéale impossible à mettre en œuvre

• Ne pas tester avec les équipes

• Ne pas comprendre le DS comme un produit à part entière

• Créer des outils sans former les gens à leur utilisation

• Apporter trop de théorie déconnectée des façons de travailler réelles

• Penser qu’on peut le faire seul

• Ne pas se concentrer à 100 % sur le partage de connaissances avec quelqu’un de l’équipe technique

• Créer des composants trop peu flexibles et ne pas autoriser le détachement

• Ne pas demander d’aide ni créer de liens avec les autres (en interne comme en externe)

• Dicter des règles de loin au lieu d’être au plus près du terrain

Question 2. Quelles soft skills sont nécessaires pour qu’un DS réussisse ?

• Communication, communication, communication !!!

• Être avec les utilisateurs, écouter, poser des questions et mener des recherches est vraiment essentiel.

• Reconnaissez humblement vos échecs

• Faites preuve de patience

• La capacité à créer un espace sûr

• Savoir transmettre

• Proposer une vision structurée de la réutilisation

• Il faut préserver une cohérence ferme, même à grande échelle

• Quand il s’agit de comprendre les autres, il n’est pas nécessaire de trop s’y projeter. Acceptez les règles telles qu’elles sont.

• 95 % relèvent des hard skills, et 5 % des soft skills nécessaires quand les règles sont enfreintes.

• Encouragez la progression des gens et partagez-la

• L’autonomie

• Continuez à vendre le produit (le DS)

• Pensez de manière stratégique

• Faites participer tout le monde

• Faites du bruit autour du DS

• Consacrez autant de temps que possible à identifier autant de scénarios que possible

• Alignez le langage utilisé.

Question 3. La façon de faire un DS doit-elle être plus centralisée ou plus distribuée ?

Il existe deux approches : une équipe centralisée qui vérifie comment les gens conçoivent et en porte la responsabilité, et une autre où tout le monde en est responsable. J’ai demandé aux gens laquelle leur semblait la bonne.

• Nous sommes une équipe trop centralisée, ce qui crée des goulots d’étranglement. Mais un modèle distribué peut aussi entraîner une dilution de l’ownership.

• Nous avons une équipe de designers de plus de 100 personnes pour centraliser le DS.

• Nous collaborons avec les bibliothèques alpha créées par les équipes, et c’est à partir de là que nous constituons le backlog de l’équipe DS.

• Nous formons les gens pour qu’ils créent spontanément des composants.

• Le choix de centraliser ou non est en grande partie politique. Avant de le décider, il faut savoir précisément quel niveau de scalabilité est nécessaire.

• Il faut ajuster les attentes et faire participer les gens à la construction du DS.

• Nous voulions collaborer, mais ne savions pas vraiment comment, alors nous avons créé un processus. (Culture vs Process)

• Au départ, on peut être un peu moins collaboratif pour assurer la livraison. Avec la maturité, on peut devenir plus collaboratif.

• Nous sommes maintenant arrivés au moment où il faut décentraliser ; il faut apprendre aux gens comment contribuer.

• Si vous ne formez pas les gens, ils ne contribueront pas.

• Quand un designer veut dépasser les standards pour produire quelque chose de meilleur, il faut pouvoir réfléchir en même temps à la façon de le standardiser.

• Un DS ne peut pas être porté par 1 ou 2 personnes. Puisqu’il s’agit de construire un système, le DS doit commencer au niveau des squads.

• Cela dépend énormément de la taille des équipes, et parfois l’équipe DS peut se concentrer sur le développement des composants core pendant que d’autres ambassadeurs les diffusent.

-Au final, nous sommes une équipe centralisée, mais nous travaillons de manière collaborative avec des ambassadeurs. La décision finale revient à l’équipe DS.

4. Pensez-vous qu’un DS doive être un ensemble de règles détaillées et restrictives, ou quelque chose de plus large et ouvert, laissant aux designers la liberté de créer de nouvelles mises en page ?

Fermé ou ouvert ? Si vous travaillez sur un design system, cette question vous intéressera sans doute. C’est mon cas, donc j’ai décidé de la poser aux autres.

• Sur l’"accessibilité", il faut adopter une approche plus restrictive

• Nous sommes tous partis d’une structure de base, mais nous avons commencé à créer certaines incohérences. Nous avons donc décidé d’imposer davantage de contraintes sans être 100 % fermés. En parallèle, nous essayons toujours de trouver un moyen de rendre quelque chose aux designers

• Cela dépend du contexte, donc mesurez d’abord le risque avant de décider. En général, petite équipe = plus grande flexibilité

• Il ne s’agit pas simplement de créer des composants nouveaux et créatifs. Il faut des composants suffisamment flexibles pour répondre aux besoins des gens

• Le DS, c’est du business. Moins il y a de composants, mieux c’est.

• Les gens doivent prendre plaisir à utiliser le DS. Vu de l’extérieur, on peut facilement penser que c’est comme un uniforme et qu’il n’a pas besoin de flexibilité (mais ce n’est pas le cas)

• On ne peut pas être très restrictif dès le départ. Avec suffisamment de temps, cela peut commencer à évoluer vers certains patterns spécifiques.

• Pour les designers qui rejoignent l’entreprise, plus de contraintes peuvent être utiles. Pour enfreindre les règles, il faut d’abord partir des règles.

• Nous fournissons suffisamment d’ingrédients pour que les gens puissent créer leurs propres recettes.

• Cela dépend du niveau de maturité des équipes. S’il y a davantage de juniors, ils ont tendance à demander plus de guidelines design, car ils comprennent moins bien une documentation légère. Cela demande donc plus de formation, mais nous essayons malgré tout de leur laisser de la liberté au lieu de les enfermer. Le plus grand défi consiste à amener les gens à lire et utiliser eux-mêmes la documentation ; il est donc possible de la rapprocher davantage des designers, par exemple via Figma.

• Pour tout ce qui touche à l’accessibilité et à l’esthétique, il faut être plus restrictif.

• Les tokens sont importants pour maintenir la cohérence.

• Une bonne documentation trouve le bon équilibre entre harmonisation et liberté laissée aux personnes.

Question 5. Que pensez-vous d’un DS lié au branding et au marketing ?

Je maîtrise mal ce sujet, donc la traduction n’a pas été simple.

Je comprends qu’un design system doive avant tout concerner les produits numériques, mais comme le produit peut être l’une des plateformes de marque les plus importantes, je voulais savoir comment les gens relient les deux dans leur réflexion.

• Une façon de penser au branding lié au DS consiste à réfléchir à la manière dont, en retour, il influence le DS.

• Nous avons commencé à aligner le design system sur la marque afin d’harmoniser l’apparence et le ressenti de la marque.

• Le DS sert la scalabilité et l’identité de marque, mais le lien entre les deux dépend de l’équipe branding.

• Since DS is a language, MKT could support with assets for it;

• L’équipe branding doit rejoindre le DS dès le départ afin d’établir les règles de base.

• Cela dépend des entreprises. Le DS est un outil de renforcement de la marque, donc l’alignement est important. Le lien entre les deux domaines influence aussi l’accessibilité du DS.

• Il est important de trouver une manière de se synchroniser avec l’équipe branding pour aligner les stratégies.

• They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;

• Parfois, on peut utiliser ensemble la documentation et le système, mais le plus souvent non. Le DS, c’est l’interface. L’équipe marque dispose séparément d’un "branding system", et il est plus courant que les bibliothèques interagissent entre elles. Les deux ne sont pas totalement identiques.

Question 6. Comment mesurer le succès d’un DS ?

• Enquêtes de perception pour comprendre l’engagement, l’adoption et l’état des équipes

• Couverture des composants (à quel point le DS est utilisé vs ce qui est codé en dur)

• Adoption

• Time to market

• ROI

• Figma Analytics

• Réactions des équipes de développement

• Accessibilité

• Nombre d’utilisations des composants

[xguru]

Ah, c’est super. Merci pour ce récapitulatif !