UX Fail : Suppression d’un document dans Google Drive

Scénario : J’ai créé un document par erreur et je souhaite le supprimer.

C’est un truc que je fais assez souvent, et qui systématiquement me fait tiquer. J’ai eu envie d’écrire un peu dessus pour comprendre pourquoi.

 

Capture d’écran 2018-12-12 à 15.00.29 copie.png
Page d’accueil de Google Drive

Je crée un nouveau document, parce que j’ai eu une idée de génie, j’arrive sur une page blanche et d’un coup je me dis « Ah ouais, nan c’est nul, laisse tomber ». Je veux donc supprimer ce document.

 

Capture d’écran 2018-12-12 à 12.00.11.png
Menu « Fichier » de Google Slides

Assez naturellement, depuis le document, je clique sur le menu « Fichier » et là, je cherche. À chaque fois, je scanne le menu à la recherche d’un intitulé qui commencerait par « Supprimer », mais ça serait trop simple évidemment. Heureusement, l’icône de poubelle m’aide à trouver relativement vite l’item qui m’intéresse : « Placer dans la corbeille ». Bon, ok, personnellement, je ne formule pas cette action comme ça dans ma tête mais je ne représente pas non plus tous les utilisateurs, et j’imagine que les designers de Google ont leurs raisons. D’ailleurs, ce libellé a probablement été testé et validé, n’est-ce-pas ?

Donc revenons-en à nos moutons : je souhaite supprimer ce document, je clique donc. Cette fenêtre modale s’affiche :

Capture d’écran 2018-12-12 à 12.01.43.png

Je lis à peine le message. Et oui, je suis ce qu’on appelle une « power-user » et j’ai l’habitude des interfaces : quand on veut supprimer quelque chose, on tombe toujours sur une fenêtre de confirmation. En plus, mon document est encore visible en arrière plan : preuve s’il en est qu’il n’est pas encore supprimé.

Je lis donc les options, à la recherche de celle que je m’attends à trouver. Quelque chose comme « Supprimer » ou bien « Confirmer la suppression » ou encore « Oui, je veux vraiment supprimer ce document ». Oh mais tiens ? Rien de ce genre ?

Je rebranche mon cerveau et (re)lis la modale plus attentivement.

Capture d’écran 2018-12-12 à 14.56.06.png
Modale à la suppression du document

Le premier bouton, celui mis en avant par sa couleur me dit : « Accéder à l’écran d’accueil Slides » . Hum, bof, non, ça n’est pas ce que je cherche à faire, moi je veux supprimer mon document. Alors, que dit le suivant ? « Sortir le fichier de la corbeille ». Ah, mince, ça n’est pas ça non plus !

Je remonte donc un peu pour lire le titre : ah tiens « Le fichier a été placé dans la corbeille ». Il est donc bien supprimé ! (Mais pourquoi diable est-il est encore sous mes yeux alors ?). Je veux donc conserver cet état et pour cela, je comprends enfin ce qu’on attends de moi : que je clique sur « Accéder à l’écran d’accueil Slides ». Ah oui ok. Bon, soit.

 

(Et après avoir rédigé cet article, je me rends compte que je radote, j’en avais déjà parlé il y a 9 mois dans Workflow de suppression; Google, fait quelque chose et corrige moi ça s’il te plait !)

Publicités

La méthode Kano

Quand j’ai l’opportunité d’utiliser une méthode UX que je n’ai jamais utilisé avant, c’est toujours la même chose : d’abord l’euphorie « Heeey, cette méthode semble répondre exactement à mon problème, ça va être trop bien ! », ensuite l’excitation « Hiiii, je vais pouvoir interroger des vrais gens, j’adore ça ! » ensuite la désillusion quand il faut vraiment s’y mettre : « Hein, mais attend, comment je suis supposer formuler ça de manière claire et concise ? ».

Bref, tout ça pour dire : voilà quelques notes à propos de la méthode Kano, ça pourra servir à mon moi futur ou à quelqu’un qui passe par là.

La méthode Kano

En quelques mots, le modèle de Kano permet d’évaluer l’impact d’une fonctionnalité sur la satisfaction de l’utilisateur.

Vous avez déjà entendu le dicton qui dit que “ Plus un produit propose de fonctionnalités, mieux c’est ! ”. Si oui, changez de boîte ! Si non, vous pouvez continuer à lire 😅.

Le modèle de Kano est une méthode qui permet de hiérarchiser les fonctionnalités pour ne garder que celles qui apportent du sens et de la satisfaction utilisateur.

Cette méthode propose donc de faire évaluer à des utilisateurs l’interêt d’un ensemble de fonctionnalités pour les classer en différentes catégories :

  • Les fonctionnalités indispensables : leur présence n’augmente pas la satisfaction utilisateur mais leur absence à un impact très négatif.
  • Les fonctionnalités performantes : ces fonctionnalités ont un lien direct avec la satisfaction utilisateur. Ainsi, leur présence augmente la satisfaction utilisateur quand leur absence diminue la satisfaction utilisateur.
  • Les fonctionnalités attractives : Les utilisateurs sont contents d’avoir cette fonctionnalité mais son absence n’engendre aucun problème.
  • Les fonctionnalités quelconques : elles n’apportent rien de positif ni négatif sur la satisfaction des utilisateurs.
  • Les fonctionnalités répulsives : Leur présence a un impact négatif sur la satisfaction des utilisateurs. Ils pourront être amenés à payer pour s’en débarrasser, ou à aller voir le produit concurrent.

Évidemment, le modèle de Kano est un modèle mouvant : une fonctionnalité peut changer de catégorie avec le temps. Par exemple, une fonctionnalité peut passer d’attractive à indispensable avec le temps et l’évolution de la concurrence. Enfin, cette catégorisation est aussi dépendante de l’utilisateur : il peut donc être intéressant de travailler sur des sous groupes, basés sur des personas par exemple.

