Qu’est ce que je suis ?

 

Télécharger le PDF

La semaine dernière, je suis allée à un évènement Flupa, au cours duquel une jeune femme issue d’un master Architecture de l’information m’a demandé quel était mon poste. J’ai répondu ergonome. C’est ce qui est écrit sur ma fiche de paie : développeuse ergonome. Je n’ai jamais compris ce que le “développeuse” venait faire là-dedans mais en tout cas, officiellement, je suis ergonome. Pourtant, la vérité c’est que je ne sais pas ce que je suis.

Ergonome, UX designer, architecte de l’information ? Et je ne parle même pas de mes rôles officiels ou officieux de Product Owner, Scrum Master, manager, responsable qualité. Je n’ai de formation pour aucun de ces métiers puisque je viens d’un cursus académique en neurosciences. Quand je suis arrivée sur ce poste, j’ai beaucoup lu sur l’ergonomie et l’UX design. J’ai suivi un débat enflammé sur la liste ergo-ihm sur la question de valoriser un diplôme d’état d’ergonome pour ne pas mélanger les choux et les carottes. J’ai lu encore. J’ai fini par me dire que c’était blanc bonnet et bonnet blanc, des ergonomes qui viennent de la psycho et des UX designer qui viennent du design, mais qui font la même chose dans l’entreprise, du coup j’ai mis les deux sur mes profils Viadeo et LinkedIn. Mais de temps en temps, on me pose la question, ou je lis des choses qui excluent l’un de l’autre, et je ne sais plus. Je me suis formée sur le tas, je ne viens ni de la psycho ni du design, et je ne sais pas dans quelle case je rentre.

En revanche, je peux vous dire ce que je fais, ça je le sais.

Je travaille sur trois produits, reliés les uns aux autres : une bibliothèque virtuelle, un document enrichi, et un logiciel utilisé en interne permettant de produire et d’enrichir des documents. Deux de ces produits ont été montrés au public pour la première fois ces 10 derniers jours : voici le rapport annuel de l’observatoire des PME de Bpifrance (première production avec la nouvelle génération de document enrichi, lancement officiel le 24/02/16) et la bibliothèque utilisée sur le salon Ekoburo auquel nous étions les 16 et 17 février derniers (lancement officiel prévu pour Juin). Comme nous travaillons avec une approche agile (voir mon article sur le sujet pour en savoir plus), des améliorations et des ajouts de fonctionnalités vont continuer à avoir lieu toutes les trois semaines.

Alors qu’est ce que je fais sur ces produits ?

Beaucoup de gens différents (utilisateurs, chefs de projet, big boss…) me rapportent des choses à faire et à améliorer sur ces différents produits. J’écoute, j’analyse les besoins, je cherche des solutions fonctionnelles, et j’essaie de prioriser les demandes. Comme je suis Product Owner (PO) de la bibliothèque virtuelle et du logiciel de création des documents enrichis, c’est à moi de décider ce qu’on fait et dans quel ordre. J’aide également à établir des priorités sur le troisième produit de par ma qualité d’ergonome, et pour assister la PO très occupée par ailleurs. Dans cette équipe, je suis ce qu’on appelle Proxy Product Owner.

Quand une fonctionnalité va bientôt être développée (théoriquement, dans le sprint précédent le développement), je fais des maquettes. Pour ça, je regarde ce que fais la concurrence, je lis parfois des articles sur le sujet, je réfléchis, je gribouille. J’ai en tête la théorie de la Gestalt, les critères de Bastien et Scapin, et toutes les bonnes pratiques détaillées dans mon article Base d’ergo : notions à connaitre et à appliquer. Je dois prévoir les comportements sur toutes les tailles d’écrans : desktop, tablette, mobile. Je présente mes idées aux graphistes ou aux développeurs qui pointent parfois du doigt certaines faiblesses du design. Je recommence. De plus en plus, j’utilise le papier comme support. C’est rapide, coût zéro de tourner la page de mon bloc-notes et de recommencer. Quand je veux quelque chose d’un peu plus propre je fais des maquettes dans Powerpoint : hyper simple, facile à annoter, et ça permet de montrer quelques transitions. Quand j’ai vraiment besoin de quelque chose d’interactif, j’utilise Axure. C’est l’outil qui m’a été fourni par la société, mais je trouve ça lourd, je l’utilise très rarement. De temps en temps, je fais des tests utilisateurs sur mes maquettes, c’est à dire que je ne me contente pas d’expliquer et de demander “T’en penses quoi ?” mais je fais une maquette dynamique et j’observe quelqu’un utiliser celle-ci, en lui demandant de verbaliser ce qu’il comprend et ce qu’il ne comprend pas. Je le fais rarement car je n’ai pas le temps, mais je gagnerais sans aucun doute à le faire plus souvent.

Quand je sais ce que je veux, je spécifie au maximum dans notre outil de gestion de Backlog les fonctionnalités et leur comportement : j’insère des pièces jointes, je précise point par point ce que je veux.

Pendant le développement, je réponds aux questions. Entre les points auxquels je n’ai pas pensés, et ceux que les développeur·se·s ont oubliés, j’ai toujours beaucoup de sollicitations.

En fin de développement, je valide. Je teste le comportement, et quand j’ai le temps je teste également sur tous les écrans à notre disposition : nos interfaces doivent être fonctionnelles sur tous supports, tous OS, tous navigateurs. Souvent les développeur·se·s n’ont pas fait cet effort en amont, et je leur remonte des bugs. Souvent aussi, il manque des morceaux de la fonctionnalité : “ok on peut ajouter des notes dans le document, mais le déplacement n’est pas comme je l’avais demandé”. Ça peut parfois boucler plusieurs jours : test – correction – test – correction.

