UX designers et développeurs de tous les produits, unissez-vous !
Les ateliers de Paris Web
L’idée de cet article m’est venue lors des ateliers de Paris Web, en septembre dernier.
Les ateliers de design étaient alors complets très vite. Et moi, je disais que c’était finalement assez peu étonnant, puisqu’un développeur (ou une développeuse) peut parfaitement participer à un workshop design, alors que c’est beaucoup plus compliqué pour un designer d’aller suivre un atelier de PHP (même si la douce symphonie de la programmation bien indentée dans l’éditeur de code, c’est quand même, finalement, déjà de l’UX (eh ouais, vous utilisez les théories de la gestalt sans même le savoir, mais c’est un autre sujet).
C’est en réaction à cette réflexion qu’une participante aux ateliers me répondit très spontanément :
« Parce que t’as déjà vu des dev s’intéresser à l’UX, toi !? »
Je vivrais sur une autre planète ?
Je dois, de fait, vivre sur une autre planète, moi, parce que oui, j’en connais des développeurs•ses qui s’intéressent à l’expérience utilisateur. PLEIN, même.
Je ne suis certes pas UX designer depuis la Nuit des Temps, mais j’ai plutôt l’impression, au contraire, que je travaille avec les développeurs•ses et pas avant eux. Pour une histoire assez évidente de workflow, bien sûr, je conçois en amont du développement, mais je n’ai vraiment pas l’impression de faire tout mon travail seule dans mon coin, en attendant que les GI des variables et des fonctions arrivent pour tout réaliser, sans se poser aucune question sur le pourquoi du comment.
Et donc cette question : Comment se fait-ce que certains designers ou Product Owners croient les développeurs•ses incapables de penser autrement que technique et de n’avoir rien à dire sur la conception d’une interface ?
On ne les prendrait pas un peu pour des idiots ?
J’imagine bien que, s’ils ont cette conviction, ce doit être basé sur du vécu. J’ai moi-même aussi parfois été confrontée à des collègues assez peu loquaces, mais ça n’a jamais vraiment duré.
Mais si, de base, tu te dis « Nan mais laisse tomber, ces nerds, ils ne sont bons qu’à pisser des lignes de code : tant que ça marche, le reste ils s’en fichent complet », bon, on ne va pas se mentir, c’est clair que c’est mal barré.
Alors je vais donner mon point de vue, et partager ma façon de faire. Et je suis bien obligée de dire que la méthode Scrum m’a beaucoup aidée pour mettre tout ça en place.
Échanger, la base.
Présente tes choix de conception aux développeurs•ses, comme tu le ferais avec l’UI designer avec qui tu collabores. Nous, à la MAIF, nous organisons des sortes de revues de backlog en amont du Planning Poker, où sont exposées les User Stories qui seront embarquées dans le Sprint qui suit. C’est à ce moment-là que je présente les maquettes et étaye les choix de conception.
Même si tu ne bosses pas en plateau produit/projet, que tu ne fais pas de Planning Poker, provoque des points où tu exposes tes choix de conception.
Bien sûr que ça va réagir, c’est même le but.
Les réactions seront d’autant plus vives quand les choix de conception évoluent. Et c’est parfaitement compréhensible : faire et défaire du code en fonction des désidératas des UX est particulièrement frustrant !
Ces cérémonies prennent un peu de temps, mais c’est, à mon sens, indispensable. Au bout du compte, c’est certain qu’il y aura moins de temps de perdu, et d’énervements évités du style « Mais putain – oui, parfois il arrive qu’on dise des gros mots – ! Pourquoi elle veut qu’on fasse ça comme ça ? C’est n’importe quoi ! ». C’est peut-être n’importe quoi, mais il y a probablement des raisons, donc autant échanger nos points de vue avant. Comme ça au départ du sprint, il n’y aura plus de potentielle animosité.
Et, magie des relations sociales, parfois, il arrivera même que les développeurs•ses te suggéreront des astuces auxquelles tu n’aurais pas forcément pensé au départ. Parfois il arrive que tu fasses des choix effectivement mauvais, et c’est en les confrontant avec d’autres points de vue que peuvent te venir les bonnes solutions (C’est un peu notre canard en plastique à nous, designers).
Parce que oui, beaucoup de développeurs•ses s’intéressent à l’expérience utilisateur, font beaucoup de veille, y compris sur des sujets de design.
C’est précisément ce qui est cool, et que personnellement j’aime dans mon métier, c’est qu’on s’enrichit de nos différentes expériences !
L’implication. La clef.
En se sentant impliqué, valorisé, dans une ambiance bienveillante, on est toujours plus enclin à poser des questions, échanger son point de vue. Bref, se challenger. Je déteste ce mot, mais pour le coup, je trouve qu’il est plutôt approprié.
Pendant ces Revues de Backlog ou en Planning Poker, ça m’est souvent arrivée qu’un développeur me pose des questions sur la façon dont j’avais construit une interface. Et quand tu expliques avec des arguments tangibles comme de la data, des éléments piochés dans ta recherche utilisateur (y compris dans les tests utilisateurs) et, bien sûr, l’état de l’art, tes collègues comprennent et se sentent impliqués.
D’ailleurs, ça fonctionne. Sur un des produits où des tests utilisateurs avaient été réalisés après développement du MVP, tous me demandaient les résultats.
Mea culpa, en dehors d’échanger certains résultats de l’étude autour du café de la pause du matin, je n’ai jamais pris le temps d’exposer l’intégralité de l’étude. Ne faites pas ça chez vous.
L’UX, c’est l’affaire de tous.
Bien sûr, il y aura toujours des récalcitrants, mais on gagnera pas la bataille de la meilleure conversion tous seuls avec nos Post-It*. Et tu sais pourquoi ?
En réalité, on le sait tous : sans bonnes performances techniques, l’UX de nos produits ne vaut rien. Tu pourras faire les formulaires les mieux conçus de la Terre, mais si tu as des pages qui mettent 10 secondes à se charger, tu peux fermer boutique. Et on a, nous, UX designers, beaucoup à apprendre des développeurs•ses sur la façon d’optimiser notre conception pour améliorer les perfs.
Donc autant tous s’y mettre ensemble.
C’est tellement rien d’y croire,
et tellement tout, pourtant,
qu’il vaut la peine de le vouloir, de le chercher, tout l’temps.
Pour que l’amour
qu’on saura se donner
nous donne l’envie d’aimer (l’UX). (Steve Jobs, enfin il me semble.)
↑*Marque déposée qui peut remercier l’UX design d’exister pour lui avoir donné un nouveau levier de croissance.