Geek, fermé d’esprit, pas créatif, trop pragmatique, réfractaire,… sont parfois ce que peuvent penser les designers à l’égard des développeurs. À l’inverse, les designers sont souvent qualifiés par les développeurs de stars, arrogants, rêveurs, idéalistes, irréalistes…

Ces préjugés et défiances sont généralement dus à une méconnaissance respective des deux parties tant sur les modes et temporalités de réflexion que sur les processus et logiques d’exécution. Les dualités entre les métiers de la conception et de la réalisation ne sont pas nouvelles et se retrouvent dans d’autres secteurs : architecte / artisan, designer produit / ingénieur, réalisateur / acteur, chorégraphe / danseur…

Chez Yumans, nous sommes persuadés, qu’en plus d’être utile, ergonomique et esthétique, un produit doit être pensé de façon réalisable. Cela passe notamment par une approche technique lors de la phase de conception (penser les variables de styles, grilles, composants et modules réutilisables, comprendre le choix des frameworks, des technos, l’architecture des données, les logiques back-end… mais aussi par une ouverture à l’implication de l’équipe de développement tout au long du processus de création.

À quel moment faire intervenir le développeur ?

Dans notre cycle de conception, il existe de nombreux moments pour que les deux parties puissent discuter entre elles.

Process Design - Développeur

Pour des raisons d’organisation et de coût, il n’est pas toujours obligatoire (ni nécessaire selon la nature du projet) que toutes les étapes soient respectées. Nous sommes conscients que ces temps d’échanges demandent du temps, de la disponibilité et l’envie de bien faire de part et d’autre. 

Néanmoins, plus les interactions avec les développeurs sont nombreuses, plus le projet aura la chance de voir le jour tel qu’il a été imaginé.

Avant l’intervention du designer

Avant même de lancer la réflexion sur le design, il est important d’essayer de savoir si le produit sera construit avec un langage ou un framework spécifique qui viendrait contraindre les possibilités front-end. 

Ce choix peut notamment être dû à des choix historiques, structurels ou budgétaires. Cependant, si les contraintes ne sont pas prises en compte dès le début, cela aura pour conséquence de produire des choses irréalisables. Le plus souvent, c’est le développeur qui se retrouvera à devoir composer par lui-même et à entrer les éléments au chausse-pied. Designer avec les contraintes en tête est la base principale de cette bonne relation.

Pendant l’intervention du designer

Lors de la phase de conception, il est nécessaire d’avoir un profil technique pour garantir la faisabilité de la solution imaginée. C’est également primordial pour l’équipe de développement de suivre l’avancement du projet afin de s’imprégner au mieux du contexte, de comprendre les enjeux, d’identifier les usages et de découvrir les fonctionnalités clés. Cela permettra de minimiser la phase d’onboarding, de réduire la documentation à produire et d’évaluer le temps de développement le plus en amont possible.

Ces informations peuvent s’obtenir à différentes étapes clés : 

  • À la restitution de la recherche : pour donner du contexte sur les profils, les cas d’usages, l’environnement d’utilisation, les fonctionnalités clés attendues…
  • À la phase de wireframe : pour donner de la visibilité sur la structure globale de la solution, la navigation, l’architecture de l’information, les parcours utilisateurs…
  • Aux premières maquettes : afin de découvrir le style graphique, challenger des composants, des interactions, des animations, identifier des états manquants…
  • À la livraison des assets : afin de présenter l’UI kit, la solution handoff et se mettre d’accord sur les process de suivi d’intégration (outil de ticketing, recette graphique…)

Pendant l’intervention du développeur

De la même manière que le développeur doit suivre l’avancement de la conception, il est primordial que le designer puisse suivre le développement de la solution. Cela permettra d’assurer un suivi qualité de l’intégration à travers des recettes graphiques. Le designer doit aussi rester disponible pour répondre aux questions de comportement et produire certains écrans et états qui auraient été oubliés (ex : page 404, état d’erreur, …).

Enfin, même si des échanges ont eu lieu pendant la phase de conception, la réalisation amène toujours son lot de surprises et d’évolutions. Le designer doit ainsi continuer de rester dans la boucle pour soit trouver des compromis, soit produire un nouvel écran, soit repartir dans une phase de conception complète si le changement est trop important.

Conclusion

La vision que nous avons voulu apporter dans cet article est avant tout une logique de fond. Nous sommes conscients qu’elle est assez liée à notre métier de prestataire de services et que dans le cadre d’un team designer / développeur intégré certaines choses sont plus implicites mais l’idée d’une meilleure collaboration, écoute et compréhension des rôles restent primordiale dans la réussite d’un projet peu importe son organisation.

Visuel : Warp.dev Terminal par Josh Warren sur Dribbble