Loading

Fin 2015, j’ai démarré une fabuleuse et éprouvante aventure au sein d’une start-up… L’objectif était de bâtir une grande plateforme web de services avec de multiples clients. Une plateforme “scalable”, ce qui signifiait l’implémentation de nouvelles fonctionnalités presque toutes les deux à trois semaines !

Au fur et à mesure que nous grandissions, de nombreuses difficultés en terme de design et de développement m’ont poussé à bâtir un Design System. À l’époque, j’avais à peine commencé à lire Brad Frost et découvert le Design System Lightning de Sales force. Brad Frost n’avait fait que son premier chapitre, une révélation mais aucun retour sur la mise en place d’un tel produit.

Voici donc un an plus tard mon retour sur la mise en place de ce Design System.

PS : pour préciser (beaucoup de personnes ayant travaillé dans les startups ont vécu la même chose) j’avais de nombreuses casquettes. Product Designer, UX et UI en passant par le référencement, le tracking et la mise en place de campagnes marketing et même du front-end (landing pages) et du codage d’e-mails et le management de développeurs. D’où ma vision globale sur ce retour d’expérience et la liberté de décision que je pouvais avoir concernant le Design System.

Retour d'expérience sur la conception d'un Design System Cliquez pour tweeter

1 – Le Contexte

Concernant le projet

  • Nous avions deux types de publics cibles : les patients et les établissements de santé, et donc deux grandes familles de fonctionnalités, par cible visée. Bien qu’interconnectées, les interfaces et fonctionnalités étaient bien différentes selon le profil qui l’utilisait.
  • La plateforme ne cessait d’évoluer, avec des fonctionnalités parfois complexes. De questionnaires entièrement personnalisables à l’analyse sémantique en passant par une messagerie anonyme privée, chaque sprint amenait à implémenter de nouvelles features qui avaient de nombreux impacts des deux côtés de l’interface.
  • Pour finir, le projet était entièrement en adaptative, avec des composants ayant des comportements spécifiques selon les breakpoints.

Concernant l’équipe

  • Nous avions beaucoup de fonctionnalités différentes à designer en peu de temps.
  • Le rythme était très intense, dont aucun temps pour réellement surveiller la cohérence visuelle et expérientielle.
  • Des contraintes en terme de coordination des équipes ainsi que des points de blocages côté communication entre les développeurs (tous étant freelances et localisés aux quatre coins de la France).
  • Des décisions en terme d’UI qui ne se sont prises que dans le scope de la fonctionnalité en cours de design et non dans l’ensemble de la plateforme.
  • Beaucoup trop de temps a été perdu à faire des UI et UX différentes.

2 – Les conséquences

Elles devinrent vite très couteuses, comprenant une dette de Design qui devenait de plus en plus énorme. Différents fichiers CSS pour la même UI et trop de composants différents qui répondaient à un même objectif ce qui engendra :

  • Une énorme perte de temps (que nous n’avions pas) : notamment lorsque l’on intégrait les différents développements, je vous laisse imaginer le nombre de casses et la difficulté à comprendre les éléments déclencheurs.
  • Des performances pour le site décroissantes : le site devenait de plus en plus long à charger, avec des bugs aussi dans l’affichage, etc.
  • Des conversions manquées : avec des campagnes en cours qui voyaient leur optimisation chuter.

Pour un même composant, deux classes différentes : ça surcharge.

 


Pour une même classe, deux composants différents : ça casse.

3 – Les bénéfices

La mise en place d’un Design System m’a permis de réaliser ces objectifs :

  • Maintenir une expérience cohérente à travers nos différents services et fonctionnalités. Ce qui est quand même une des bases des plateformes ubiquitaires.
  • Diriger la charge de travail sur la conception de fonctionnalités à valeur ajoutée et non plus sur le look & feel et les composants.
  • Augmenter la performance de notre plateforme en minimisant les ressources front.
  • Rendre la plateforme facilement scalable.
  • Gagner du temps et de l’argent : notre Design System comprenant les composants avec le code correspondant, il était facile de faire entrer de nouveaux développeurs sur certains projets et composer des pages en front devenait plus rapide.

4 – Le bilan

Je vais vous en faire un retour synthétique sous forme de KISS (What to keep, What to Improve, What to Stop, What to Start).

What to Keep

  • Avoir fait l’inventaire des différents composants
    Cela nous a permis de voir l’étendue des dégâts, de trouver des composants similaires à fusionner et de prioriser nos choix en terme de conception autour du Design System. Brad Frost propose désormais un template pour cela.
  • Avoir une approche “Atomique”
    Très inspiré par les écrits de Brad Frost, cela a permis de réaliser étape par étape et de manière structurée cette approche. Même si je pense que c’est impossible de la suivre à la lettre. Cela nous a pas mal permis de réfléchir à des composants en terme de possibilités maximales pour ensuite retirer des blocs suivant les besoins.
  • Une approche Mobile First et Inclusive
    Ce qui est indispensable dans le résultat final pour vos end-users.
  • Avoir les développeurs en tête
    Car cela a permis de rationaliser certains choix en fonction de la faisabilité et des temps de développements nécessaires. Leur connaissance des composants est aussi fort utile, en veillant à ne pas tomber dans le moindre effort.
  • Créer une organisation autour du Design System
    Pour chaque nouveau composant, avant de l’intégrer on vérifiait qu’il soit présent dans le Design System. S’il ne l’était pas, dans ce cas on pesait le pour et le contre, si un composant pouvait servir d’alternative. Ce qui aboutissait soit à son intégration, soit à son rejet.

