Comment nous avons construit un écosystème centralisé de bibliothèques multimarques pour l'un des plus grands holdings edtech au Brésil.

Tout d'abord, je dois dire que ce n'est pas un article qui vise à expliquer "Qu'est-ce qu'un Design System?" ou « Quelle est son importance pour votre entreprise » (Pour avoir un aperçu sur le sujet, je vous conseille de lire cet article de Meiuca ). Notre objectif est de partager un peu de la façon dont nous avons construit un système de conception multimarque pour l'un des plus grands holdings edtech au Brésil, en nous concentrant principalement sur les défis du front du design et sur les résultats que nous avons obtenus avec ce projet.

Bien sûr, à cause de cela, nous parlerons de choses qui peuvent vous inspirer pour prendre une décision avec votre équipe ou, qui sait, même convaincre certaines parties prenantes d'investir dans leur propre Design System (j'espère que cet article pourra vous aider avec ça ).

Puisque nous sommes alignés, allons-y !

Contexte et problèmes

De nos jours, Wiser education est une holding de produits numériques destinés au marché de l'éducation, plus spécifiquement à l'éducation des adultes, cependant, cela n'a pas toujours été notre réalité.

Wiseup Online , meuSucesso.com , Conquer et Power House ensemble, ils totalisent plus de 300 000 utilisateurs.

Wiser a commencé comme franchiseur d'écoles d'anglais pour les personnes de plus de 18 ans. Je crois qu'ils ont conquis la scène nationale parce qu'ils se sont toujours positionnés pour embrasser les nouvelles tendances du marché (l'anglais pour adultes, par exemple, n'était pas courant à cette époque).

En 2020, cependant, nous avons tous vu le marché mondial de l'éducation bouleversé par une pandémie. Notre modèle d'entreprise, qui était auparavant basé sur l'enseignement en face à face, devait maintenant changer complètement vers un format d'enseignement en ligne.

Comme d'habitude, Wiser a adopté cette nouvelle réalité du marché et est officiellement devenue une entreprise de produits éducatifs numériques.

Cependant, comme toute croissance accélérée a son prix, nous avons reçu la facture de mois de travail sans organisation claire et évolutive. Et ce compte était cher.

« Nous grandissons vite, mais avec trop d'OPEX »
OPEX : Dépenses Opérationnelles. dépenses de fonctionnement : capital humain — https://www.suno.com.br/artigos/capex/ ou Medium

Début 2022, nous avions ce scénario : trop de fichiers et trop d'incohérences (composants, systèmes de couleurs et bibliothèques). Par conséquent, nous avons eu une énorme perte de temps à refaire des écrans et des composants qui pourraient être réutilisés.

Nous sommes arrivés à la conclusion que nous avions besoin d'un Design System, mais la question sans réponse était : comment pouvons-nous faire cela, étant donné que nous devons adapter nos bibliothèques à différentes marques et produits, en plus de ne pas avoir une équipe entièrement dédiée à cela ?

Agile était la réponse

Nous avions en tête que plusieurs frameworks étaient possibles pour guider ce projet : 5W2H, double diamant, mais rappelons que notre scénario était entouré de plusieurs livraisons qui devaient supporter le développement d'un Design System en parallèle ! (Ce n'était pas une tâche simple).

"Nous devons fournir quelque chose à notre utilisateur final et en tirer des leçons le plus rapidement possible."

Par conséquent, plutôt que de mettre en place un processus clair et linéaire, nous avons décidé de prendre à cœur les principes de base de la pensée agile et de partir de là.

• Les individus et les interactions sur les processus et les outils.
• Logiciel qui s'exécute sur une documentation complète.
• Collaboration avec le client sur la négociation du contrat.
• Réagissez au changement plutôt que de suivre un plan.

Découvrir

Nous sommes partis de l'hypothèse que nous ne savions pas tout sur les systèmes de conception et que nous avions encore beaucoup à apprendre sur la façon de gérer un scénario multimarque. Nous avons donc invité quelques représentants des équipes technologie, business et design à se réunir hebdomadairement en guilde, et ainsi présenter le fruit de leurs découvertes (tous guidés par des objectifs et des buts).

Des bibliothèques de grandes entreprises aux tests de langage et au système de couleurs, nous avons beaucoup appris, mais surtout qu'il existe de nombreuses façons de construire un système de conception, lol. Par conséquent, notre objectif sera de présenter les choix que nous avons faits pour adapter cet écosystème de bibliothèques au scénario Wiser.

1. Jetons mondiaux et de marque

Nous savons que l'un des grands avantages d'un projet comme celui-ci est la systématisation des définitions entre concepteurs et développeurs. C'est pourquoi nous pensons qu'il est important pour notre contexte de créer 2 classifications de jetons : Global et Brand.

Aussi simple que cela puisse paraître, cette définition nous a permis de comprendre quels éléments d'interface doivent être communs à tous les produits (Font weight, Border radius, Shadow, etc) et lesquels doivent être contextuels (Font family, colors). Pour en savoir plus sur cette division, regardez ce live sur DS par XP Investimentos.

