Au cours d’un projet, les designers et les développeurs sont amenés à travailler ensemble. Leur relation est clé pour son bon déroulement.
Avant d’aller plus loin, il faut garder en tête que les deux profils sont complémentaires et ils ont de forte chance d’avoir le même objectif : terminer et faire rayonner le projet.
Cependant, ils ont différentes priorités et ils n’abordent pas les problématiques via la même perspective : les designers sont attachés au look & feel et à l’expérience utilisateur sans couture alors que les développeurs ont en tête les performances, la stabilité et les contraintes techniques.
La collaboration est donc primordiale. Elle permet de s’appuyer sur les connaissances de chacun afin d’assurer une réalisation sans accroc et de concevoir une expérience unique.
Bien qu’il existe des process, nous, designers comme développeurs, pouvons ajouter une dose d’effort pour s’assurer que le courant passe et que les informations circulent.
J’ai été dans les deux cas : je suis actuellement designer et je transmets mes maquettes aux développeurs. Et au cours de mes anciennes expériences, j’ai été développeuse qui recevait des maquettes de la part de designers.
Donc les conseils dont nous allons parler aujourd’hui ne viennent pas que d’un constat en tant que designer mais bien d’une compréhension des enjeux et problématiques des deux parties.
Ce sont des actions qui, en tant que designer, vont vous permettre de tendre la main aux développeurs et de collaborer sereinement avec les équipes techniques mais également les choses que les développeurs apprécient qu’on mette en place au cours de la collaboration.
#1 IMPLIQUER
Ce que je constate souvent dans les process en mission, c’est ce moment particulier où le designer montre ses maquettes (plusieurs maquettes déjà bien abouties) et c’est une grande découverte pour les développeurs.
Ce n’est pas une bonne chose ni pour le projet ni pour le client, les chefs de projet ou les développeurs. On s’écarte de la collaboration en équipe et je trouve qu’il y a un vrai manque de considération vis à vis du développeur.
Et je pense que c’est réciproque, en tant que designer, c’est dérangeant d’être écarté du projet une fois que les maquettes sont transmises aux développeurs.
Il faut donc inclure les développeurs dès le début du projet et rester nous-même dans la course jusqu’à la fin du projet.
Au cours de la conception,
- Engager la discussion : les développeurs se sentiront valorisés et cela permettra, au moment du développement, qu’ils aient une meilleure compréhension du projet et des problématiques rencontrées.
- Valider les contraintes techniques et s’entraider à trouver des solutions ou des compromis.
- Recueillir leur avis : les développeurs sont malins et surtout ils ont sûrement récolté de l’expérience sur d’autres projets et peuvent donc apporter une valeur ajoutée.
Pendant le développement, même si les écrans ont déjà été transmis,
- Garder le contact : afin de vérifier si les développements sont en accord avec les décisions prises en atelier et également si elles nous conviennent. Cela permet d’affiner mais également de montrer qu’on est disponible si jamais il manque quelque chose ou s’il y a un doute sur une fonctionnalité.
- Faire des suggestions de micro-interactions pour guider l’utilisateur et approfondir le lien entre la machine et l’humain.
- Être réactif : il arrive que le développeur nous demande de changer quelque chose. Il est possible que techniquement ça ne soit pas réalisable ou bien que cela ne corresponde pas au socle technique choisi. Dans ce cas, il faut rester ouvert d’esprit et engager le dialogue pour trouver un compromis.
Si les designers et les développeurs collaborent du début à la fin, il y a moins de chances que les conceptions soient irréalisables ou non abouties.
#2 COMPRENDRE
Ce qui me sert beaucoup pendant mes missions, c’est de connaître quelques bases de code. Le fait de savoir comment mes maquettes vont être découpées et implémentées, savoir également anticiper les contraintes techniques que peuvent rencontrer les développeurs, cela m’aide à adapter mon design et à proposer des solutions réalisables.
Anticiper ces problématiques permet de ne pas perdre de temps mais également de créer un dialogue construit avec les développeurs avec lesquels je travaille.
#3 DOCUMENTER
Transition toute trouvée avec les outils qui me permettent de partager les maquettes avec les développeurs de manière à ce qu’ils aient tout ce dont ils ont besoin. Par exemple, Invision ou Zeplin.
Grâce à ces outils, le développeur ne perd pas de temps à ouvrir et à comprendre les logiciels du designer. Ainsi, il peut analyser les maquettes (les marges, les couleurs, les styles de texte, se repérer par rapport à la grille, …). Il y a aussi la possibilité d’ajouter des commentaires et ainsi avoir un échange permanent sur les doutes ou les questionnements de chacun.
Si aucun de ces outils ne peut être utilisé, je vous conseille de créer un guide de styles. Ce document rassemble les codes couleurs, les typographies et les styles de texte, les icônes, les espacements et la grille, les interactions et les styles de boutons / liens.
Lors de la passation des maquettes, il est également important de penser à exporter l’ensemble des éléments graphiques (logos, illustrations, icônes, pattern…) utilisés pour la conception de l’interface. Le point positif des outils comme Zeplin, est qu’en 2 clics sur l’outil de conception, les assets sont disponibles pour les développeurs dans Zeplin.
L’idéal est d’échanger sur tous ces process et outils en début de projet et de convenir d’une méthodologie d’échange qui convient à tous. En général, je suis force de propositions : je donne des exemples d’outils qui pourraient être utilisés et des points d’échange à planifier. Ensuite, je vois et j’ajuste en fonction des retours de l’équipe.
Si un Design System existe, alors le designer va concevoir en utilisant ses éléments. Il est donc important de se renseigner si un Design System est mis en place et communiquer avec l’équipe de développement sur celui-ci. S’il n’en existe pas, il peut être intéressant de s’interroger sur l’intérêt d’établir un Design System. Cependant, il n’est pas nécessaire pour tout type de projet et ne doit pas être un frein pour les échanges avec l’équipe de développement si ce n’est pas le cas.
#4 MONTRER
Construire un prototype et avoir une vue d’ensemble du projet peut être bénéfique pour le designer et l’expérience qu’il construit.
Mais cette vision est aussi bénéfique pour le développeur. Cela lui permet de s’imprégner du parcours et de comprendre les différentes étapes.
- Il va ainsi pouvoir détecter les éléments similaires, les potentielles (futures) difficultés qu’il pourrait rencontrer ou les éléments existants.
- Il pourrait avoir des idées notamment sur les animations et avoir du temps pour anticiper et penser à l’optimisation du code.
- D’ailleurs, il peut être également intéressant de montrer aux développeurs des exemples ou des inspirations.
Il m’est arrivé au cours de certaines missions, de ne pas avoir le temps de réaliser un prototype poussé avec les animations que j’imaginais. Mais le fait d’échanger avec l’équipe de développement sur certaines animations trouvées sur d’autres sites, m’a permis de communiquer l’idée et a permis aux développeurs d’avoir un exemple de ce que j’avais en tête et pouvoir le reproduire.
#5 CENTRALISER
Être organisé ! Une des clés quand on collabore est de centraliser les documents, les maquettes, les notes et de ne pas s’éparpiller. Sinon c’est un enfer pour s’y retrouver et savoir où aller chercher telle ou telle information.
Mais cela implique aussi d’être rigoureux par exemple sur le nommage des éléments, les espacements, la taille des blocs, … Les développeurs ont besoin de cette structure pour ne pas se poser trop de questions et se perdre.
Nous avons peut-être l’impression de perdre du temps. Mais le fait de mettre en place une organisation et une méthodologie dès le début du projet, cela nous en fait gagner par la suite. Nous créons des automatismes qui nous rendent plus efficaces et qui améliorent la collaboration. Et cela va se ressentir dans le produit final.
EN CONCLUSION
Au cours de mes missions, j’ai remarqué que les développeurs apprécient que l’on s’intéresse à la partie technique et qu’on leur donne le plus de détails possibles sur notre travail. Le fait de parler le même langage ou tout du moins avoir quelques mots de vocabulaire en commun, permet de résoudre un problème et d’apporter une solution que chacun de nous comprend.
C’est pourquoi j’encourage autant aux designers qu’au développeurs d’aller vers l’autre et d’échanger – grâce à des réunions, des messages et/ou des outils.
Il faut retenir que la collaboration entre chacun des acteurs sera bénéfique à tous les niveaux du projet, de la conception à la mise en production.
Source image : https://undraw.co/illustrations
Alexa CUELLAR UX-UI Designer @UX-Republic
Nos prochaines formations
SMILE Paris SMILE Paris UX-REPUBLIC Belgique UX-REPUBLIC Belgique SMILE Paris SMILE Paris Distanciel SMILE Paris UX-REPUBLIC Belgique SMILE ParisCONCEPTION UX/UI ACCESSIBLE # Paris
163 quai du Docteur Dervaux 92600 Asnières-sur-SeineSERVICE DESIGN : LES FONDAMENTAUX #Paris
163 quai du Docteur Dervaux 92600 Asnières-sur-SeineUSER RESEARCH : APPRENDRE DES UTILISATEURS # Belgique
12 avenue de Broqueville - 1150 Woluwe-Saint-PierreTESTS UTILISATEURS # Belgique
12 avenue de Broqueville - 1150 Woluwe-Saint-PierrePILOTER ET MESURER L’UX # Paris
163 quai du Docteur Dervaux 92600 Asnières-sur-SeineUI-DESIGN : LES FONDAMENTAUX # Paris
163 quai du Docteur Dervaux 92600 Asnières-sur-SeineDESIGN SPRINT : INITIATION & FACILITATION # Distanciel
Depuis chez vous !SCRUM PRODUCT OWNER – CERTIFICATION SCRUM INSTITUTE # Paris
163 quai du Docteur Dervaux 92600 Asnières-sur-SeineDESIGN THINKING : CRÉER DE L’INNOVATION # Belgique
12 avenue de Broqueville - 1150 Woluwe-Saint-PierreSTORYTELLING : L’ART DE CONVAINCRE # Paris
163 quai du Docteur Dervaux 92600 Asnières-sur-Seine