What to Improve

  • Partir de Zéro
    On s’est basé sur un framework existant, cela aurait été mieux de faire le notre from scratch, mais bon le cadre de la startup l’oblige 🙂
  • Avoir une vue plus générale
    Intégrer des notions comme le ton of voice, les règles de rédaction ou encore les grands principes qui ont guidé la conception. Cela aurait aidé les nouveaux développeurs à comprendre et à s’immerger plus rapidement.
  • Définir des règles de classification et de naming
    Autant pour le développement que pour les symboles dans Sketch.
  • Updater l’ensemble des fichiers
    Forcément, le site destiné aux développeurs était prioritaire en terme d’évolution. Le problème est que j’ai réellement eu du mal par la suite à mettre à jour la librairie qui me servait pour les designs. Cela m’a valu pas mal de temps à essayer de voir si mes designs répondaient toujours aux décisions prises concernant le design system.

What to Stop

  • Penser à court terme
    Et ne pas avoir une vision plus grande concernant le Design System.
  • Ne pas avoir de process d’update de fichiers
  • Tout baser sur un framework existant
    Qui s’est révélé parfois difficile à maintenir.

What to Start

  • Si c’est un projet plus grand, avoir une équipe dédiée au produit Design System
    Concernant tous les updates et les prises de décisions, et l’anticipation des évolutions.
  • Intégrer l’identité et les valeurs de l’entreprise
    Concernant les choix et partis pris en terme de design mais également en terme de valeurs que souhaite véhiculer l’entreprise.
  • Avoir un outil d’évaluation
    Permettant d’évaluer la compliance des différentes fonctionnalités développées avec ce Design System.
  • Intégrer tous les états des composants
    Hover, active, disabled, et toutes les variations dans chaque fichier.
  • Créer de meilleurs composants
    Pour qu’ils puissent s’adapter non pas qu’aux usages mais également à la customisation visuelle.
  • Le Design doit driver le développement et non l’inverse, notamment avec la technologie changeante (Hello Ruby) car l’expérience doit prévaloir (toute mesure gardée).
http://mxmfrr.cc
Contributor
Do you like Maxime Frere's articles? Follow on social!
People reacted to this story.
Comments to: Retour d’expérience sur la conception d’un Design System
  • 24 novembre 2017

    Bonjour,

    Très intéressant, je travaille également sur un projet dans le monde de la santé et en effet, chaque semaine de nouveau système doivent être pensées et repensées, sans cesse.
    Je rencontre la plus part des problématiques présentées dans l’article.
    La solution d’un Design Système devient de plus en plus évident !
    Merci pour ce témoignage sur cette expérience !

    Victor.

    • 25 novembre 2017

      Merci pour ton commentaire. N’hésite pas à m’en parler sur Twitter si jamais tu as des questions !

    • 1 février 2018

      Bonjour Maxime, merci beaucoup pour cet article précis !
      Je démarre actuellement la mise en place d’un design system pour une app très utilisée.
      Peux-tu me dire (à part si pb pub) quelle est le framework que vous avez utilisé pour faire du design system un outil consultable par tous et qui peut à la fois se synchroniser avec la bibliothèque de composants (atomes…) ?

      Merci !

      Emmanuel

      • 8 février 2018

        Bonjour à tous, je suis aussi intéressé à connaitre quel était le framework utilisé ?
        merci d’avance.

Write a response
Inscription obligatoire et gratuite

Suivez toutes nos actualités

Ne manquez pas un article ! Toutes les nouveautés directement dans vos emails.

ARTICLES LES PLUS APPRÉCIÉS

Articles des membres

Devenir un community manager n’est pas une tâche facile. Cela demande beaucoup de travail, de dévouement et, surtout, de bonnes compétences. Un community manager doit posséder des compétences exceptionnelles en matière de communication, être capable de gérer des situations difficiles et de réfléchir rapidement. Ils doivent également avoir une connaissance approfondie des produits ou services […]

LES NOUVEAUX ARTICLES

  1. Actualités
Cela n’est plus nouveau, la cybersécurité est un enjeu crucial pour toutes les entreprises et organisations qui utilisent des systèmes informatiques. Mais, en même temps, l’expérience utilisateur (UX) est également devenue un facteur clé pour la bonne utilisation des systèmes. Malheureusement, ces deux objectifs ne vont pas toujours de pair. En effet, sécuriser quelque chose […]
  1. Articles des membres
Devenir un community manager n’est pas une tâche facile. Cela demande beaucoup de travail, de dévouement et, surtout, de bonnes compétences. Un community manager doit posséder des compétences exceptionnelles en matière de communication, être capable de gérer des situations difficiles et de réfléchir rapidement. Ils doivent également avoir une connaissance approfondie des produits ou services […]