En classant chaque fonctionnalité dans une catégorie, on peut alors construire une backlog en priorisant certaines catégories sur d’autres :

 

 

featureplotprioritization.png
Il est plus intéressant d’investir du temps à implémenter des fonctionnalités indépendantes que des fonctionnalités quelconques.

Quand utiliser le modèle de Kano

Il se trouve que depuis quelques mois, je note dans un coin des tas d’idées de fonctionnalités qui me sont remontées par des utilisateurs ou par des collègues en interne, mais sans trop savoir où donner de la tête. Certaines me parlent beaucoup, certaines ont l’air chouette, d’autres ne m’émeuvent pas mais parlent énormément à des utilisateurs.

La méthode de Kano me semblait donc la réponse idéale pour m’aider à faire le tri et pouvoir travailler de pair avec notre Product Owner pour construire une backlog cohérente pour notre produit.

Mettre en place le modèle de Kano

Avant toute chose, il est important de choisir les fonctionnalités que l’on va faire évaluer aux utilisateurs : dans le cadre de mon projet, j’ai rassemblé les retours venant du Services Clients, des influenceurs testant nos produits et enfin venant de notre équipe en interne. À partir de cette liste, j’ai d’abord écarté toutes les évolutions ou corrections de bug pour ne choisir que des fonctionnalités nouvelles, que j’ai ensuite limité à 10.

J’ai ensuite pu passer à la rédaction du questionnaire. Le principe de base du modèle de Kano est d’interroger l’utilisateur sur l’absence puis la présence de la fonctionnalité :

Que ressentez-vous si la fonctionnalité est présente ?

  • Je suis content·e.
  • C’est normal (“Je m’y attendais”).
  • Je suis neutre (“Et alors?”).
  • Je fais avec (“J’ai pas vraiment le choix…”).
  • Je suis mécontent·e.

Que ressentez-vous si la fonctionnalité est absente ?

  • Je suis content·e.
  • C’est normal (“Je m’y attendais”).
  • Je suis neutre (“Et alors?”).
  • Je fais avec (“J’ai pas vraiment le choix…”).
  • Je suis mécontent·e.

Bon, ça c’est la théorie. Car dans la pratique, j’ai bien galéré à écrire un questionnaire qui aie du sens. Ici, les tests en interne m’ont été très utile pour valider la bonne compréhension de mon questionnaire. En vrac, voici quelques questions que je me suis posées :

  • À quel point faut-il rentrer dans les détails pour présenter une fonctionnalité ? Est-ce qu’un titre est suffisamment clair ou faut-il décrire la fonctionnalité en une phrase ou plus ?
  • Comment formuler les questions ? Dans mon cas, le produit existe déjà. La question « Que ressentez-vous si la fonctionnalité est absente ? » n’a pas de sens (c’est le cas aujourd’hui mais on envisage de la rajouter). Devrais-je plutôt dire « Que ressentiriez-vous si la fonctionnalité était présente ? » et « Que ressentez-vous à propos du manque de cette fonctionnalité ? ».
  • Les questions ne seraient-elle pas plus claires si les fonctionnalités étaient rappelées dans l’intitulé des questions ?
  • Mais au fait, à quel temps conjuguer mes questions : « Si vous pouvez visualiser vos statistiques de lecture, que ressentez-vous ? » ou plutôt « Si vous pouviez visualiser vos statistiques de lecture, que ressentiriez-vous ? » ?
  • Et les réponses proposées, on en parle ? Certains personnes en interne m’ont remonté ne pas bien comprendre la nuance entre « C’est normal » et « Je fais avec ». Faut-il rajouter une explication ? comme par exemple « C’est normal, je m’y attendais”.

Finalement, après mures réflexions et nombreux tests, j’ai choisi de rédiger mon questionnaire de cette manière :

kano-extrait-questionnaire.png
Exemple de question sur la fonctionnalité des statistiques de lecture.

J’ai donc arbitré de la manière suivante :

  • Re-décrire la fonctionnalité dans la question, pour plus de clarté :  « Si vous pouvez visualiser vos statistiques de lecture, que ressentez-vous ? » et « Si vous n’avez pas d’informations sur vos statistiques de lecture, que ressentez-vous ? ».
  • Simplifier au maximum les réponses proposées, même si certaines réponses sont parfois mal comprises (c’est un problème connu qui ne semble pas déranger l’analyse des résultats d’après Daniel Zacarias qui le mentionne dans son guide complet).
  • Préférer le présent au subjonctif.
  • Utiliser l’écriture inclusive, parce que vive l’inclusion.

Analyser les résultats

Super, le questionnaire est écrit, les utilisateurs identifiés et prêt à être contactés ! Il n’y a plus qu’à envoyer tout ça, et analyser les résultats.

J’aurais aimé trouver un outil équivalent à kano.plus en français, mais j’ai fait chou blanc. Je suis tombée sur le Kano Model Calculator through Google Sheets mais j’ai abandonné l’idée de le tester : j’ai toujours du mal avec l’idée d’autoriser des obscures applications trouvées sur Internet à accéder à tout mon Google Drive 🤔.

J’ai donc retroussé mes manches pour envoyer le questionnaire par mes propres moyens (ça c’était facile, les outils de questionnaires en ligne ne manquent pas) puis pour analyser moi-même les résultats (et là, ce fut une autre paire de manche !). Mais rien de tel pour mieux comprendre les résultats, non ?

categorisation-modele-kano
Tableau de catégorisation d’une fonctionnalité

 

En m’appuyant sur le fichier Excel conçu par Daniel Zacarias (voir le guide complet) puis en bidouillant entre Numbers et Libre Office, j’ai pu réussir à faire fonctionner les formules permettant de calculer le score de chacune des fonctionnalités.

