Designers, travailler en équipe comme des développeurs
Seul designer chez MeilleursAgents, de nouvelles personnes arrivent pour renforcer l’équipe. A partir de là, nous avons commencé à être confrontés à des problématiques de process :
- Comment préserver la cohérence de nos interfaces avec nos différentes sensibilités ?
- Comment collaborer avec les développeurs ?
- Comment travailler en collaboration sur nos fichiers Sketch ?
Pour mieux nous organiser, il fallait construire notre process idéal. Au final, il se trouve qu’il nous fallait le même que nos équipes techniques. 3 points nous ont amené à cette conclusion :
- Les logiques des designers et des développeurs tendent de plus en plus à converger. Par exemple : on entend beaucoup parler de développement modulaire poussé par la popularité de framework JS comme React, au même titre que l’atomic design rentre dans le vocabulaire des designers. Notre façon de concevoir des interfaces a donc un impact direct sur le code.
- Avant de produire du code ou des maquettes, nous avons besoin de passer par une phase de recherche approfondie. Les développeurs font des benchmarks et testent les meilleurs outils et la meilleure technologie pour répondre aux critères d’un projet. Du côté du design, nous faisons aussi des recherches sur nos utilisateurs et leurs besoins, et réalisons aussi des benchmarks pour voir comment d’autres solutions répondent au même besoin.
- Ces dernières années, le métier de développeur est probablement celui qui a le plus évolué. L’une des évolutions les plus marquantes est leur capacité à travailler en équipe tout en garantissant une bonne cohérence et un code de qualité. Les Pull Requests, qui consistent à faire relire son code par un pair, y sont pour beaucoup. Les sensibilités des designers étant souvent très variées et pouvant être un risque pour la cohérence de l’expérience utilisateur, pourquoi ne pas faire pareil ?
Voici ce que nous avons mis en place pour travailler efficacement en équipe :
- Logiques atomic design
- Versionning et librairies de nos fichiers Sketch
- Design reviews
Atomic design
Entre la conception des maquettes et leur intégration, beaucoup de choses peuvent changer. Communiquer son design peut être difficile et des détails peuvent se perdre à l’intégration.
Les logiques de nos designs peuvent nous paraître évidentes mais un développeur ne les percevra pas forcément de la même façon. Au contraire, il pourrait y voir des cas particuliers partout, mettant à mal la modularité de son code. Le code devient alors difficilement maintenable et la fidélité des éléments d’interface est mise à mal par la répétition de code inutile, augmentant le risque de mal implémenter certains éléments. Bref, tout le monde est frustré et la qualité de l’interface finale n’est pas toujours très aboutie.
C’est pourquoi il est important que les logiques des designers et des développeurs soient alignées. Chez MeilleursAgents, le code est modulaire et les éléments de l’interface sont découpés en composants. C’est pourquoi il nous semblait logique d’adopter le même système en optant pour l’atomic design.
Pour ceux qui ne connaissent pas encore cette notion, voici un très bon article d’Audrey Hacq sur le sujet. En substance, il s’agit d’une logique qui part des éléments les plus petits (les atomes) pour constituer des éléments plus grands (les molécules) qui eux même constituent d’autres ensembles plus grands jusqu’à arriver à constituer des pages. En communiquant les maquettes de cette façon les logiques apparaissent de manière plus évidentes aux intégrateurs. Et au final, cette méthode va dans le même sens que les logiques des développeurs.
Bien sûr, ces guidelines atomic ne se substituent pas à une bonne communication entre designers et développeurs front. Il est très facile de reprendre de mauvaises habitudes, même avec une bonne documentation.
Versionning et librairies
Quand j’était le seul designer de l’entreprise, le découpage des fichiers Sketch n’était pas une problématique importante. Tout le site MeilleursAgents tenait sur un seul fichier. Les symboles étaient donc très facilement accessible ainsi que les styles de couleurs et de typographies.
Mais même en étant le seul designer de son entreprise, on peut un jour avoir à travailler avec un freelance sur des gros projets. A ce moment là, une quantité de questions se posent :
- Comment travailler sur le même fichier ?
- S’il travaille sur un fichier différent, comment peut-il accéder à mes symboles ?
- S’il reprend une de mes maquettes, comment revenir facilement à ma version pour comparer ?
Pour travailler à plusieurs sur le même fichier Sketch, GIT est apparu très vite comme la solution évidente. Cet outil incontournable du code collaboratif n’en restait pas moins peu pratique pour mettre en commun deux versions différentes de fichiers Sketch.
Quand Mathieu (le premier designer à nous rejoindre) est arrivé chez MeilleursAgents, il avait déjà entendu parler d’un outil équivalent pour les maquettes Sketch : Abstract. Il reprend les mêmes logiques que GIT, création de “branches” pour travailler sur 2 versions d’un même fichier et utilisation de “commit” pour enregistrer et garder les traces des modifications faites sur une “branche”. Mais le principal avantage d’Abstract, c’est qu’il permet de rendre plus visuels les changements faits sur un fichier, ce qui est d’autant plus pratique pour gérer d’éventuels conflits.
Même si nous avions trouvé une solution adéquate avec Abstract pour travailler à plusieurs sur les même maquettes, il fallait tout de même limiter les conflits générés au fil des projets. Nous avons donc décidé de séparer le fichier Sketch unique du site MeilleursAgents en autant de fichiers qu’il y a de fonctionnalités majeures sur le site. Ainsi, nous limitons les chances de collisions en travaillant sur les mêmes fichiers.
Le problème, en découpant ainsi le fichier Sketch unique, c’est que nous ne pouvions plus avoir accès aux même symboles d’un fichier à l’autre. Nous perdions ainsi le principal avantage de Sketch qui est celui de pouvoir faire un design modulaire facilement maintenable. Notre logique en “atomic design” était donc mise à mal.
Heureusement, la version 47 de Sketch avec la gestion de librairies externes de symboles est arrivée au moment où nous en avions besoin. Honnêtement, je ne sais pas comment nous aurions fait sans, ou comment les autres équipes de designers faisaient jusque là pour gérer les symboles avec Sketch. Avec l’arrivée des librairies, nous pouvons maintenant rendre nos symboles communs à toutes nos maquettes et ainsi garantir leur bonne maintenabilité.
Mais un design cohérent et de qualité, tout comme le code, ne passe pas que par la mise en place d’outils adéquats.
Design reviews
Travailler avec d’autres designers qui n’ont pas toujours la même sensibilité graphique est peut-être le plus grand défi quand on n’est pas habitué. L’enjeu est de pouvoir garder une cohérence de l’interface sans pour autant frustrer ses pairs dans leur créativité. Dans ce cas, la meilleure solution reste et restera toujours la communication. Les développeurs ont encore une fois trouvé la bonne solution à travers les “pull request”. Quand un développeur a fini de coder une fonctionnalité, il la fait toujours relire par un autre développeur pour valider sa logique et vérifier que le code correspond à des standards définis en équipe.
Ctrl+C / Ctrl+V
Remplacer le mot code par maquette et garder à l’esprit que vos critiques doivent toujours être constructives. Et c’est peut-être ici que réside la plus grande différence avec les développeurs. Il est facile de glisser vers des débats interminables de goût et de couleur quand il s’agit de design. Les retours doivent toujours répondre à des problématiques de lisibilité, cohérence et alignements, les “je n’aime pas…” sont à proscrire. Il est possible de faire cette étape directement avec le designer pour échanger rapidement ou de faire les retours sur Invision avec l’outil de commentaire.
Pour finir, l’atomic design, le versionning de maquettes, les librairies de symboles et les design reviews sont des outils qui nous aident beaucoup au quotidien. Regarder du côté de l’organisation des développeurs a été la meilleure idée que nous ayons eu pour nous organiser. Mais une bonne communication et montrer régulièrement ce que nous produisons reste la meilleure façon de garder un design efficace et cohérent.
N’hésitez pas à réagir à cet article et échanger sur vos méthodes de travail !