2. Composants de base de l'e-équipe

Nous n'avons pas eu beaucoup de temps pour créer tous les composants que nous aimerions pour la v.1 (en plus du fait que ce ne serait pas très aligné avec la vision agile de l'implémentation continue), nous avons donc défini ce qui était le plus composants communs parmi les interfaces que nous analysons et les appelons composants de base (composants qui devraient être les mêmes entre les produits que nous créons, avec seulement quelques différences de couleur, de typographie, de rayon de bordure, entre eux).

Les composants d'équipe, à leur tour, seraient des composants créés par la propre équipe du produit, qui consommeraient des informations du système de conception, mais n'existeraient pas nécessairement pour tous les produits (par exemple : composants de classe en direct).

3. Documentation et gouvernance.

Nous avons divisé nos fichiers en fonction de leur gouvernance, afin d'éviter les erreurs et de garantir l'échelle. Ce classement a été effectué comme suit :

• Jetons globaux
  (Seules quelques personnes pouvaient modifier ce fichier, car il couvrait les jetons qui seraient utilisés par toutes les marques).
• Composants de base (Seules quelques personnes pouvaient modifier ce fichier, car il couvrait tous les composants de base partagés entre d'autres produits.).
  
• Feuille de style (tous les concepteurs d'escouade peuvent modifier ce fichier. Regroupement de jetons de marque et de composants d'équipe - créés par l'escouade elle-même, à l'aide d'éléments DS).
  

Après cette définition, nous avons analysé les interfaces des produits présents dans notre entreprise et identifié quels étaient les composants les plus répétés dans notre contexte. Nous avons ensuite défini quels seraient les composants Core générés pour DS v.1.

1. Typographie
2. Couleur
3. Bouton
4. Champ de texte
5. Sélectionner
6. Case à cocher
7. Bouton radio
8. Carte de base

Juste après nos découvertes et notre cadrage, nous avons commencé à générer les composants liés à notre première version du Design system. Pour ce faire, nous avons suivi un processus comprenant les étapes suivantes :

Comme nous n'avions pas d'équipe dédiée, mais une guilde composée de personnes intéressées par le sujet, nous avons compris la nécessité de déléguer les livraisons de projets à une équipe spécifique, qui pourrait lier leurs demandes hebdomadaires aux livraisons DS.

Par conséquent, nous avons défini que l'équipe de caisse des produits Wiser devrait être responsable des livraisons des premiers composants du Design System, considérant qu'ils coordonnent un produit en marque blanche.

Nous avons généré un engagement notable entre les équipes technologiques, puisque toutes les livraisons de composants Core générées par la caisse pouvaient être appliquées par d'autres équipes. Ce processus, qui a progressivement mis à disposition de nouveaux composants, a suscité la curiosité des équipes, amenant les leaders technologiques eux-mêmes à utiliser le Design system LIB, assurant désormais que les nouvelles livraisons front-end utiliseraient, en quelque sorte, le référentiel Design System.

Résultat et découverte continue

Nous avons inclus le thème dans notre environnement, de sorte que nous avons commencé à remarquer comment chaque équipe, qui a adopté le Design System, avait un gain considérable dans son délai de livraison. Nous laissons ici quelques-uns des résultats que nous avons obtenus jusqu'à présent.

Apprentissage et prochaines étapes

Nous avons beaucoup appris de tout ce processus, voici quelques points qui, à mon avis, méritent d'être partagés :

1. Lorsque vous montrez de la valeur (résultat), il devient plus facile de demander plus de temps et d'argent.
   Nous avons essayé de faire décoller ce projet à plusieurs reprises, et nos parties prenantes connaissaient son importance. Mais c'est lorsque nous avons généré les premières livraisons que le projet a vraiment commencé à gagner en priorité.
2. Les couleurs peuvent devenir un grand défi pour le contexte multimarque.
   Nous savons que les palettes de couleurs doivent être polyvalentes et simples, mais définir une norme qui s'applique automatiquement à plusieurs produits, supprimant le besoin d'ajustements manuels par les concepteurs et les développeurs, était un défi.
3. Le travail d'équipe est incroyable !
   Nous n'avions pas encore beaucoup de fans pour travailler sur le projet, donc chaque partenaire désireux de collaborer avec l'idée a fait la différence !
4. Livraisons continues !
   Je l'ai peut-être déjà dit, mais la livraison continue a été la clé du développement de ce système de conception. Attention à ne pas rester coincé dans des cycles d'apprentissage interminables. Générez de la valeur chaque jour, semaine, mois, trimestre.

Merci d'avoir lu!

Les références

Marinheiro, Felipe — Greenstone Design System Hassu Thiago — Design System na visão da Meiuca Invision — Putting DesignOps into play IBM — Carboom Design System Google — Material Design

Crédit

Maria Fernanda — Product designer Ops
Renata Caraih — Product designer Ops
Marcus Vinícius — Tech lead
Adson Amorim — Front-end
Diogo Thomaz — Product Owner
Luan Lima — Product Head