kano-analyse-continue.png
Ça ne paraît pas impressionnant comme ça mais j’ai passé plusieurs heures à calculer ces scores.

Ensuite, oh joie, il n’y avait plus qu’à placer chacune de mes fonctionnalités sur un graphique pour faire ressortir les catégorisations :

Kano-resultat
Résultat de l’étude de Kano sur 9 fonctionnalités

Sur ce graphique (anonymisé pour ce blog), vous noterez que :

  • Aucune fonctionnalité indispensable n’est dans notre scope : c’est plutôt bon signe, sachant que notre produit est en ligne depuis un moment déjà !
  • Plusieurs fonctionnalités performantes et attractives en vue : youpi, ce sont donc celles là que nous avons tout intérêt à pousser vers le haut de la backlog !
  • Une fonctionnalité jugée comme répulsive est identifiée : Oups ! Cette fonctionnalité là devra nécessiter de sérieux arguments de la part de nos équipes marketing pour valoir le coût (aussi bien coût de développement que coût en satisfaction utilisateur !)

Bon, et bien maintenant, il n’y a plus qu’à implémenter tout ça !

Les ressources qui m’ont bien aidées

View story at Medium.com

Dark-pattern : Comment inciter l’utilisateur à donner ses données personnelles ?

 

Sauf à ne plus cliquer sur aucun lien, les gros encarts pour « respecter votre vie privée » sur tous les sites webs utilisant des cookies ne vous auront pas échappés. Voici un exemple, chez Slate.fr par exemple, dont je lis souvent les articles (principalement à cause de la fabuleuse newsletter de Titiou).

Capture d’écran 2018-11-16 à 09.31.36.png
Sur slate.fr, le respect de ma vie privée est « leur priorité » #onYCroit

Sur cette page, j’ai deux choix : cliquer sur « J’accepte » ou cliquer sur « Afficher toutes les utilisations prévues ».

Personnellement, je n’accepte pas que Slate utilise des cookies pour « personnaliser les contenus et les publicités ». Il semblerait donc que je n’aie pas le choix : je dois choisir « Afficher les utilisations prévues ».

Capture d’écran 2018-11-16 à 09.35.26.png
Slate.fr n’a pas moins de 10 autorisations prévues pour utiliser mes données personnelles.

Là, (bonne ?) surprise : toutes les autorisations demandées semblent déjà désactivées. Comme j’ai la flemme de scroller pour le vérifier, généralement, je clique sur « Tout refuser » puis sur « Enregistrer et quitter ».

Ça y est, miracle, après 3 clics et 30 secondes, j’ai enfin accès à l’article que je souhaite lire ! Enfin… jusqu’à ma prochaine visite…

Mais à chaque fois que je fais cette procédure (au moins une fois par jour donc, un peu comme Stéphanie Walter), je suis un peu frustrée : déjà parce que je dois refaire (éternellement ??) la même manipulation, et puis parce que chaque fois que je constate que les cookies semblent désactivés par défaut, je me demande si j’aurais pu cliquer tout simplement sur « J’accepte » sur le premier écran ? (La réponse est : évidemment non, en faisant ça, j’accepterais le dépot des cookies).

Pourtant, la solution utilisée (Quantcast Choice) offre bien une option pour que le bouton « Refuser tout » soit affichée au même niveau que le bouton « J’accepte », mais beaucoup d’éditeurs ne l’activent pas… Ils attendent la première jurisprudence pour se mettre en conformité… (Merci Julien Lafont pour l’information).

Quantcast.jpg
Interface administrateur de Quantcast Choice

Je découvre ainsi que :

  • Il existe bien une option « Show reject button ». POURQUOI PERSONNE NE L’ACTIVE ?
  • Il existe aussi une option permettant de choisir tous les combiens de jours on (re)demande aux utilisateurs récalcitrants de partager leurs informations personnelles. (Probablement en espérant que si on me le demande chaque jour, je vais finir par capituler…)

 

Bref, vous avez absolument envie de fliquer vos utilisateurs ? Suivez l’exemple de Quantcast… Mais légèrement hors la loi aussi, car dans la théorie, il devrait être aussi simple d’accepter le consentement que de le refuser, et aujourd’hui ça n’est clairement pas le cas…

En attendant, l’extension Firefox QookieFix peut vous sauver en faisant apparaitre le fameux bouton « Je refuse » sur les sites intégrant la solution de consentement de Quantcast (merci à Mathieu pour l’information !).

 

 

 

De dev à UX designer : reconversion d’une convertie

Cet article (qui prévoit d’être long) est un transcript de la conférence que j’ai donné à BlendWebMix à Lyon, le 25 octobre 2018.

De dev à l'UX _ reconversion d'une convertie

Dans ce talk, De dev à l’UX : reconversion d’une convertie, je parle un petit peu de moi-ma vie-mon oeuvre (pardon d’avance donc), puis de ce que j’ai mis en place dans mon entreprise pour initier une démarche un peu plus user centrée. Vous pouvez visionner les slides ici, regarder la vidéo, ou bien lire la suite de cet article.

Où je parle déjà de moi

Déjà, je vais me présenter un petit peu :

De dev à l'UX _ reconversion d'une convertie (1)

Commençons par vous décrire un peu qui j’étais il y a 10 ans (à part plus jeune). En 2008, j’étais plutôt comme ça :

  • Je travaillais sur Linux ; et faisais longuement la morale à tous mes proches osant utiliser Windows, ou, pire, Mac (heureusement, comme j’étais étudiante à l’époque, tous mes amis étaient pauvre, et très peu étaient sur Mac).
  • J’utilisais exclusivement des logiciels libres et open-source : si je ne trouvais pas un outil open-source me permettant de faire ce que je voulais, je ne le faisais pas.
  • Je suivais 40 heures de cours d’informatique par semaine (« Tu verras le rythme de la fac, c’est tranquille… ! » Tu parles !) et puis sur mon temps libre (le matin, le midi, le soir ou la nuit) une vingtaine d’heures par semaine sur un projet open-source (coucou Dotclear ♥).
  • Je préférais la ligne de commande aux interfaces graphiques : c’est plus rapide, automatisable, cronable !

