Whitespace
Fortuneo
Accompagner la mise en place du design system au sein des équipes
Whitespace
Design system : le défi
Fortuneo veut profiter de sa nouvelle direction artistique pour implémenter le design system au sein de ses équipes de développement.
Par où commencer ? Comment intégrer au mieux les différent éléments entre web et app native pour faire une seule composante commune à tous ?
Mon accompagnement au sein des équipes de Fortuneo commence.
Tout d'abord, un design system qu'est-ce que c'est ?
Les définitions du design system englobent souvent les mots bibliothèque (library), lignes directrices (guidelines), styleguide et langage visuel (visual language).
En fait, le design system comprend tous ces aspects. Le design system regroupe ce que nous appelions auparavant la charte ergonomique et la charte graphique. C’est une bibliothèque de référence et un guide pour faciliter le design et développement d'une application métier, un site e-commerce ou toute autre forme de produit ou service digital. Les équipes techniques et design peuvent ainsi piocher des composants prêts à être utilisés et écrits dans un langage commun. Le contenu du design system dépend de l’identité de l’entreprise et de son écosystème digital. Toutefois, les éléments suivants y figurent généralement :
- Composants UI et patterns
- Principes visuels autour de la typographie
- Palettes des couleurs et règles associées
- Iconographie et imagerie
- Grilles pour structurer les éléments, espaces, etc (Grid layout)
- Principes de communication de la marque (langage, ton…)
- Éléments réutilisables de l’interface utilisateur (UI)
Comment mettre en place ce Design System ?
Avant de concevoir il faut discuter, unifier les équipes sur une seule et même pensée, un design system c'est... Car oui au-delà de connaitre plus ou moins la théorie, il faut que chaque personne au sein de Fortuneo sache ce que ça implique et signifie demain pour eux.
Première chose à prendre en compte, avant même la nomenclature des différents composants, devons-nous opter pour une gouvernance centralisée ou fédératrice, telle est la question.
Il ne s’agit pas de décréter qu’un modèle est meilleur que l’autre. Il va - de fait - se choisir en fonction de l’organisation de la structure et du temps qui peut être alloué par chacun.
La gouvernance centralisée :
Chaque équipe pourra faire des propositions de nouveaux composants ou de nouveaux patterns, mais le choix final de leur intégration ou non au système reviendra toujours à l’équipe (centrale) en charge du design system.
Les avantages de ce modèle sont doubles :
- une allocation de ressource en entreprise (homme et temps) plus légère;
- une cohérence plus facilement maîtrisée des éléments du Design System.
La gouvernance fédérative :
Les membres de plusieurs équipes sont en charge du système et y contribuent. L’adoption est souvent plus facile mais il faut des garants qui ont la vision transverse du système afin de garder une cohérence d’ensemble et qui restent disponibles.
Ils prennent des décisions collectivement, construisent et communiquent via un support de leur choix (et ce choix est large).
Les avantages de ce modèle sont multiples :
- accroître la pertinence de nombreuses plateformes et lignes de production
- limiter les biais en représentant de nombreux points de vue différents
- faciliter la circulation du système entre les équipes en multipliant le nombre “d’évangélistes”.
Avec les équipes présentes, nous opterons pour une gouvernance fédérative pour un meilleur pilotage cross-device, en mettant en place des points d'échanges réguliers pour faire grandir et évoluer le design system au sein de l'entreprise.
Code, langage et co-création
Nous avons défini la gouvernance, la prochaine étape est :
le langage source... (oui on ne commence pas encore à concevoir mais ça arrive).
Avec l'ensemble des designers, nous organisons un point pour déterminer avec les développeurs quelle technologie utiliser pour ce fameux design system, tout réunir ou au contraire séparer la ressource en différents langage pour faciliter leur implémentation entre web et app native sans avoir à refondre l'entièreté du process mis en place.
Nous optons pour un design system partagé, via une librairie en ligne. Chaque équipe (Web, iOS et Android) devra implémenter au fur et à mesure les composants et les partager avec le reste des équipes, permettant ainsi aux développeurs (nouveaux comme anciens) de retrouver le code approprié à implémenter dans son projet.
Nous pouvons commencer à créer à l'unisson
Le mot d'ordre est simple, chacun son composant et on se réunit une fois par semaine (voire 2 au début) pour discuter et concevoir les composants basés sur la nouvelle charte graphique. Nous intégrons à chaque réunion des membres de l'équipe de développement pour discuter de la bonne nomenclature des composants (couleurs, formes, taille des typo, boutons etc...). Chaque composant a son nom propre et nous les présentons à toutes les équipes (dev, marketing, designer, PO) pour éviter les erreurs d'appellation et pouvoir avancer d'un même pas.
Aujourd'hui le design system est entre de bonnes mains au sein des équipes de Fortuneo, son évangélisation est faite. Les PO, membres de l'équipe marketing et développeurs externes parle le même language et connaissent les composants sur le bout des doigts.
