Accéder au contenu
  • Blogue

Promouvoir une communication ouverte entre développeurs et designers

17 novembre - 17

Olivier Aubin
Lead Design

Selon la Loi de Conway, «toute organisation qui conçoit des systèmes (au sens large du terme) est contrainte de produire des modèles qui reflètent sa propre structure de communication». Ainsi, les problèmes de communication de votre organisation se reflèteront dans la conception de vos produits par des boutons mal alignés, des ombres manquantes, des animations mal ficelées, etc.

Chez Mirego, le design joue un rôle essentiel dans le développement des produits. Il fait en quelque sorte le pont entre les équipes multidisciplinaires pour que la structure solide de l’organisation soit reflétée dans notre travail. Pour nous, les équipes de design, d’assurance qualité (AQ) et de développement doivent travailler en synergie et l'implantation d'un processus d’assurance qualité (AQ) de design nous a permis de raffiner notre workflow, d'éliminer les frictions entre développeurs et designers et d'optimiser l’UX (expérience utilisateur) à peu de coûts.

Pourquoi l’AQ de design? Tout d’abord, la facilité d’utilisation d'un produit numérique nous permet de mesurer la qualité de sa conception et son UX. Ensuite, elle nous permet de valider que la qualité de son code et celle de son interface utilisateur (UI) sont intrinsèquement liées et produisent des résultats de qualité supérieure et une expérience utilisateur mémorable.

« Le design, n’est pas juste une question de forme ou de ressenti. Le design c’est le fonctionnement. »

⏤ Steve Jobs

Oui, je sais, mettre en œuvre des processus qui favorisent une communication ouverte et qui incitent à la collaboration entre équipes multidisciplinaires peut s’avérer assez complexe. Pour avoir déjà travaillé avec d’autres équipes, je peux confirmer qu’il n’est pas facile d’avoir une vision claire de ce que font au même moment une équipe de développeurs et de designers, même s’ils travaillent tous sur le même projet. Chez Mirego, c'est l'assurance qualité (AQ) de design qui nous a permis de régler ce problème. Elle nous permet de nous concentrer sur l’UX et de bâtir de meilleurs produits. Voici comment nous avons procédé pour la mettre en place.


Trouver le problème

Pour être franc, on voit souvent l'AQ de design comme une étape qui n’arrive qu’après-coup. Autrement dit, on y réfléchit seulement une fois les sprints complétés et la nouvelle version prête à lancer. Plus souvent qu’autrement, l’AQ de design n’est pas intégrée au processus de validation de l’application : inutile de dire qu’il est frustrant et peu efficace de travailler en marche arrière. En fait, cela attise des frictions dans les relations entre développeurs et designers. Bref, c’est improductif. De plus, en abordant ainsi le processus d’AQ de design, on risque d’oublier certains détails de l’UI, mineurs mais importants, et qui peuvent créer des faiblesses dans l'interaction avec l’utilisateur et, du même coup, une expérience moins agréable. En adoptant un processus d’AQ de design en continu, l’équipe peut constamment réévaluer le design d'un produit en peaufinant les détails et ainsi relever tout problème potentiel. L’équipe travaille de façon préventive, pour voir venir les lacunes et s’assurer que l’UX est parfait du début à la fin.


Collaborer pour trouver des solutions

Après avoir compris cette idée, nous nous sommes mis à brainstormer en équipe pour trouver des solutions au problème. Voici un survol des éléments intéressants qui sont ressortis:

  • Permettre aux designers de collaborer sur GitHub pour favoriser et améliorer la communication avec les autres équipes.
  • Aviser les designers de toute demande de changement lié à l’UI, pour leur permettre de la valider pendant que les développeurs la codifient pour l’améliorer.
  • Donner aux designers la permission de faire, au besoin, des ajustements en temps réel.
  • S’assurer que l’équipe de design participe du début à la fin pour qu’elle puisse faire le suivi des travaux, pas à pas et en temps réel.
  • Améliorer la communication et les processus de travail entre les équipes de développement et de design pour qu’elles puissent collaborer en temps réel. Par exemple, si on étend le processus de pull request aux deux équipes, on leur permet de voir les commentaires de façon chronologique, ce qui les aide à rester concentrés et sur la même longueur d’onde.


Définir le processus

Après avoir révisé nos notes, nous sommes arrivés à la conclusion qu’en instaurant un processus de pull request, nous aurions une façon plus efficace de travailler. Voici ce processus :

  • Étape 1 – Les designers créent des maquettes, puis les développeurs les intègrent.
  • Étape 2 – Les développeurs avisent l’équipe de design graphique de toute demande de changement liée à l’UI ou au design, pour lui permettre de vérifier des éléments d’interface comme la police, les couleurs et les animations.
  • Étape 3 – Les développeurs ajoutent des écrans de téléphone de diverses tailles (iPhone 8, 8+, X, etc.) pour que les deux équipes puissent vérifier que l’aspect de chaque écran est parfait et qu’il fonctionne comme il devrait.
  • Étape 4 – Le designer choisit d’accepter ou non la demande de changement et peut laisser des commentaires aux développeurs, ou se servir de GitHub pour suggérer lui-même des modifications.
  • Étape 5 – Avec un tel feedback, l’équipe de développement peut alors procéder à la modification des éléments d’UI surlignés par le designer et faire le suivi de validation avec une autre pull request une fois que tout est complété.

Ainsi, une fois le sprint complété ou la nouvelle version prête à lancer, le designer n’aura plus à revoir l’application en entier pour s’assurer que tout est en place et fonctionne en douceur. En instaurant ce processus, nous avons rationalisé notre travail et comblé le vide entre les équipes de design et de développement.


Les avantages

Je sais que ça peut sembler futile, mais cette solution toute simple pourrait améliorer votre travail et votre productivité. En favorisant la communication continue et en adoptant des processus de travail intégrant les équipes de développement et de design, on ouvre la voie à un dialogue intéressant sur l’UI et l’UX, pour que tous aient une vision claire de l’état d’avancement du projet à chaque sprint. Chez Mirego, nous cherchons non seulement à nous améliorer, mais aussi à améliorer nos processus de travail. Et c’est cette capacité d’adaptation et cet esprit d’ouverture qui nous poussent à améliorer nos processus de travail et qui nous donnent les moyens de créer des produits numériques de calibre mondial, reconnus pour leur excellence.

00:00
00:00

Switching to English