Bref, vous pouvez le dire, j’étais ce qu’on appelle communément une NERD (et très fière de l’être).

Aujourd’hui, je suis plutôt comme ça :

De dev à l'UX _ reconversion d'une convertie (2)

  • Je travaille sur Mac.
  • J’utilise 23 outils SAAS différents (dont zéro logiciels libres).
  • Je ne code plus (principalement car je n’arrive pas à retenir le raccourci clavier pour faire un [ ou une { sur Mac).
  • Je passe mes journées à faire des slides ou des réunions.

Naturellement, j’imagine que des questions vous brûlent les lèvres : Que s’est-il passé ? Comment en suis-je arrivée là ? Ai-je aussi renié mes parents et ma patrie ?

Pour répondre à ces questions tout à fait légitimes, je vais tenter de remonter dans le temps.

Où l’on essaye de retrouver quand tout à basculé

En 2008, il y a 10 ans donc, j’étais étudiante : j’avais du temps et l’envie de tout découvrir. Le combo parfait pour participer activement à un projet open-source : Dotclear. Je touchais un peu à tout : code, documentation, forum d’entraide, web design, etc Et ce fut aussi et surtout l’occasion de rencontrer et travailler avec plein de gens hyper chouette, dont la fabuleuse Laurence Vagner 🦄 (alias @hellgy).

En 2010, Laurence m’a envoyé un email qui a changé ma vie :

mail-pw-hellgy

Elle proposait de m’inviter à Paris Web, une conférence qui me faisait vraiment de l’oeil, mais dont l’entrée coûtait l’équivalent de 5 mois de repas au RU (le repas au resto universitaire était mon unité de mesure de base à cette époque). Autrement dit, cette invitation était vraiment une opportunité fabuleuse et unique pour moi !

Ni une ni deux, j’ai accepté en sautant de joie, et quelques mois plus tard, j’ai séché deux jours de cours pour débarquer, jeune, fraîche et pimpante, à Paris Web. Et ce fut une révélation !

Déjà, je suis tombée en amour pour Amélie Boucher. Cette année là, elle proposait une conférence qui s’intitulait sobrement Internautes sous surveillance : retours de la réalité pour un monde meilleur. C’est une révolution pour moi : elle explique qu’on peut observer et interroger des utilisateurs ! Pour améliorer ses produits ! C’est passionnant !! C’est un nouveau monde qui s’ouvre à moi !!!

Ainsi, au fil des conférences, je découvre les termes design, ux et ergonomie. Des aspects totalement absent de ma formation très technique, mais qui me parlent vraiment.

Et puis j’entends aussi des mots comme accessibilité, bonnes pratiques ou standards. Là encore, c’est une manière d’aborder les choses qu’on ne m’a pas du tout appris pendant mes études (Faire les choses bien, mais pourquoi faire ?). Cela me donne de perspectives inédites pour ma vie professionnelle à venir.

Où les années passent…

En 2011, je finis mes études et je continue mon chemin de développeuse en m’orientant vers le web. Coïncidence (ou magie du networking), c’est un cofondateur de Paris-Web, Éric Daspet, qui m’embauche chez TEA.

En 2013, (et les années qui suivent), je continue d’assister (et même de donner) des conférences, en prenant soin de choisir des conférences mixtes : j’évite les événements purement technique comme le PHP Tour pour me focaliser sur des événements mixtes : Paris Web, MiXiT, Sud Web… Ces conférences sont toujours pour moi une bouffée d’air frais : j’évite soigneusement les talks techniques pour plutôt aller voir ce qui se passe du côté du design et de l’UX, et chaque fois, je suis passionnée.

En 2014, lors d’un entretien annuel, à la question « Où tu te vois dans 5 à 10 ans ? », je verbalise pour la première fois mon envie de (un jour, éventuellement, peut être) quitter le développement pour me diriger vers de l’UX.

Couverture du livre Undercover User Experience DesignEn 2015, je (re)lis Undercover User Experience Design : Learn how to do great UX work with tiny budgets, no time and limited support (salut le titre le plus long mais le plus parlant du monde). Ça me motive à essayer de mettre des choses en place, avec les moyens du bord (des tests utilisateurs par exemple). Ce sont des petites actions mais toujours immensément gratifiantes pour moi.

En 2016, je commence à me renseigner sur les formations pour devenir UX designer. Je mets de côté les cursus basés sur les sciences humaines (sociologie ou psychologie) : c’est un domaine où j’ai tout à apprendre mais je n’ai pas l’énergie de reprendre 3 à 5 ans d’études. Je trouve d’autres formations plutôt orientées web mais elles ne me conviennent pas non plus : cela fait 5 ans que je travaille dans le monde du web, je n’ai pas besoin de tout apprendre depuis les bases. Et puis, surtout, je suis bloquée par la peur : peur de quitter un CDI confortable (développeuse, c’est la belle vie quand même niveau marché du travail !), peur d’investir du temps et de l’argent dans une formation mais de ne pas trouver de travail ensuite… Bref, je laisse le temps passer.

En 2017, c’est finalement mon entreprise, TEA, qui m’apporte la réponse : ma hiérarchie réalise que nous avons (grandement) besoin de nous améliorer sur les questions d’expérience utilisateur. Comme ça fait quelques mois/années que je saoule toute la boîte avec ça manifeste un interêt pour la chose, mes chefs me demandent : « Est-ce ce que ça t’intéresse de t’en occuper à temps plein ? »

De dev à l'UX _ reconversion d'une convertie
Petit résumé de ce qui se passe dans ma tête
  • D’abord, je m’auto-dépite : « Se reconvertir au sein même de mon entreprise ? C’est du génie ! Mais pourquoi n’y ai-je pas pensé moi même ??!! »
  • Ensuite, je réfléchis un peu à la question et j’ai peur : « Mais ils sont fous ! J’y connais rien en UX moi, j’ai juste lu 2-3 trucs par ci par là… »
  • Et puis, majoritairement, je saute et je danse de joie : « Olala mais c’est le job de mes rêves, ça va être trop bien, c’est une évidence ! »

Où je deviens UX designer

Évidemment, je dis oui. Alors, tout va très vite : on annonce la nouvelle à l’équipe (tout le monde est plutôt content car c’est vraiment un poste qui manquait) et la semaine d’après, je commence ma nouvelle mission. Je suis UX Designer !

Yay ! Super ! Bon, mais…. je fais quoi concrètement ?

De dev à l'UX _ reconversion d'une convertie (4)

Autant être honnête, les premières semaines ont été… particulières ! Je me suis laissée portée : dès le départ, mes collègues (à tous les niveaux, qu’ils soient des équipes marketing ou dev) m’ont impliquée dans de nombreuses discussions (je vous l’ai dit : nous avions vraiment un manque à ce niveau). Comme ils avaient l’air de penser que je pouvais apporter des solutions à leurs questions, j’ai fait comme si je savais comment leur apporter une réponse. J’ai bricolé des trucs ; et puis, personne ne se plaignant de mon travail, j’ai commencé à prendre confiance en moi, à y voir plus clair.

Mais très vite, la nécessité de structurer tout ça est apparue.

Où je me construit une base de référence

De dev à l'UX _ reconversion d'une convertie.png

J’ai d’abord eu besoin de faire un état des lieux de ce que je savais. Après 10 ans de veille légère, j’ai repris toutes les conférences que j’avais vu et les livres que j’avais lu pour faire un état des lieux. J’ai commencé à rencontrer des membres de ma nouvelle communauté et j’ai entreprit une veille plus active grâce notamment à des newsletters et à Twitter.

Tout cela m’a permis de me constituer une base de référence de méthodes à réutiliser. Ainsi, quand on me présente un problème, je peux très vite trouver les ressources me permettant de le résoudre, même si je n’ai jamais utilisé cette méthode avant. J’avais listé les outils qui m’ont été très utiles au début dans cet article : Ressources pour débuter en UX design.

Où je me rends compte de la diversité des concepts engagés

Que ce soit en interne, ou en parlant à mes amis ou à mes proches, souvent, j’ai dû répondre à la question suivante : « Mais au fait, c’est quoi ton nouveau métier ? ». Telle une bonne élève, j’ai appris à réciter une définition toute faite : « Je travaille à penser et concevoir des services et produits proposant la meilleure expérience utilisateur possible. » Mais je dois l’admettre, ça reste fort peu compréhensible pour le commun des mortels. Ceux et celles n’étant pas dans le web bloquent aux termes « service » et « produit ». Les autres s’arrêtent à l’expression « expérience utilisateur ». Qu’est-ce que ça désigne au juste ?

Et bien, il faut admettre que ça n’est pas si simple car derrière l’expérience utilisateur se cache effectivement BEAUCOUP de concepts différents.

De dev à l'UX _ reconversion d'une convertie (1)

Pour pouvoir répondre aux questions : « Que veut faire cette utilisatrice ? Pourquoi ? Et comment ? », un certain nombre de critères doivent être pris en compte : de la définition des fonctionnalités en passant par des notions de marketing et d’information de l’architecture. Je me rends compte par exemple que :

  • Il va falloir que j’arrête de considérer les termes « marketing » et « analyse business » comme des gros mots (désolé, habitude de développeuse…), car je réalise vite que cela joue effectivement beaucoup sur l’expérience utilisateur.
  • Je vais devoir faire un petit état des lieux de ce que je sais, mais surtout ce que j’ai besoin d’apprendre.

Où j’évalue mes compétences

Pour faire un premier bilan, je me suis appuyée sur le modèle de compétences UX en T proposé par Raphaël Yharrassary.

Tableau du modèle en T de compétences UX
Compétences UX et modèle en T

Sur l’axe horizontal, Raphaël a listé toutes les grandes familles de compétences indispensables en UX. Sur l’axe vertical, de bas en haut, on passe de compétences les plus basiques et des compétences plus spécialisées.

De dev à l'UX _ reconversion d'une convertie (10)
Après 6 ans de dev, les compétences techniques, ça me connait !

Si l’on regarde la colonne Technique (acquise de par mon background de développeuse) l’idée n’est évidemment pas de dire qu’un·e UX designer doit savoir mettre en place une infrastructure ou une architecture système mais plutôt de savoir que ça existe et que ça influe sur l’expérience utilisateur.

Ainsi, pour se construire une base de compétences pertinente, un·e UX designer doit d’abord avoir des connaissances « de bases » sur toutes les grandes familles, avant de se spécialiser dans certains domaines selon les affinités ou les besoins de l’entreprise.

De dev à l'UX _ reconversion d'une convertie (3)

Ce modèle en T est donc très utile pour faire un bilan sur les compétences que l’on a (ou a acquérir), mais aussi dans le cas d’une équipe de plusieurs UX designers pour voir comment les profils se complètent.

Où j’évalue l’étendue de ma mission

Pour mieux cerner les bornes de ma mission d’UX Designer, je me suis appuyée sur le travail de Jasper Stephenson sur les différents rôles et métiers du design UX selon l’étape du cycle de travail .

D’abord, un petit rappel sur le cycle de vie d’un projet d’un point de vue de designer : le travail se découpe en plusieurs phases, sur lesquelles on peut boucler :

Cycle de vie d'un projet vue par un UX designer

  • La phase de recherche, auprès d’utilisateurs par exemple.
  • La phase de synthèse et idéation, où l’on génère des idées.
  • La phase de prototypes et design, où l’on conceptualise une solution.
  • La phase d’implémentation, où la solution voit le jour.

En tant que développeuse, mon métier intervenait plutôt en fin de cette chaîne :Web designer et Dev front end interviennent en fin de chaîne

  • Web designer : s’occupe du design et de l’implémentation
  • Développeuse front end : se concentre sur l’implémentation.

Mais, en amont de ces phases, différents métiers de l’UX existent :

De dev à l'UX _ reconversion d'une convertie (1)

  • L’UX Designer, qui intervient sur toute la chaîne.
  • L’UX Researcher, qui se spécialise dans la phase de recherche et de synthèse.
  • L’UI Designer, qui se concentre sur les interfaces.
  • L’UX Writer, qui est encore plus spécialisé puisqu’iel s’occupe exclusivement de la copie (micro ou macro, j’en parle un peu dans La micro-copie : de l’importance du choix des mots)

Et puis, il y a le cas particulier de l’UX Designer « Team of one ». Quand, comme moi, on travaille seul·e dans son équipe, la situation demande d’avoir des compétences particulières :

  • Accepter d’avoir un profil généraliste : on touche à tout, mais pas avant autant d’expertise qu’une personne spécialisée.
  • Savoir évangéliser : toute la démarche UX repose sur nos épaules. Il faut arriver à motiver les autres corps de métiers pour avancer dans la même direction.
  • Être ingénieuse : avec du temps et des ressources limitées, il faut savoir adapter parfois les méthodes.
  • Et surtout audodidacte : je ne peux pas m’appuyer sur mes collègues pour progresser.

Spectre des métiers de l'UX selon les phases du cycle du travail

Enfin, il est toujours bon de préciser que les licornes n’existent pas : aborder la chaîne de bout en bout est extrêmement compliqué. Je m’en rends compte maintenant : quand j’étais développeuse mais que je tentais de mettre en place des améliorations UX, malgré toute ma bonne volonté, je ne pouvais pas avoir le même recul qu’aujourd’hui. Le fait de savoir et de déjà réfléchir à comment implémenter et coder ma solution me limitait grandement dans ma réflexion. J’ai mis du temps à quitter cet état d’esprit « réflexion de développeur » mais ça m’est indispensable pour proposer aujourd’hui des solutions vraiment centrées sur l’utilisateur.

Où j’évalue le degré de maturité de mon entreprise

Une fois que les tenants et aboutissants de ma mission étaient plus clairs pour nous, j’ai pu mettre en place des choses plus structurées chez TEA.

Je ne l’ai pas mentionné avant, mais je suis arrivée chez TEA au tout début de l’entreprise, quand elle n’avait que quelques mois. Je l’ai donc vu évoluer (en même temps que moi), à tous les niveaux.

Les premières années, l’UX n’était pas un mot de notre vocabulaire, et donc pas un problème : l’UX chez nous était non reconnue. Nous, développeuses et développeurs, créions nous-même les interfaces, avec tous les problèmes que cela peut causer.

Tableau de résumé des différents degrés de maturité UX d'une entreprise

Au fur et à mesure de mes révélations (mais aussi du travail d’autres collègues), l’UX est devenue une question ponctuelle : nous avions connaissance des bonnes pratiques. Hélas, cela ne suffit pas : si aucune méthode n’est mise en place de manière systématique et si les utilisateurs ne sont pas impliqués régulièrement, les problématiques d’UX ne sont pas vraiment abordées dans leur ensemble.

Nous avons atteint le degré de maturité où l’UX est devenue considérée quand TEA a choisi d’investir, via du personnel dédié donc (moi). J’ai ainsi pu commencer à mettre en place des méthodes, sur certains projets.

Depuis un an et demi que j’exerce ce poste, les choses évoluent, j’interviens à plusieurs niveaux du cycle de vie d’un projet. On peut dire que l’UX est gérée.

Nous ne sommes pas encore à une phase où l’UX serait intégrée, ni même institutionalisée. En effet, il ne suffit pas de dire que l’UX doit être au coeur de la stratégie de l’entreprise pour qu’elle le soit vraiment : cela demande du temps et de l’investissement, que les changements se fassent et que l’organisation se développe de manière structurée et pérenne. Mais, chaque jour, on y travaille un peu plus 🙂

Où je m’adapte à mes interlocuteurs

Au fil du temps, j’ai vite appris à identifier mes interlocuteurs, mais aussi à adapter mon discours pour obtenir les réponses les plus pertinentes.

De dev à l'UX _ reconversion d'une convertie (3)

D’abord en amont du projet, puis tout au long de son cycle de vie, je commence par m’entretenir avec les décideurs (ma hiérarchie, ou nos clients, selon les projets). L’identification des besoins nécessite souvent de poser beaucoup de questions.

Évidemment, ces besoins sont toujours croisés avec les besoins réels des utilisateurs. Il existe de nombreuses manières de récolter du feedback : par le biais des utilisatrices et utilisateurs eux même, évidemment ; mais aussi par des biais détournés, via l’équipe du service client, par les réseaux sociaux (commentaires…) mais aussi en analysant l’utilisation de nos produits.

Enfin, discuter avec l’équipe technique est indispensable, notamment pour identifier les contraintes techniques au problème donné.

Pour chacun de ces interlocuteurs, j’adapte mon discours :

  • Avec les décideurs : je suis souvent dans une démarche de convaincre. Le storytelling est devenue ma manière privilégiée de communiquer, avec l’appui de maquette et prototypes basse ou haute résolution selon l’avancée du projet.
  • Avec les équipes techniques : je privilégie la mise en place d’outils et de canaux de communication efficaces.
  • Avec les utilisateurs : j’adapte radicalement mon discours puisque j’ai appris à… me taire pour mieux écouter, lors d’entretiens téléphoniques ou de visu.

Où j’ai gardé mes supers pouvoirs

Depuis bientôt deux ans que j’ai changé de métier, une question qui revient souvent c’est « Mais ça ne te manque pas trop, le métier de dev ? ». Et bien… non, ça va merci ☺️ .

En tant que développeuse, ce que j’aimais particulièrement, c’était avoir l’étincelle et l’illumination de génie quand j’arrivais à résoudre mon problème avec une solution élégante techniquement, pragmatique, et évolutive.

De ce point de vue là, ça n’a pas tellement changé : je cherche toujours une solution qui soit élégante, pragmatique et évolutive, pour répondre aux besoins de l’utilisateurs, aux contraintes techniques et aux besoins des décideurs.

De dev à l'UX _ reconversion d'une convertie.png

Et puis, de mon ancien métier, j’ai gardé quelques super pouvoirs :

De dev à l'UX _ reconversion d'une convertie (1).png

  • Je sais faire des requêtes SQL, toujours pratique pour obtenir en quelques minutes des réponses à des questions bizarre « Mais au fait, est-ce que cette fonctionnalité est utilisée comme ceci ou comme cela ? ».
  • Je sais manipuler les langages HTML/CSS/JS : pratique pour faire des prototypes, manipuler directement le code source d’une page ou communiquer avec les devs.
  • Et surtout, surtout, surtout, je sais lire la documentation : je n’ai pas besoin de tout savoir, j’ai juste besoin de savoir où je peux trouver la réponse à ma question, et tout ira bien pour moi. Ouf, voilà qui est rassurant !

Où je tente une conclusion

Voilà donc la fin de ce retour d’expérience : je n’ai pas vraiment de conclusion, car je ne sais pas si on peut tirer de généralités de mon expérience personnelle ; mais surtout parce que mon chemin est loin d’être fini : je continue d’apprendre chaque jour.

Mais quand même, juste un truc : si vous en avez l’occasion, invitez des jeunes à des conférences, c’est l’occasion de planter des graines qui pourront germer dans le futur 🙂

 

À celles et ceux qui ont lu jusqu’au bout, merci ! Vous pouvez aussi retrouver les slides sur Slideshare.

Se mettre aux sketchnotes

C’est Laurence qui m’a donné envie de me mettre aux sketchnotes l’année dernière. J’avais alors essayé pendant des conférences du MiXiT 2017 (mais si, tu sais, la conférence lyonnaise avec des crêpes et du coeur).

 

Ce n’était pas fameux fameux mais j’avais quand même bien progressé entre le début et la fin de la journée.

Et puis, en revenant, j’ai complètement arrêté de pratiquer. Jusqu’à ce que Raphaël en parle pour des entretiens utilisateurs. C’était l’élan de motivation qu’il me fallait pour m’y remettre un peu plus sérieusement. J’ai d’abord investi dans ce chouette livre :

initiation_sketchnote.jpg
Initiation au sketchnote, de Mike Rohde (Eyrolles)

Et depuis, je m’entraîne régulièrement :

 

Je sketchnote un peu pour tout (conférences, formations, compte rendu de réunion diverses et variées), et j’y vois énormément d’avantages et de bienfaits :

  • Meilleure concentration : Pendant les réunions, mon esprit ET mon corps travaillent, difficile d’être distraite donc.
  • Meilleur esprit de synthèse : Je suis forcée d’écouter, d’analyser et de synthétiser à la volée ce que j’entend pendant une conférence ou une formation.
  • Sortir de ma zone de confort : je n’avais jamais pensé que j’étais capable de dessiner ; en fait, je n’avais jamais essayé. Même si je reste très « texte » sur mes sketchnotes, j’essaye maintenant d’intégrer des petits dessins : ils sont imparfaits mais ont le mérite d’exister. Et je vois bien que je progresse donc bye bye les « j’y arriverais pas ». Yay me 🤗.
  • Être créative : entre deux idées importantes, je peux m’occuper des titres et gribouiller des « décors », c’est aussi apaisant que de dessiner des doodles !
  • Meilleure capacité d’écoute : je ne connais généralement pas le plan de ce qui va être raconté, mais je dois quand même l’anticiper pour composer un sketchnote compréhensible : ça me force à écouter encore plus mon interlocuteur.

Jusque là, je faisais ça dans mon coin, mais je vais commencer à essayer de les partager de manière plus systématiques (à mes collègues après une réunion, ou aux organisateurs après une conférence). Mais pour cela, je dois encore améliorer quelques points :

  • Ça serait bien que j’investisse dans des feuilles blanches plutôt que des feuilles à carreaux 😅.
  • Si je pouvais aussi trouver une combinaison encre/papier qui ne bave pas : je suis gauchère et c’est une plaie quand je passe mon poignet sur un texte pas encore sec 😭.
  • Et puis apprendre à scanner correctement (ou retravailler sur photoshop mes sketchs après coup ?)…
  • Et pratiquer, pratiquer, pratiquer !

 

La micro-copie : de l’importance du choix des mots

S’il y avait bien un sujet que je n’avais pas « anticipé » en devenant UX designer, c’est à quel point j’allais apprendre à écrire. Naïvement, je pensais avant que l’UX design tournait principalement autour des interfaces. Mais j’ai vite découvert, qu’en plus, venait le bonheur de s’arracher les cheveux pendant 4 heures sur un texte (pour qu’au final, le résultat paraisse évident) !

Il existe des milliers de façons de présenter une même chose à l’utilisateur. Mais comment la formuler ? Quels mots choisir ? Quel ton utiliser ? Comment présenter le problème ou l’information ?

  • Je me suis par exemple posé des questions parfois très bête, sur deux mots : faut-il écrire « Mes ebooks » ou « Vos ebooks » ? Et je ne suis pas la seule à me poser ce genre de questions : Alla Kholmatova en parle dans son retour d’expérience Making personal pronouns consistent in the FutureLearn user interface.
  • Je suis restée des heures devant un message d’erreur : comment expliquer à un utilisateur que dans certains cas très spécifiques, nous ne pouvons pas traiter sa requête, et qu’il doit faire une action manuelle et contraignante de son côté, le tout, sans le faire fuire (ni passer pour des branques) ? J’espère au final avoir réussi à appliquer les bonnes pratiques d’un bon message d’erreur : dans The art of the error message, Marina Posniak préconise qu’il soit explicatif, avec le bon ton, et qu’il donne une porte de sortie à l’utilisateur.
  • Inspirée par mes lectures sur le Design Emotionnel, je me suis posée la question d’intégrer plus d’humain, et d’humour, dans certains de nos produits. J’ai trouvé que Connecting With Users: Incorporating Humor In Web Design était un article très complet sur les possibilités qui s’offraient à moi.
  • Quand je bloque trop longtemps sur la manière de présenter une information, je retourne lire Stop searching for the perfect word pour penser à des alternatives.

Bref, au fil de mes réflexions, j’ai beaucoup appris sur la micro-copie : l’art d’écrire des petits textes ou messages, qui passent presque inaperçus, mais qui ont un rôle à part entière dans la communication avec l’utilisateur pour convaincre, informer, rassurer éduquer ou simplement faire sourire l’utilisateur.

Je me suis rendue compte qu’il n’existait (à ma connaissance) aucun article en français sur le sujet ; par contre, il y en a pléthore en anglais. Je ne vais pas les traduire ou refaire le job (la flemme 😅) alors je balance des liens en vrac :

Mais quand même, pour apporter un peu de contenu frenchy (et pour changer des exemples de MailChimp ou Slack des articles cités ci-dessus), voici quelques captures d’écrans françaises pour illustrer le principe de la micro-copie ; merci à CozyCloud pour ce beau travail !

Capture d’écran 2018-03-16 à 14.41.40.png
CozyCloud rappellent leurs avantages en quelques mots juste en dessous du CTA principal de leur home
Capture d’écran 2018-03-16 à 14.42.01.png
Tout en bas de la page, CozyCloud fait un petit tacle gentil à nos amis de la Silicon Valley.
Capture d’écran 2018-03-16 à 14.51.55.png
Dans son parcours de création de compte, CozyCloud explique à quoi sert l’URL que l’utilisateur doit créer, et pourquoi elle est importante. En plus en utilisant l’écriture inclusive ❤️.
Capture d’écran 2018-03-16 à 14.54.12.png
Leur travail est tout particulièrement excellent au niveau de la présentation des CGU.

 

Je m’arrête là avant de screenshoter tout le site et je termine mon article avec deux derniers liens sur le sujet :  d’abord une checkliste, pensée par Ryan Cordell, à utiliser avant de rajouter de nouveaux textes : A 6-point microcopy checklist for product teams without UX writers. Est-ce que ce message est utile ? Succinct ? Transparent dans ses explications ? Humain ? Intégré au design ? UTILE ?

Et puis, pour continuer à être inspiré, n’hésitez pas à suivre le compte @tinywordsmatter sur Twitter !

Les Smart Reply de Gmail, plus flippantes que pratiques

Google n’en est pas à sa première fonctionnalité aussi flippante que pratique… La dernière en date ? Ces boutons « réponse rapide » en bas des emails dans la vue mobile de Gmail, qui apprennent à parler comme nous, grâce au machine learning.

Je me demandais comment ça marchait, j’ai vite trouvé que la fonctionnalité s’appelle Smart Reply, qu’elle a été annoncée en 2017 à la conférence Google I/O. Puis mon niveau de flippe a triplé en lisant plus de détails sur l’algorithme. (Mais c’est peut être juste moi qui ne me rend pas assez compte de ce qu’on est capable de faire aujourd’hui…)

Voici un petit aperçu de réponses automatiques tirées de ma boîte personnelle, et une étude de la pertinence des réponses proposées :

Capture d’écran 2018-03-12 à 22.39.51.png
Pertinence 8/10 : le ton est juste, c’était pour répondre à une blague (j’espère que l’IA l’a trouvé drôle)
Capture d’écran 2018-03-12 à 22.40.01.png
Pertinence 0/10 : j’étais en copie d’une demande de devis, ce n’était pas à moi d’y répondre.
Capture d_écran 2018-03-12 à 22.40.11
Pertinence 5/10 : C’était bien une photo, mais bon, c’était un escalier, rien de transcendant non plus.
Capture d_écran 2018-03-12 à 22.40.22
Pertinence : 3/10. Mon frère me disait « Merci », pourquoi diable je lui répondrais EN MAJUSCULE ? Ou bien « Voilà. » ?! Google, ressaisis toi !
Capture d_écran 2018-03-12 à 22.40.35
Pertinence : 7/10. ENCORE UNE FOIS, JE NE COMPRENDS PAS POURQUOI GOOGLE CROIT QUE JE PARLE À MON FRÈRE EN MAJUSCULE
Capture d_écran 2018-03-12 à 22.40.42
Pertinence : 5/10. C’était bien un « compte rendu », mais de la journée de mon amoureux. Réponse un peu trop formelle à mon goût, donc.
Capture d_écran 2018-03-12 à 22.40.55
Pertinence : 9/10. (Je n’ai pas envie de mettre 10/10 à une IA)

Bref, je n’ai encore jamais utilisé ces boutons, que je trouve plus souvent hors propos qu’à propos, mais je crois que cela n’empêche pas l’algorithme de continuer d’observer mon style d’écriture, alors peut-être que ça va s’affiner avec le temps ?