Le pair

Cela fait déjà 4 articles que je vous raconte le travail au sein de l’équipe Zam. Je creuse aujourd’hui un souci rencontré dans mes allers-retours avec David et Ronan, les 2 développeurs qui implémentent mes maquettes : Comment faire remonter pour améliorations une longue liste de petits détails ?

Le problème initial

Lorsque je fais des maquettes, je crée souvent de 0, ce qui m’oblige à faire de nombreux choix. Or, lorsque je suis arrivée sur Zam, les développeurs avaient déjà mis en place une base d’interface, ce qui fait que lorsqu’ils ont, par la suite, implémenté les maquettes, j’ai repéré plein de détails qui faisaient que l’interface n’était plus aussi bien “finie” que lorsque je l’avais conçue sur les maquettes.

Je précise, ici je ne parle pas de décalages liés à une mauvaise conception de ma part qui n’étais pas réalisable techniquement, mais clairement d’oublis. Je ne parle pas non plus d’être tatillone et de vouloir du pixel perfect, ce n’est pas le cas. Mais le diable est dans les détails et si parfois, je mets du gras, ou du gris plutôt que du noir, c’est bien que j’ai une idée derrière la tête: En général, hiérarchiser visuellement les différents éléments de l’interface.

Donc imaginez-vous, nous discutons de ce qu’il y a à faire, je réalise des maquettes, on en débat, on parvient à un consensus, je les envoie à David et Ronan pour qu’ils les implémentent, et une fois que c’est en ligne, je relève qu’il faut du gris à la place du noir à un endroit, une icône mal alignée ailleurs, un mot qui a changé là-bas…

Sauf que déjà en faire la liste pour moi, c’est long, mais en faire une, exhaustive, pour qu’ils puissent effectuer les changements nécessaires, en expliquant assez clairement où le souci se trouve, et comment l’améliorer précisément, et répéter 15 ou 20 fois ces actions, ça me semblait vraiment pénible et rébarbatif. Je ne savais pas bien comment m’en sortir !

La solution ? Le pair !

Le pair programming est une astuce pratiquée par certains binômes de développeurs : On se met côte à côte et on partage le clavier, ou on s’appelle et on partage son écran pour partager une vision commune de ce qu’il faut faire et de comment le faire.

Mais j’avoue que je n’y avais pas songé pour le design, et pourtant !

Je ne sais plus comment est arrivée l’idée, mais face à mon souci de liste-sans-fin que je ne savais pas comment traiter, j’ai appelé à l’aide sur le tchat de l’équipe. Proposition : “Viens on s’appelle, et tu me raconte ce qu’il faut changer”

Et très vite, nous nous sommes mis à partager nos écrans pour que je puisse dire précisément “Oui, là, ici, cette page, cet endroit, il faudrait changer ça, comme ça”. Et ensuite, selon la difficulté, David ou Ronan notait pour le faire plus tard, soit, pour la majorité des cas, il modifiait immédiatement le code pour réaliser les changements !

Les avantages

Les avantages sont très nombreux pour moi :

• Je peux facilement expliquer précisément ce que je veux changer,
• Je vois en temps réel l’impact des changements,
• Je peux changer d’avis et itérer très très rapidement,
• Si la modification est complexe (alors qu’elle semblait triviale), je peux travailler en temps réel avec mon binôme pour voir ce qui est plus simple à faire techniquement et répond à la problématique de conception (Oui, je pense à toi, header de tableau de malheur qui n’est pas du tout implémenté de la même façon selon les navigateurs et qui nous donne des cauchemars !!)

Et en plus, ça permet de discuter ensemble et de ne pas être seulement dans une relation “je te donne mes maquettes et exécute-les”, mais de partager les problématiques de chacun·e !

En résumé, faire du pair me fait économiser du temps, de l’énergie, partager des moments avec les développeurs de l’équipe, et mieux comprendre les problématiques auxquelles ils sont confrontés. Tout est positif et très enthousiasmant !

Et après ?

Dans le prochain article, je vous raconterai ma première observation terrain, au ministère de la santé et sécurité sociale, de nuit, pour la première utilisation en réel de Zam !