

Opteamis
Industrialiser la conception d’une plateforme en marque blanche avec un design system
équipe
DATE
Début de conception — Q2 2023
Fin de conception — janvier 2024
Méthodes
Tri de cartes, Expert analysis, Design system
INTRODUCTION
Opteamis est une plateforme VMS (Vendor Management System) qui met en relation les entreprises et les prestataires de services informatiques. Les clients publient des appels d'offres, contractualisent et gèrent leurs prestations depuis la plateforme, tandis que les ESN et les consultants freelance recherchent leur prochaine mission.
Contexte
Pendant 12 ans, Opteamis a développé des fonctionnalités afin de créer un outil capable de répondre à tous les besoins exprimés par ses clients. Au final, la plateforme est devenu un léviathan de fonctionnalités parfois incompréhensibles, souvent frustrantes mais toujours compliquées à utiliser. De plus, les composants de l'interface n'étaient pas homogènes : ils étaient tous différents d'une page à l'autre, créant une cacophonie visuelle à laquelle s'ajoutaient des problèmes d'architecture de l'information.
problématique
Objectifs
Garantir une meilleure cohérence et qualité visuelle en standardisant les composants pour toutes les marques.
Augmenter la vitesse du prototypage et du développement front-end.
Problèmes
Incohérences visuelles
Certains éléments graphiques étaient différents d'une page à l'autre alors que leur fonctionnement était identique. Ce problème touchait tous les types de composants, y compris des composants importants tels que les menu déroulants, les datepickers ou les barres de recherche.
Mauvaise ergonomie et accessibilité
Les composants ne répondaient pas aux normes de qualités requises pour une interface utilisable : les contrastes ne remplissaient pas les exigences WCAG, des icônes abstraites étaient sans libellés, etc...
Des lenteurs inutiles lors du prototypage
Lors du prototypage, je perdais un temps précieux à recréer des éléments simples comme un bouton, une barre de recherche, des éléments d'une liste, etc... De plus, à chaque fois que des changements étaient nécessaire sur un composant je devais reporter les modifications sur tous les prototypes au lieu de mettre à jour en un clic le style.
En approfondissant
Un développement supplémentaire et coûteux pour les marques blanches
Opteamis engageait souvent des développements supplémentaires pour déployer la plateforme en marque blanche chez ses clients. Qu'il s'agisse d'un léger rebranding ou du développement de fonctionnalités : le temps engagé était trop long et coûteux.
Des surcouches de CSS problématiques
Les composants de la bibliothèque utilisée (Bootstrap) étaient peu flexibles et difficiles à personnaliser. Pour pallier à cela, les développeurs ajoutaient des feuilles de style CSS lors de la création de pages. Mais les ajouts de CSS étaient locaux : si des modifications étaient nécessaires, il fallait les faire une par une sur chaque page pour uniformiser.
Cette méthode n'était pas scalable car effectuer des modifications minimes nécessitait un temps précieux et fastidieux. Cela devenait encore plus compliqué lors de changements à grande échelle notamment dans le cadre du déploiement en marque blanche chez un client.
Solution
J'ai lancé le projet de création d'un design system afin de :
-> Accroître la vitesse de prototypage et de développement.
-> Garantir une meilleure qualité et une meilleure cohérence visuelle grâce à la standardisation des composants de la plateforme commercialisée en marque blanche.
-> Améliorer la collaboration entre les équipes en créant une référence commune pour les concepteurs, les développeurs et les autres parties prenantes afin de faciliter la communication et minimiser les malentendus.
Challenges
Créer un système compatible avec 3 produits différents.
Concevoir un système qui peut être facilement personnalisable et déployé en marque blanche pour le client.
Mettre en place un process de travail collaboratif pour impliquer l'entreprise dans le projet d'amélioration du produit.
Approche
Opportunités
Opteamis utilisait les composants et le système de grille de la bibliothèque Bootstrap. Mais en 2022, une migration technique vers une nouvelle stack technique intégrant PHP et Angular a été initié. Et elle a ouvert la discussion sur un changement de framework front-end.
solution privilégiée
En tant que designer, j'ai recommandé la solution CSS Tailwind, qui avait l'avantage d'être très populaire, de bien fonctionner avec Angular et d'être facilement compatible avec la question des design tokens. En complément, j'ai évoqué l'installation d'un storybook pour servir de référentiel de composants développés.
OUTILS

Conception de composant
Figma

Librairie de composant (pour le design)
Figma


Développement de composant
Tailwind, Angular, CSS…
Librairie de composant (pour le développement)
Storybook

