Chez superhuit, nous aimons utiliser l’acronyme SDD pour Styleguide Driven Development lorsqu’il s’agit d’expliquer comment créer nos codes Front End.

Pour chaque site que nous développons, nous construisons et délivrons une styleguide complète du projet.

Une styleguide (parfois appelée styleguide dynamique) est un site qui référence l’ensemble des composants UI (User Interface) ainsi que quelques lignes directrices pour la version web de l’identité de marque.

Pour certains de nos lecteurs, cette introduction peut sembler au premier abord un peu trop technique, mais ne vous inquiétez pas, je vais vous l’expliquer d’une manière simple avec un autre exemple.

Imaginez que vous demandez à une entreprise de construction de vous faire une maison. Premièrement, vous allez parler du projet ensemble, définir les prérequis, prendre des décisions sur le design et les parties technique de la maison de vos rêves.

Imaginez dans un monde idéal qu’après seulement trois mois de travaux, votre maison est enfin prête! L’entreprise vous donne vos clefs, ainsi que la documentation nécessaire comprenant la liste des matériaux utilisés pour la construction de votre chère maison, ex: briques, plomberie, fenêtres, peintures, etc.

Vous trouverez dans ce document une explication complète sur le “fonctionnement” de chaque composant, tant au point de vue design qu’au point de vue technique.

Imaginez maintenant que vous voulez ajouter une chambre dans votre maison. Dans ce document, vous allez trouver les règles de base à suivre pour construire des murs (avec des briques), mettre une porte et une fenêtre grâce à une liste de matériaux à utiliser et comment peindre votre nouvelle chambre afin qu’elle soit jolie et reste en harmonie avec le reste de votre maison.

C’est ça une styleguide, mais pour votre site internet.

Cette approche offre de multiples avantages pour tous; ceux qui ont créé le projet et ceux qui l’ont acheté:

  • La séparation entre Front End et Back End est très distincte. Ils ne dépendent pas l’un de l’autre, jusqu’au moment où il faut les intégrer permettant ainsi à chacun d’être concentré sur sa tâche.
  • La collaboration entre les designers et les développeurs Front End est plus facile. On peut facilement lister les composants et comprendre si il y a des problèmes UX qui en découlent.
  • Le « Styleguide Driven Development » s’intègre bien dans une méthodologie agile telle que la nôtre, puisqu’il est ainsi facile de diviser le projet par « composant » à réaliser.
  • Nous fournissons à nos clients une liste complète des composants html et javascript, leur permettant ainsi d’être autonomes afin de faire évoluer leur site.

Rappel historique

Si nous voulons comprendre le concept de la Styleguide, il est nécessaire de connaître l’ Atomic Design.

L’Atomic Design est une méthode créée par Brad Frost.
Atomic Design est divisé en cinq sections distinctes, qui travaillent ensemble afin de créer un système de design d’interface d’une manière plus hiérarchique et délibérée.
Les cinq sections d’Atomic Design sont:

  1. Atomes
  2. Molécules
  3. Organismes
  4. Templates
  5. Pages

Le web est de plus en plus un système dynamique de composants (webapps, sites web interactifs,…) par opposition à un ensemble de pages statiques.

Atomic Design rend la tâche plus facile aux designers et aux développeurs. Imaginez que vous devez créer un site de 3000 pages. Cela vous semble-t-il réaliste de designer et coder 3000 templates différents? Supposons que nous passons de 3000 à 50 pages… Cela représente tout de même beaucoup de travail !

Maintenant imaginez que vous avez une liste complète de tous les composants dont vous avez besoin pour votre site, chaque élément ayant des variations de couleur et de taille.

Imaginez que vous pouvez prendre chacun de ces éléments et assembler les pages comme bon vous semble. En faisant cela, vous n’obtenez non pas 3000 mais une multitude de templates différents pour votre site!

Intéressant, non ?

Introduction à l’outil Fractal

Fractal vous aide à assembler, prévisualiser et documenter les composants des listes web, pour ensuite les intégrer dans vos sites web ou applications et construire des procédés pour créer différents projets.

Ayant par le passé utilisé d’autres outils nous développons depuis plus d’une année avec Fractal, qui est :

  • flexible
  • indépendant du stack de développement et s’y intègre facilement
  • orienté “data”, permettant de visualiser les composants avec des données réelles
  • il aide à assembler, prévisualiser et documenter les différents composants

Finalement, il n’y a pas de restrictions quand il s’agit de technologies frontend. Vous pouvez utiliser le pré/post-processeur CSS et la méthodologie de nommage CSS de votre choix (le nôtre est BEM), un super template engine, les bibliothèques javascript de vos rêves…

Amélioration de la collaboration entre designers et développeurs

Travailler avec une styleguide et Atomic Design a des avantages pour toutes les personnes impliquées dans un projet: les designers, les développeurs, les project managers, les partenaires et bien sur les clients.

Les designers ont une meilleure vision macro et micro sur le projet. Ils savent où et combien de fois a été utilisé chaque composant. Ils peuvent se concentrer sur les détails, bugs et les interactions. À noter que l’approche Atomic Design fonctionne parfaitement avec des outils de design tels que Sketch.

Les développeurs ont à la fois une vue d’ensemble et la possibilité de se concentrer sur un composant spécifique.

Le projet étant découpé par éléments visuels, il est facile pour les project managers (/product owners) d’avoir une vue précise de l’avancement et de valider chaque composant individuellement.

La compréhension de chaque étape de projet est aisée puisque la définition est la même pour designers, développeurs et project managers.

Et pour finir, le client reçoit un projet web complet, qui peut être facilement maintenu et peut évoluer dans le temps. Aucune magie noire dans le code source, plus d’attente interminable avant la publication: tous les composants et fonctionnalités sont décrits et peuvent aisément être améliorés ou réparés en cas de bug.

Nous utilisons cette méthode pour tous nos projets de développement web, parce que nous sommes sûrs que c’est une stratégie gagnant-gagnant, pour nous ainsi que pour toutes autres personnes impliquées dans le projet!

Pour aller plus loin

Si vous souhaitez en apprendre plus sur le SDD et/ou mettre en place ce genre de pratiques dans votre équipe nous vous recommandons la lecture de ces quelques articles: