Design Systems : Travailler avec les développeurs

Dans l’article précédent, nous avons vu pourquoi il était important de ne pas négliger les développeurs mais au contraire les associer à la création de votre design system. Maintenant, il est temps de voir comment !

Si vous souhaitez creuser le sujet, vous pouvez aussi lire l’article de Leslie Pochat :
Le Design System en 10 étapes !

Step #1 : La Co-conception

La co-conception est une démarche permettant d’associer l’utilisateur final à la réflexion et au développement d’un service ou d’un produit.
Cette démarche peut largement être employée avec les développeurs puisqu’ils constituent les utilisateurs de votre design system.

Vous pourriez d’ailleurs être surpris par leurs idées.

Step #2 : La Documentation

Un design system construit sans une bonne documentation ne survivra pas. C’est aussi simple que cela. Si vous n’avez pas de documentation ou si celle-ci est difficilement utilisable ou accessible, vous prenez le risque que l’équipe de développement aille au plus simple… et se passe de votre travail.

Pour assurer son succès, une bonne documentation doit selon moi réunir les impératifs suivants :

1. Être facile d’accès

C’est simple comme tout mais donnez un nom à votre design system et créez-lui une adresse web (facilement mémorable). Cela permettra d’avoir un point de ralliement et de rendre le projet plus palpable. Au passage, évitez si vous pouvez les softwares que le développeur devra installer, cela génèrerait un point de friction inutile surtout si son besoin se résume à de la consultation.
Enfin, structurez le plus finement possible votre site en fonction des besoins. Le plus souvent, les documentations prennent la forme suivante : * Guidelines générales (couleurs, polices, metrics, …) * Composants * Ressources (illustrations, charte graphique, logo, …)

Mais vous pourriez très bien aussi structurer votre documentation par usage, métier, etc. À vous de voir en fonction des problématiques de l’entreprise et de son organisation interne.

2. Être facile d’usage

Donnez un accès direct au code exploitable, au visuel et aux règles et interdits d’utilisation de chaque composant. Si vous n’êtes pas en charge de l’intégration, travaillez étroitement avec les intégrateurs pour que les mises-à-jour soient les plus fluides et rapides possibles.

3. Gérer les cas particuliers

Gérez tous les cas particuliers, notamment pour vos composants les plus petits (et donc souvent les plus utilisés) tels que les boutons, les liens, les pop-up les titres ou les menus… Indiquez clairement le comportement que vous attendez et les règles à respecter. Gérez-les dès le 1er déploiement et non plus tard. Ce sont ces cas qui poussent le développeur à s’affranchir de votre design.

4. Présenter des exemples et mises en situation

Si vous souhaitez laisser plus de liberté au développeur et lui permettre de composer lui-même les écrans à partir de votre design system, n’oubliez pas de fournir de nombreux exemples pratiques et mises en situation. Tels que : Formulaires, Barres d’action, panneaux qui se déploient, pop-up, transitions entre pages, chargement de données, etc.

5. Encourager les retours rapides

Votre documentation aura beau être la plus parfaite possible, n’oubliez pas de fournir un moyen aux développeurs d’échanger rapidement avec vous pour gommer les petites incompréhensions .

6. Informer rapidement et clairement des changements effectués et de leurs possibles impacts

L’un des avantages du design system est de pouvoir modifier rapidement et globalement un élément. C’est aussi un risque car la moindre petite évolution peut avoir un impact immense (tel quel qu’un changement de taille de police). Avertissez vos utilisateurs de tout changement qu’il soit général ou limité à un seul composant. Et n’oubliez pas de lister les impacts potentiels.

Step #3 : Se tenir au courant

Daily, fin de sprints ou même machine à café, les occasions ne manquent pas pour vous tenir au courant des problèmes rencontrés par les développeurs. Ne négligez pas ces instants car c’est là que vous obtiendrez les meilleurs retours et l’info sur les problèmes rencontrés.

Step #4 : La validation

Pour mesurer si votre design est compris par les utilisateurs, qu’il plaît, en bref qu’il fonctionne, il existe toute une palette de services pour mesurer, quantifier, tracker, alerter. Et pour évaluer si votre design est correctement déployé par les développeurs ? C’est plus compliqué.
Mais il existe tout de même des outils pour vous aider dans votre tâche.

Quelques-uns parmi d’autres : Pastel Toybox CSSPeeper Flawless App

Step #5 : Le Design Review Meeting

Votre design system commence à tourner ? C’est le bon moment pour mettre en place des Design Review Meetings ! Le principe ? Instituer un moment rythmant les sprints permettant de valider les écrans déjà développés mais aussi d’identifier les problèmes dans ceux en cours de développement. En officialisant ces moments de partage, vous habituerez chaque équipe à échanger sur les problématiques de l’autre et aux développeurs à exercer leur oeil critique sur l’ergonomie et le respect de vos guidelines.

Pour aller plus loin sur la QA pour le design : La “Design Review” entre Designers & Développeurs

Hugo, UX-Designer @UX-Republic