En fin de sprint (toutes les trois semaines), je participe à la phase de validation complète avant livraison. Nous avons un plan de test que nous enrichissons à chaque nouvelle fonctionnalité, et nous déroulons ce plan de test sur le maximum de contextes parmi ceux que nous supportons. Je participe parfois également à la préparation du support pour la Sprint Review.

Depuis un mois, nous avons un testeur qui nous aide à tester dans tous les contextes, qui remonte et spécifie les bugs identifiés, et qui essaie de formaliser un process de tests fonctionnels. Cette demande venait de l’équipe, elle a émergé d’une rétrospective de Sprint. En tant que Scrum Master de l’équipe, c’est mon rôle d’animer ces temps de réflexion sur comment s’améliorer, mais également de remonter les demandes à la direction quand cela est nécessaire.

Dans ce cadre là, j’ai fait du recrutement, de la formation (pour expliquer au testeur tout ce qu’il avait besoin de savoir) et du management (on a eu 2 départs spontanés avant de trouver la perle rare, et un besoin de revoir le cadre de son contrat). J’ai également le sentiment d’être manager en tant que Product Owner, bien que cela ne soit pas du tout officiel. Pour les équipes (au moins certains membres), je suis la personne référente à prévenir en cas d’absence, mais également parfois en cas de frustration. Cette semaine par exemple, il a été décidé qu’une personne allait changer d’équipe. Pour éviter qu’elle ne le découvre à la réunion d’information en même temps que tout le monde, c’est moi qui lui ai annoncé la nouvelle, et heureusement que je l’ai fait car je sais qu’elle aurait très mal vécu de l’apprendre autrement. J’ai aussi lu récemment que le manager est la personne pour laquelle on est motivé de travailler, la personne qui fait que l’on reste ou que l’on part d’une entreprise. Quand l’un des développeurs de mon équipe m’a dit récemment qu’il était venu un samedi parce que “y’avait pas le choix si tu voulais la fonctionnalité de partage pour mardi” alors que je n’ai pas l’impression de mettre particulièrement la pression sur mes équipes, je me suis beaucoup interrogée sur cette facette alors inconnue de mon poste.

Aussi souvent que possible, j’organise des tests utilisateurs. Je n’ai pas de budget pour faire cela, donc je demande à des ami·e·s, à la famille. Chaque nouvelle personne rejoignant l’entreprise a droit à son test utilisateur. J’observe les gens utiliser nos produits, parfois en leur donnant un objectif à atteindre, et en leur demandant de verbaliser le plus de choses. J’en tire des points bloquants, cela confirme ou infirme des avis déjà remontés. Lorsque des modifications d’interface sont à faire, je les ajoute dans les Backlogs et je les priorise.

En ce moment, j’essaie de mettre en place des questionnaires en ligne pour évaluer les besoins, l’UX et l’ergonomie de mes produits. J’ai piqué plusieurs idées dans le livre de Carine Lallemand et Guillaume Gronier : Méthodes de design UX – 30 méthodes fondamentales pour concevoir et évaluer les systèmes interactifs. J’ai envie de faire remplir ces questionnaires à une trentaine de personnes qui utilisent les anciennes versions de nos web apps (en Flash), et à autant de personnes qui utilisent les nouvelles. Je croise les doigts pour que la conclusion soit positive. Dans ces questionnaires, j’ai également prévu de poser quelques questions plus personnelles aux utilisateurs, pour m’aider à créer des personas. C’est un peu tard mais je n’ai jamais été en contact direct avec nos utilisateurs finaux, je me dis que ça peut être un moyen d’en savoir un peu plus sur qui ils sont et quels sont leurs besoins.

Les seules personnes auxquelles j’ai accès qui utilisent réellement l’un de nos produits sont l’équipe de production, qui va de plus en plus utiliser le logiciel de création et d’enrichissement des documents. Lors de la phase de conception, j’avais observé l’une de ses membres pendant 2 jours, pour comprendre précisément son travail, ses contraintes et les cailloux dans la chaussures qu’elle se trimbalait. Maintenant que l’équipe va utiliser l’outil au quotidien, je vais pouvoir recueillir des avis et des demandes de personnes vraiment concernées.

À mon arrivée dans l’entreprise, j’ai également fait beaucoup d’analyse ergonomique de l’existant, et de recommandations (maintenant que presque tous travaillent sur les nouveaux produits, je ne le fais quasiment plus). Je rédigeais des documents, capture d’écran à l’appui, en expliquant ce qui n’allait pas, et en faisant des propositions d’améliorations.

Enfin, dès que j’ai le temps, et parfois même quand je ne l’ai pas, je fais de la veille. Ergo, UX, design, je lis beaucoup d’articles qui tournent sur Twitter ou publiés sur des blogs que je suis.

 

Hier j’ai lu un tweet rigolo :

Ma théorie : tu fais un “bullshit job” ou “faux métier” s’il n’existe pas de série Playmobil représentant ta profession.

Clairement, il y a peu de chance que Playmobil édite un jour une série correspondant à mon profil. En 2011, soit 3 ans avant que je cherche et trouve le poste que j’occupe actuellement, lors d’une formation sur l’après-thèse, la formatrice avait identifié en moi trois compétences primaires : la créativité, la communication et la coordination. Elle m’avait alors proposé comme projet professionnel “Chef de projet de conception”. Ça me semble d’un bon niveau en termes de “bullshit job”, mais finalement, est-ce que ce n’est pas le terme qui correspondrait le mieux à la palette de mes activités ?

Aidez-moi à régler cette crise existentielle, par pitié ! 🙂

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.