Chez Getaround et Doctolib, j’ai mis en place un framework de collaboration où l’UX Writer adopte un rôle owner, partner ou consultant. Ce framework a été inspiré par un article de Bronwyn Berkery et j’ai également écrit mon propre article sur ce sujet.

C’est quelque chose que j'avais fait aussi au sein de Getaround en tant que contributeur individuel parce que j'étais le seul UX writer et du coup, je devais gérer toutes les demandes. 

Lorsque tu es la seule personne, ce n’est pas possible de suivre tous les projets à la même vitesse et avec la même implication. 

J’ai trouvé un framework de collaboration de owner/partner/consultant. C’est-à-dire :

• Est-ce que je vais vraiment prendre le l’ownership de A à Z sur l’UX writing de ce projet ? Dès le début jusqu’à la fin. 
• Ou est-ce que je vais m’impliquer un peu plus tard en tant que partenaire, mais quand même assez tôt dans la phase define (du double diamond) ? 
• Est-ce que ça va être plutôt un travail de collaboration entre les product designers et les PM où ils vont mettre leur cerveaux ensemble et je suis là en support en tant que consultant ? 

Au début, en arrivant chez Doctolib, je me disais ce qui marchait pour moi chez Getaround, en tant qu’une personne qui bossait avec 6 squads différentes et trois product designers, ça ne va pas fonctionner dans une boîte comme Doctolib où on a presque cinquante, peut-être soixante-dix squads. 

Les gens au sein de mon équipe avaient un peu ce même problème où il y avait trop de projets en même temps, où ils avaient du mal à les différencier et à prioriser quels étaient les projets sur lesquels ils devaient passer plus de temps que les autres. 

Du coup, je me suis dit que ce framework n’était peut-être pas mal. 

J’ai parlé avec mon ancienne manager de Getaround qui m’a m’a dit :

“Franchement, ce framework, ça marchait trop bien. J’ai exactement la même chose avec cette nouvelle user researcher parce que c’est le même genre de situation où on peut avoir énormément de demandes.” 

Le fait qu’elle me fait ce retour, je me suis dit que c'était peut-être assez solide comme framework. Du coup, j’ai expérimenté jusqu’à quel point ça marche sur une échelle un peu plus grande. (et c’est encore en cours)

En tant que manager, je joue un peu le rôle de consultant où on a des créneaux dans nos agendas que les membres de l’équipe peuvent réserver pour faire une content critique, pour faire un pair review, et d’autres moments pour présenter le travail en cours. En réalité, je joue un peu le rôle de consultant avec le travail.

Pour prioriser, entre owner/partner/consultant lorsque j’étais chez Getaround on observait dans un premier temps ce qui était dans la roadmap et je notais les projets selon des critères d’exclusions ou non: 

• Est-ce que ce sont des problématiques qui sont déjà connues au sein de la boîte ou pas ? 
• Si on est en train d’aborder de nouveaux problèmes, je pense que je devrais être là
• Si ce sont des problèmes reconnus, peut-être plus apprises sur des connaissances existantes, je considérais que les product designers et PM devraient être un peu plus à l’aise. Ces deux-là sont assez liés, ils connaissent bien ces utilisateurs ou pas. 
• Si c’était un nouveau type d’utilisateur, je pense que je devrais être là, Si c’est le type de base qu’on met dès le début et qu’on connaît bien, à ce moment-là, je pense que les product designers et les PM peuvent être un peu plus autonomes. 
• Du coup, c’est aussi lié sur est-ce que c’est un sujet sensible ou pas ? 
• Si les risques étaient plutôt élevés, je bascule plutôt vers owner 
• Si les risques étaient plutôt négligeables, je peux accepter d’avoir un peu moins la main dessus. 

C’est hyper dur d’accepter de ne pas avoir le contrôle, néanmoins il faut garder en tête que l’on est en train de créer des logiciels.  

On peut modifier les libellés après si besoin. Si tu es en train d’imprimer des magazines c’est plus dur à rattraper à ce moment-là, donc tu as de la marge de manœuvre (selon le projet).