Comment améliorer la collaboration entre les designers et les développeurs ?
L’un des points névralgiques du développement de produits numériques est la qualité de la communication et l’alignement entre les différentes équipes contributrices (product managers, designers, product owners, développeurs…). Avec Romain Lesniak, UX designer chez Oodrive, nous sommes intervenus dans le cadre d’Open R&Day, un événement créé “pour et par les développeurs”, afin de partager notre expérience sur la collaboration entre les designers et les développeurs.
Evoluer dans l’univers produit, c’est certes faire le constat d’un certain déséquilibre dans le ratio designer/développeur. Celui-ci est en moyenne d’1 designer pour 8 développeurs dans les entreprises de la tech. Au-delà de la supériorité numérique des développeurs, il faut aussi reconnaître que le niveau d’intégration du design progresse partout en entreprise. Plus que veiller à l’équilibre des forces en présence, il convient de veiller à ce qu’une convergence productive s’opère entre eux. Dans cette perspective, les process et les outils jouent bien entendu un rôle majeur. Mais l’idée que nous défendons, c’est que les personnes qui les animent sont beaucoup plus importantes.
Depuis quelques années, il a été beaucoup question d’intégrer design et approche(s) agile(s), comme facteur clé de réussite de la collaboration entre les designers et les développeurs. De fait, cette convergence de raison a beaucoup questionné et challengé la démarche du design. Elle a produit une saine remise en question de nos process et parfois aussi des applications extrêmes comme le design sprint. Si notre exigence est de travailler avec méthode, ces méthodes ne doivent pas pour autant devenir des obsessions. Au sein d’Oodrive, nous préférons contextualiser l’approche du design plutôt que d’appliquer des recettes. Par contextualiser, nous entendons la capacité d’adaptation que doivent appliquer les designers pour l’intégrer harmonieusement avec la culture de l’entreprise et les valeurs des équipes. Nous préférons déjouer les modèles pour placer les personnes et leur esprit critique au centre de nos démarches, dans un programme d’action précis.
De fait, les process et les outils du design évoluent de façon dynamique et se nourrissent de nombreuses influences. La forme même de nos livrables n’est plus la même. Les maquettes pixel-perfect de Photoshop ont laissé place à des prototypes plus ou moins sophistiqués qui permettent d’éprouver une version simplifiée du produit. Ils sont plus que jamais précis sur les intentions de conception que les designers adressent aux développeurs. Nos techniques de travail convergent. Avec des outils comme Sketch et Abstract, les designers ont introduit le versionning dans leurs process, à l’image de GitHub. Avec des outils comme Abstract ou Zeplin, les designers ont cessé de créer des documents de charte graphique de 300 pages pour fournir aux développeurs les spécifications graphiques des interfaces. Pour autant, ces outils ne suffisent pas, ils requièrent une collaboration étroite entre les personnes, de se parler pour bâtir des projets communs. Les modes passent, le sens est éternel.
Si l’on devait citer l’une des démarches les plus fructueuses dans la convergence de cette collaboration entre les designers et les développeurs, ce serait sans aucun doute le design system. Il ne se limite pas à une bibliothèque de composants réutilisables et à une somme de guidelines. C’est une démarche et un livrable qui s’affine sur mesure. Chez Oodrive, par exemple, ce projet est un élément fédérateur des équipes. Produit à part entière, il est co-créé et co-géré par les équipes de design, les développeurs front-office, les développeurs mobiles et les développeurs client lourd. Plus que les gains de productivité qu’il promet, il appartient à tous. Le design system a permis chez nous d’accroître notre implication à de nombreux niveaux et notamment dans le suivi de l’assurance qualité. Nous sommes mieux synchronisés et nos développeurs sont parties prenantes dans la conception des interfaces. Sa force est de nous apporter des composants réutilisables à la fois en conception et dans le développement. C’est une convergence d’intérêt inédite entre les deux mondes. Elle s’inscrit naturellement dans le cycle de vie des produits de l’entreprise. Son déploiement est progressif, il ne suppose pas de grand soir. Avec les équipes de développement, nous préférons une approche incrémentale à une approche de radical redesign.
En résumé, la convergence de plus en plus évidente de nos métiers nous permet
- de parler un langage commun
- de développer des intérêts communs aux fondations mêmes des produits
- d’envisager des formes de collaboration qui ne reposent pas que sur des outils et des process mais sur des techniques de prototypage élaborées qui permettent de faire des allers-retours entre le code et le design
- de collaborer pas uniquement dans certaines phases des projets mais sur tout le cycle de vie
Au travers du prototypage, des design reviews, des démos et des itérations fréquents que nous menons, nous trouvons des occasions pour favoriser un mode projet harmonieux et porteur de sens, une des formes du “faire-ensemble”, formule plus pertinente que celle du “vivre-ensemble”. Au-delà de nos identités professionnelles, designers et développeurs trouvons le moyen de “bâtir des actions et des projets communs”. Les prochaines étapes de ce système commun, au-delà de la qualité logicielle recherchée, sont par exemple de nouvelles techniques de prototypage qui permettraient aux designers et aux développeurs de concevoir et de développer simultanément, en passant du design au code et réciproquement.