Documentation
Probablement Zeroheight
Outil à définir
Process
Design 1.0 - Concevoir une première version compatible avec le "legacy"
Avec cette première version, l'idée est de rendre tout les composants uniformes, cohérents et liés à travers la plateforme, de sorte à ce que, si des modifications sont apportées à un composant : il n'y aura aucune incohérence d'une page à une autre.
étape 1
Lister les composants existants
Il était d'abord question de lister les composants à refaire. L'objectif était d'obtenir une vision exhaustive de l'existant et d'anticiper les conséquences sur l'interface si l'un de ces composants était modifié de manière drastique.
étape 2
Penser aux composants nécessaires
Ensuite, j'ai dressé une liste des composants potentiels qui sont essentiels mais manquants. Ces éléments futurs seraient anticipés dans la conception.
étape 3
Organiser la structure du design system (tri des cartes)
Nous avons organisé des événements avec les développeurs pour trier les anciens et les nouveaux composants de manière logique. Étant donné que les développeurs et les concepteurs allaient travailler avec cet outil commun, il fallait qu'ils aient le même langage et que cela ait un sens pour les deux parties concernées.
étape 4
Concevoir les composants
J'ai défini les différentes variables des composants sur le papier puis les ai fait validé avec les développeurs. Ensuite, je les ai réalisé sur figma. Ces première briques ont été le début de notre librairie de composant.
étape 5
Tester les composants
Même si après avoir anticipé les possibles impacts, nous devions tester les composants pour s'assurer de l'intégrité des pages. Les résultats ont été ceux attendus. Les pages n'étaient pas devenues meilleures, mais au moins les composants étaient unifié et nous avions réglé une première problématique : celle de l'incohérence des composants au travers de l'application.
Design 2.0 - Concevoir pour la refonte
Cette deuxième version s'est inscrit dans le cadre d'une refonte majeure. L'objectif était de mettre à jour l'interface de la plateforme avec le nouveau branding d'Opteamis et d'améliorer les composants pour la nouvelle refonte plateforme. C'est dans cette version que nous avons commencé à intégrer le principe des design tokens pour améliorer le contrôle, la mise à jour des composants et pour gérer notre plateforme en marque blanche.
étape 1
Améliorer et mettre à jour les composants
Améliorer la convivialité, la lisibilité et les problèmes d'accessibilité afin de rendre l'interface utilisateur plus agréable et plus fidèle à la nouvelle image de marque.
étape 2
Définition de la palette et des design tokens
J'ai rassemblé les couleurs de l'identité de marque d'Opteamis puis je les ai déclinées en différentes teintes à l'aide de l'application UI Colors (de Tailwind). Ensuite, toutes les teintes ont été ajustées pour améliorer le contraste et s'adapter à l'interface
Les couleurs de ma palette étaient utilisées dans des tokens nommés. Les tokens de contour, d'arrière-plan ou de couleurs de texte étaient directement appliqué aux composants. Si la palette étaient modifié : alors tous les tokens utilisant l'hexadécimale en question se retrouvait impacté. De même, si la valeur de "color/border/textfield/default" étaient modifié : alors tous les composants utilisant ce token de contour (input, textarea, select…) se mettaient automatiquement à jour.
En outre, la désignation des design tokens aidaient les développeur à savoir quel jeton utiliser au lieu d'utiliser des références vagues telles que "brand:100" ou "grey:700".
étape 3
Créer un système de gestion en marque blanche
Au fur et à mesure que les jetons de couleur pour Opteamis étaient définis, nous pouvions créer des versions de ces jetons pour d'autres marques telles que MyTopManager et LuxeForGuide. Cela a été géré avec la fonction « mode » de Figma.
Une fois les tokens définis, nous pouvions sélectionner n'importe quel prototype et voir à quoi il ressemblait pour MyTopManager, LuxeForGuide, etc... Et ainsi ajuster la palette de couleurs du client.
Cela nous permet de gérer notre roadmap produit avec les mises à jour de notre plateforme, sans endommager ou modifier les spécificités visuelles de chacun de nos clients.
étape 4
Développer les composants pour le Storybook
Les composants conçus ont été développés et stockés sur Storybook. Ce référentiel a également servi de terrain de jeu pour tester chaque cas de composant.
Chaque fois qu'un développeur avait besoin d'utiliser un composant pour une fonctionnalité, il peut copier le bon code et le coller dans son éditeur de texte.
Leçons
Le design system est un outil souvent mal compris
Lorsque j'ai commencé à travailler sur la standardisation des éléments de la version legacy (1.0), on parlait de légères améliorations visuelles. L'équipe en charge de l'identité visuelle et du marketing d'Opteamis s'est donc impliquée car, avant la création de notre pôle Produit, elle avait historiquement l'habitude de travailler sur les améliorations visuelles de la plateforme. Malheureusement, ils avaient retravaillé les pages et les éléments individuels sans penser de manière "atomique". Le travail fourni n'était ni cohérent ni utilisable.
C'est en présentant de nouveaux écrans et en expliquant à nouveau les implications du projet que j'ai pu prendre en charge le sujet. J'ai repris la responsabilité du point de vue de la conception.
La nécessité de faire comprendre le coût du "Bad design"
Un élément difficile à comprendre, manquant de contraste ou inabordable peut avoir un impact négatif sur une expérience. Mais il est difficile de rendre compte de l'ampleur de l'impact d'une telle erreur avec des chiffres. Pourtant les décisionnaires qui ne font pas partie du monde du Design avaient besoin de comprendre. Face à cette problématique, le test utilisateur a été la meilleure solution.
En effectuant des test utilisateurs, j'ai montré aux parties prenantes à quel point des éléments d'interface considérés comme "triviaux" ou "accessoires" sont en fait extrêmement importants pour que l'utilisateur comprenne l'interface et que son expérience se déroule sans accroc.
Cela m'a souvent sauvé face aux stéréotypes et préconceptions du web qui ont parfois la dent dure.
Avant-propos
Le design system est devenu un outil très commun. Mais il faut se poser des questions avant d'en créer un. Car même si il est très souvent bénéfique : il nécessite des compétences, un investissement de chaque jour et des coûts.