Radiant, ThoughtSpot design system – Portfolio de Christophe Coutzoukis
J’ai été embauché en février 2018 par le VP de l’expérience pour construire le système de conception de l’entreprise. Quelques tentatives avaient été faites avant mon temps, mais aucune n’avait gagné l’élan nécessaire.
Après m’être familiarisé avec la situation et interviewé les parties prenantes à plusieurs niveaux, j’ai réalisé que même si tout le monde – des cadres aux concepteurs et aux ingénieurs logiciels – était d’accord sur le principe qu’un système de conception serait une bonne chose à avoir, n’a jamais été une priorité. Autrement dit: ce n’était pas une nouvelle fonctionnalité que vous pouvez vendre.
Pour réussir, j’avais donc besoin d’une stratégie en deux parties: créer un excellent produit interne (avec quelques gains rapides et faciles) et le commercialiser avec succès auprès de mes utilisateurs (concepteurs et développeurs), ainsi que de toute l’entreprise – y compris l’équipe de direction.
Stratégie marketing: aller à la guérilla
Bien que je sois intimement convaincu que les systèmes de conception sont une excellente méthodologie pour produire n’importe quel type de logiciel – sinon le seul – c’est encore un concept relativement nouveau dans l’industrie.
C’est pourquoi vous devez considérer votre système de conception comme un produit ou – pour le dire encore mieux – une startup à l’intérieur de la startup, perturbant la façon dont les choses étaient faites auparavant. Vous devez trouver votre stratégie d’ajustement au marché, et plus important encore, vous devez être fort et créer une marque claire à intégrer par votre public cible, avec presque pas de ressources.
Pour commencer à créer un élan, j’ai dû:
- trouver un nom: après discussion avec le VP Expérience, nous avons choisi Radiant, car il était proche d’un concept géométrique (Radius) utilisé dans la visualisation des données et il avait une lueur intéressante, étant central et touchant tout ce qui l’entoure – en plus c’est rad.
- créer un logo: J’ai informé l’un des concepteurs visuels les plus talentueux de ThoughtSpot (Wei Zheng) et elle a créé un logo qui représentait le R de Radiant avec 3 formes géométriques différentes (un rectangle, un disque et un triangle) symbolisant le fait qu’un système de conception est une somme de différentes parties, tout en étant en harmonie avec le logo de la marque pour une association claire
- diffuser la nouvelle marque: J’ai dérivé le logo en autocollants, t-shirts, icônes et thème Slack, etc.
Et ça a marché! Lentement mais sûrement, les gens à l’intérieur de l’entreprise ont commencé à intégrer le système de conception comme quelque chose d’évident, et à perdre de vue à quel point le t-shirt de l’équipe Radiant était cool.
Stratégie organisationnelle: le modèle fédéral
Pour la première année, j’étais la seule personne entièrement dévouée au système de conception. Mais au fur et à mesure que le projet prenait de l’ampleur, j’ai agrandi l’équipe pour quelque chose qui était proche de mon idéal en termes de progrès à un rythme décent:
- 2 designers: un autre senior crée des conceptions pour les composants, et un autre qui aide également à créer les composants pour la bibliothèque de conception (Sketch, puis Figma)
- 2 ingénieurs logiciels: un senior pour être mon homologue côté Ingénierie et échafauder l’infrastructure et le middleware du projet (Framework JavaScript, repo, Storybook, suite de tests, etc.) et un qui créerait des composants pour le système
- 2 ingénieurs UX: généralement plus intéressés par les aspects visuels des choses que les autres développeurs, ils ont également pu collaborer étroitement avec les concepteurs lors de la création des composants du système
- 13 h: cet ajout à l’équipe était plus stratégique car je devais avoir un champion du côté produit, et elle me donnait d’excellents conseils sur la meilleure façon de suivre nos progrès
- Je dirigeais l’équipe, en tant que chef de projet technique et contributeur individuel, mettant en place l’architecture globale et les outils du front-front-end le développement (pensez HTML, Sass / CSS, JavaScript de présentation) et le côté design (bibliothèques Sketch et Figma)
Cette équipe n’a jamais été aussi officielle que les autres équipes V de la société – et j’ai dû surfer sur beaucoup d’ambiguïtés – mais elle a néanmoins été cohérente tout au long du processus de création de la première itération et d’une équipe permanente solide.
Le véritable avantage du modèle fédéral est venu lorsque nous avons eu l’occasion de monter à bord tous les designers de l’équipe Experience au-dessus d’une poignée d’ingénieurs logiciels pour un temps limité: la société a décidé de consacrer un trimestre entier à améliorer les fonctionnalités existantes du produit plutôt que d’en créer de nouvelles, et nous avons saisi cette opportunité pour faire des progrès considérables sur Radiant.
Plus important encore, tous ceux qui sont finalement retournés dans leurs propres équipes ont emporté avec eux une grande connaissance du système et sont devenus ses champions dans toute l’entreprise.
Il est également intéressant de noter que tout le monde ne peut pas penser au niveau du système et que l’équipe permanente a dû soutenir les nouveaux arrivants pour s’assurer qu’ils fournissaient le meilleur travail possible. D’un autre côté, il est vraiment utile d’avoir la contribution des personnes qui utilisent réellement le système et créent les nouvelles fonctionnalités du produit de l’entreprise afin que vous ne finissiez pas par travailler à partir de votre tour d’ivoire et que vous soyez totalement détaché de l’équipe produit et indirect. mais des utilisateurs cruciaux de votre système: les clients réels de votre entreprise.
En fin de compte, je pense que le but d’un système de conception est de définir comment produire quoi que ce soit dans une entreprise de logiciels avec la barre la plus élevée possible en termes de qualité, de cohérence et de vitesse.
Mais chaque système de conception a un contexte et – contrairement aux bibliothèques de composants – ne peut pas être simplement transposé d’une entreprise à une autre. Pensez à la marque de l’entreprise, aux valeurs fondamentales, à la pile technologique…
Et pour le rendre efficace, je dirais que cela se résume à 3 aspects différents:
- comment prendre les meilleures décisions système
- comment organiser efficacement les décisions
- comment communiquer les décisions au bon moment et au bon endroit
Comment prendre les meilleures décisions système
Il y a tellement de décisions à prendre lors de la production du contenu d’un système de conception: meilleures pratiques techniques, principes de conception, processus, langage partagé, conventions de dénomination des fichiers, palette de couleurs, choix d’outils…
Pour vous simplifier la vie, j’ai présenté une North Star, la proposition de valeur fondamentale de Radiant: Facilitez-vous la bonne chose.
C’était simple, mémorable, et pourtant aiderait à naviguer dans la complexité: cela signifiait que nous aiderions les développeurs et les concepteurs à faire ce qui était le mieux; bien qu’ils avaient la possibilité de faire autrement, ce serait juste plus difficile.
Lorsque j’ai rejoint l’entreprise pour la première fois, nous étions 4 membres de l’équipe Experience, et il y avait tellement de terrain à parcourir que j’ai introduit une nouvelle forme de réunion: The One-Topic Meeting®.
L’idée derrière cela était que tout le monde dans l’équipe était invité (et facultatif) à participer et que pour chaque réunion, nous n’aurions qu’un seul sujet à discuter longuement et, espérons-le, à épuiser.
Les sujets peuvent être n’importe quoi: conventions de dénomination des fichiers d’esquisse, boutons radio, troncature, polices…
Et à la fin de chaque réunion, nous notions toutes les conclusions que nous avions formulées et passions à la suivante.
Quand nous avons commencé, nous avions 3 réunions comme celles-ci par semaine – j’avais besoin de réponses!
Nous avons examiné collectivement tout le travail sur les composants effectué par l’équipe de conception (c’est là qu’il est extrêmement précieux d’avoir des ingénieurs UX dans la salle pour ajouter la perspective technique), puis toutes les spécifications de conception ont été écrites par le créateur du composant, examinées par à au moins un autre designer (plus moi, la plupart du temps), avant d’être transféré sur notre portail de documentation.
L’équipe Radiant a également eu une synchronisation deux fois par semaine afin que les informations essentielles soient communiquées et validées à travers les services.
Comment gérer efficacement les décisions
Nous pouvons prendre les meilleures décisions au monde, mais elles ont tendance à être éphémères: deux semaines après une discussion, qui peut se souvenir exactement de ce qui a été décidé et pourquoi? Il est particulièrement important dans un environnement de démarrage lorsque les nouveaux arrivants arrivent à un rythme régulier. La connaissance tribale est un point douloureux de mise à l’échelle très insidieux et difficile, qui s’intensifie lorsque vous commencez à avoir une équipe géo-distribuée et multi-zonée.
Vous avez besoin de la rigueur pour organiser méthodiquement toutes ces décisions, commencer à les organiser et trouver un système où vous pouvez revoir les arguments de l’époque, car le domaine du logiciel évolue toujours très rapidement. Les vérités d’hier peuvent être changées du jour au lendemain.
Un autre défi vient du fait que personne n’aime créer de la documentation: les gens préfèrent créer et exécuter, plutôt que de journaliser ce qu’ils ont déjà fait. C’était certainement l’un des aspects critiques du système de conception que je devais défendre à maintes reprises. Document pour les autres, document pour votre futur, document, document, document.
Il n’y a rien de particulièrement technique, il vous suffit de lui consacrer du temps et des ressources. Vous avez également besoin d’un endroit où tout le monde peut au moins consulter votre documentation, idéalement avec un accès commentant pour proposer des modifications.
Comment communiquer les décisions au bon moment
C’est un concept commun à tous les systèmes de conception: un système de conception concerne les personnes et les outils. Ce dernier aspect est définitivement là où les outils brillent.
Voici le nouveau défi: bien que le contenu ait été créé, vous pouvez conduire un cheval à l’eau mais vous ne pouvez pas le faire boire.
Et c’est là que nous pouvons revenir à la proposition de valeur fondamentale Radiant: facile faire la bonne chose.
Vous ne pouvez pas vous attendre à ce que quiconque dans l’équipe produit lise le manuel de l’utilisateur de bout en bout avant de faire quoi que ce soit.
Dans un monde idéal, vous voudriez fournir à chaque membre de l’équipe une sorte d’assistant pour les aider à prendre la bonne décision à chaque étape du chemin, exactement où ils se trouvent (c’est-à-dire l’outil de conception ou l’éditeur de code préféré de votre entreprise) et quand ils ont besoin plutôt que de leur demander de perturber leur flux pour aller vérifier la documentation.
Mais cela ne suffit pas; ils ont probablement aussi besoin de moyens d’apprentissage plus nombreux et différents qui peuvent être accomplis via une stratégie de communication à multiples facettes: documentation disponible 24/7 et dans le contexte, présentations, formation, ateliers, communication ad hoc lorsque les choses sont lancées ou quand vous le souhaitez les avertir d’un changement de rupture…
Les arguments en faveur d’un outil de gestion des jetons de conception
Il est crucial de n’avoir qu’une seule source de vérité et autant d’automatisation que possible, sinon vous allez dépenser beaucoup de ressources et de temps pour tout mettre à jour. C’est pourquoi j’ai préconisé très tôt de créer un outil de gestion des jetons de conception.
Les jetons de conception sont l’élément le plus fondamental de votre système de conception. Ce sont des paires attribut-valeur que vous trouverez partout dans vos produits – pensez à une couleur, une taille, une durée, etc.
Si un simple composant de votre système de conception est un atome, les jetons de conception sont des particules subatomiques.
Et parce qu’ils sont essentiels et très simples, c’est aussi le minimum de base que vous pouvez partager entre différentes piles technologiques. Avant de pouvoir mettre votre bibliothèque de composants à la disposition de chaque framework, vous devez être en mesure d’exporter vos jetons de conception dans tous les contextes: CSS, JavaScript, TypeScript, iOS, Android, etc. pour prendre en charge plus de produits.
Plusieurs outils open source existent déjà (ou sont en état bêta) pour les gérer. Pour Radiant, nous avons décidé d’utiliser Dictionnaire de style, qui offrait les bons outils pour notre situation.
Je surveille ce sujet de très près, car il devient une véritable norme Web que, espérons-le, les outils de conception adopteront. J’ai même rejoint le Discussion de groupe W3C à propos de ça.
Tout d’abord, je vous encouragerai à parcourir le portail de documentation accessible à l’adresse radiant.oughttspot.com
Mais comme une image vaut mille mots, vérifiez ceci avant (quand j’ai rejoint l’entreprise) / après (quand je suis parti) d’une vue de liste: