UX Days 2016 : compte-rendu des ateliers

Si vous me suivez sur Twitter, vous n’êtes pas sans savoir que la semaine dernière je suis allée au UXdays2016 organisés par FLUPA. C’était ma première fois, et voici un petit compte-rendu de la première journée consacrée aux ateliers.

Construire de vrais personas à partir de données réelles de terrain

J’ai commencé par un atelier sur la création de Personas à partir de données réelles, animé par Laure Andrivot et Dominique Decotter de la société Aktan.

Les personas sont des archétypes d’utilisateur·trices cibles permettant d’améliorer la communication en interne pour recentrer systématiquement les discussions sur les besoins réels à base de “Est-ce que cette fonctionnalité serait utile à Michel ?” “Est-ce que Maureen aurait envie d’utiliser cette fonctionnalité ?”.

N’étant quasiment pas en contact avec mes vrais utilisateur·trices, je n’ai jamais eu l’occasion de créer des personas à partir de données réelles. Cependant, ayant récemment mis en place un questionnaire en ligne pour avoir quelques retours et informations personnelles sur mes utilisateur·trices, cet atelier m’intéressait beaucoup pour apprendre à traiter les données brutes que je suis en train d’accumuler afin d’en extraire les fameux archétypes. Déception donc, quand j’ai compris que nous allions seulement apprendre à “Remplir un canevas” de personas, et pas à synthétiser les informations concernant l’ensemble des données accumulées. Ceci étant dit, le canevas était bien fait et m’a permis de mesurer l’importance d’étudier certains éléments, comme les capacités du personas (physiques, intellectuelles, en termes de temps, etc).

L’expérience passe par les expérimentations

J’avais ensuite choisi d’aller explorer les possibilités d’Adobe XD, un atelier animé par Yohan Founs, Senior Creative Technologist chez Adobe. J’ai beaucoup aimé la vision et l’état d’esprit de l’animateur, qui a commencé par rappeler que l’enjeu du design est l’adoption du produit par les utilisateur·trices, et que le nombre de téléchargements d’une appli n’est pas un bon indicateur de réussite (plutôt un bon indicateur de bonne comm’ !).

L’approche choisie par Adobe est de proposer une plateforme collaborative pour simplifier le travail en groupe et/ou à distance. Pour cela, le Creative Cloud permet de partager des bibliothèques projet à travers plusieurs logiciels de la suite et plusieurs intervenants sur le projet. Ces bibliothèques peuvent contenir toutes sortes de données : images, brushes, polices, palettes de couleurs…

L’intervenant a commencé par nous époustoufler avec l’appli Adobe Capture (dispo gratuitement sur les stores Android et Apple) qui permet de capturer des formes ou des couleurs grâce à l’appareil photo du device. Ainsi, je peux en deux-temps-trois-mouvements capturer une ambiance colorée qui me plait, ou vectoriser une forme dessinée sur un bout de papier ou sur un tableau blanc. Voici par exemple un dessin que j’ai fait ce matin sur mon whiteboard (je ne vous ai jamais parlé de mon tableau blanc ? Un grand calendrier recouvert d’un papier Velleda toujours sur mon bureau prêt à l’emploi, ça a révolutionné mes habitudes de travail !) :

Bonhomme dessiné sur tableau blanc et numérisé grâce à l'appli Adobe Capture

Concernant Adobe XD, le plus intéressant de mon point de vue est la démarche choisie par Adobe. Pour un logiciel développé pour des UX designers, la société à fait le choix de développer un MVP (Minimum Viable Product) compatible Mac (le coeur de leur cible) et de le tester à grande échelle pour recueillir au plus vite les avis et les besoins de leurs réel·les utilisateur·trices. Ainsi, un forum de discussion a été mis en place par Adobe pour permettre à chacun de reporter des bugs et d’ajouter (ou de voter pour) des demandes de fonctionnalités. Ces retours aident les décisionnaires à prioriser le Product Backlog. De nouvelles fonctionnalités sont livrées chaque mois dans une nouvelle release.

Le soft en lui-même est encore assez simpliste mais permet déjà d’optimiser le maquettage de plusieurs manières, en particulier dans la manière de gérer les éléments répétés :

  • la fonction Repeat Grid permet en un coup de souris de répéter un élément sous forme de liste (vertical) ou de grille (vertical + horizontal)
  • une fois cette fonctionnalité utilisée, les éléments répétés sont synchronisés entre eux : dans une liste de contact par exemple, si on édite le label “Nom”, celui-ci sera modifié dans toutes les occurrences de la liste
  • il est également possible de distribuer un ensemble d’images ou d’éléments textuels dans les différentes occurrences de la grilles un une seule action

D’autre part, le blur d’image est grandement simplifié par rapport à Photoshop, en 2 clics une zone d’une image est floutée pour obtenir un effet iOS.

Avec un bureau infini, il est possible dans un projet Adobe XD de produire autant de maquettes que nécessaire pour définir un parcours utilisateur. Yohan Founs propose comme bonne pratique de chapeauter le projet avec un court résumé du persona pour lequel ce parcours a été conçu : nom, objectif, problème à résoudre.

Une autre bonne pratique à avoir en tête est de décliner chacun des composants de l’interface selon les différents états dans lesquels il peut se trouver, en particulier Normal, Actif, Désactivé, et Vide (ne contient aucun élément).

Une fois les maquettes réalisées, l’onglet Prototype permet de lier très simplement les écrans les uns avec les autres, tester et enregistrer sous forme de vidéo le parcours utilisateur, et partager le prototype avec des collaborateurs via un export sur le Cloud.

Concernant mes propres besoins en termes d’outil de prototypage, je pense qu’Adobe XD pourra réellement améliorer mon efficience dans la création de maquettes, dès lors que certains éléments de base auront été développés. Pour l’instant, outre la version Windows (en cours de développement), mon manque le plus évident est l’absence de micro-interaction (ouvrir/fermer un menu, swiper entre des fiches produits, etc), mais cette demande est très haute dans les priorités donc elle devrait venir vite.

User Story Mapping

J’ai ensuite participé à un atelier sur le User Story Mapping, animé avec beaucoup d’énergie et d’humour par Sophie Freiermuth.

Une User Story Map est un outil collaboratif permettant de représenter de manière physique toutes les idées de toutes les personnes engagées dans la supervision, le développement ou la production d’un service ou de l’un de ces éléments. Cette représentation physique sera ensuite un outil solide pour assister le ou la Product Owner dans la priorisation des développements.

Le pouvoir des idées hors de la tête et visibles pour tous

Le concept clé est de considérer que les idées de chaque personne impliquée ont de la valeur, et qu’il faut les extraire pour les valoriser. Or, on n’explique pas une idée, on en raconte une histoire. Quatre éléments de langages peuvent nous aider dans ce storytelling :

  • Et puis : donne une temporalité à l’histoire, du passé vers le futur
  • Parce que : exprime une causalité, un lien vers le passé
  • Pendant ce temps : propose d’observer ce qu’il se passe simultanément dans un autre référentiel
  • Et si : permet d’exprimer des cas particuliers, de capturer les idées accessoires et ainsi de ne pas froisser leurs émetteurs

Après ces quelques bases théoriques, nous passons à un exercice pratique : lister sur des post-its notre rituel du soir avant d’aller se coucher, une idée par post-it.

De manière très typique, j’ai réussi à ne pas suivre la consigne pourtant simple en ajoutant “et le mettre en mode avion” sur mon post-it “mettre en charge mon téléphone”. Pourquoi ne pas avoir fait un 2ème post-it ? Flemme ? Sentiment que des choses aussi proches pouvaient être rassemblées ? Intéressant en tout cas ce réflexe de contourner la consigne pour rassembler des tâches proches, bien que distinctes. Après débrief, on classe les post-its en 3 catégories :

  • les tâches récapitulatives : j’associerais cela à ma notion des EPICS dans Jira (outil web que mon entreprise utilise pour gérer les backlog) ; exemple : Se coucher
  • les tâches : les user stories ; exemple : se mettre en pyjama
  • les sous-tâches : les sous-éléments d’une tâche (sous-tâches dans Jira) ; exemple : retirer son pull

Les tâches récapitulatives doivent être mises en valeur (par exemple en tournant le post-it d’un huitième de tour pour lui donner une forme de losange ! Effet Wahoo garantie !). Dans ce type d’exercice, il est préférable de ne pas trop entrer dans le détail et de préférer une vision globale du projet. Ceci étant dit, un bon UX designer doit être capable de naviguer entre les différents niveaux d’information pour s’adapter à son interlocuteur : le ou la PDG s’intéressera à la vision globale tandis ce que les développeur·ses préféreront avoir une granularité d’informations beaucoup plus fine.

Une fois les idées listées, il faut ensuite les organiser sur la carte. Conventionnellement, la dimension horizontale représente le temps, le flux narratif. Les post-its seront donc placés de gauche à droite de manière à former un parcours utilisateur cohérent permettant de répondre au problème que nous nous posons (typiquement, le besoin principal de notre persona principal).

L’axe vertical, quant à lui, permet d’exprimer des variations. On peut imaginer une multitude de variations différentes.

Selon le contexte :

  • Strict minimum (quand on est très fatigué)
  • Habituellement (en situation normale)
  • Équipement spécial (en vacances)

Selon la connaissance qu’on a sur les risques et les besoins :

  • tâches pour lesquelles les risques et les besoins sont connus
  • tâches pour lesquelles les risques et les besoins doivent être vérifiés
  • tâches pour lesquelles les risques et les besoins sont inconnus

Selon les besoins :

  • Minimum Viable Product
  • Version 2
  • Version 3

Nous avons continué l’atelier par une deuxième exercice dans lequel nous avons produit par petits groupes la User Story Map d’une utilisatrice d’une appli de géolocalisation de ses contacts pro sur le lieux d’une conférence pour les retrouver facilement. Thème bien choisi quand sur Twitter deux de mes contacts me proposaient de se rencontrer sur la conf !

Lors de l’animation d’un atelier de Story Mapping, il est important de mettre en place des règles de participation, en particulier concernant la liberté d’expression de chacun. Il est indispensable de commencer la séance par la présentation du problème à résoudre, afin de s’assurer que tout le monde parle bien de la même chose. Enfin, il ne faut pas oublier que cet atelier a pour but le partage de la connaissance et l’extirpation cérébrale pour une projection physique, et en aucun cas la décision. Le ou la Product Owner, en discussion avec l’UX designer et un.e représentant.e du développement prendra la décision finale de l’ordre dans lequel les fonctionnalités seront développées.

Test utilisateur d’accessibilité, par vous, pour tous !

Enfin, j’ai terminé la journée avec un atelier sur l’accessibilité dans le web, animé par Vincent Aniort et David Molina (Orange). L’accessibilité c’est :

La capacité d’un service à être utilisé par tous, par des personnes en situation de handicap permanent ou temporaire (seniors, personnes valides), dans n’importe quel contexte (luminosité extérieur forte) et avec des outils spécifiques de compensation (NVDA, etc.).

De cet atelier, je retiens essentiellement deux choses :

  • L’accessibilité représente un avantage pour tous, une nécessité pour certains
  • L’accessibilité est relativement facile à tester

Un avantage pour tous, une nécessité pour certains

L’exemple le plus frappant est celui de la télécommande de téléviseur, initialement conçue pour les personnes handicapées moteur. Qui serait prêt à se passer de télécommande aujourd’hui et à se lever pour changer de chaîne ?

L’accessibilité présente de nombreux avantages pour tous : une amélioration du référencement, une diminution des coûts de maintenance (car le code est de meilleure qualité), un usage multi-support facilité, un effet positif sur l’image de marque (en externe et en interne), et accessoirement… c’est dans la loi !

Les recommandations internationales édictées par le W3C sont détaillées dans le document WCAG publié par le WAI, qui distingue 3 niveaux d’accessibilité :

      • environ un tiers des règles correspondent au niveau A
      • environ ⅔ des règles doivent être appliquées pour valider le niveau AA
      • le respect de l’intégralité des règles valide le niveau AAA

La politique choisie par Orange est de respecter 70% des règles validant le niveau AA, avec la contrainte de n’avoir aucun point bloquant pour l’utilisateur·trice dans le cadre du parcours principal.

Des tests faciles à faire

Il existe plusieurs manières d’évaluer l’accessibilité d’une page web. La première et la plus simple à mettre en place est l’évaluation automatique, qu’il est recommandé de faire le plus tôt possible dans le développement du projet. Cette évaluation ne couvre pas tous les critères (environ 25% des critères AA) et génère un nombre non négligeable de faux positifs (erreur remontée alors qu’il n’y a pas de problème) mais permet tout de même de relever environ 50% des erreurs. Il est donc important de réaliser ce test avant de passer aux évaluations manuelles, plus coûteuses car réalisées par un expert en accessibilité.

Quelques éléments à vérifier :

  1. Le titre de la page est explicite et différent pour chaque page : permet de différencier deux onglets ouverts sur le même site notamment
  2. Les rubriques sont écrites sous forme de titres (balises h1, h2, etc) et correctement hiérarchisées. La balise h1 est également importante pour le référencement, il serait dommage de ne pas l’exploiter !
  1. Les médias sont correctement décrits : audio description pour les vidéos et attribut alt sur les images. C’est particulièrement nécessaire lorsqu’une image est utilisée pour afficher du texte ! Le alt peut être laissé vide si l’image fait juste office de décoration.
  2. Dans les formulaires, les labels (titres des champs) sont correctement associés aux champs et les labels sont proches des champs à remplir pour réduire les erreurs des gens utilisant une loupe. Si un champ ne nécessite pas de label car le picto est suffisamment explicite (comme dans le cas d’un champ de recherche notamment), il est important d’y associer tout de même un label qu’on placera hors écran en CSS (top -10000).
  3. La taille des textes est réglable (en utilisant la fonction de zoom du navigateur) et la mise en page s’adapte pour que tous les textes restent lisibles (les zones contenant des textes s’agrandissent également)
  4. La couleur n’est pas utilisée comme seule source d’information. Pour indiquer les erreurs dans un formulaire par exemple, il est recommandé de mettre les messages d’erreur dans les labels de champs pour qu’ils soient associé à l’item erroné, et de les déplacer ensuite en CSS pour les placer à l’endroit adéquat (sous le champ ou à droite de celui-ci).
  5. L’interface est entièrement navigable avec le clavier. En particulier, il faut être vigilant vis-à-vis des pop-in qui ont tendance à être mal gérées et à bloquer la navigation.
  6. Les contrastes sont suffisants pour permettre une lecture confortable par tous. Le contraste entre deux couleurs se calcule (cf section suivante) et doit être comparé à une norme. Attention, la norme est plus contraignante sur mobile : il faudra donc porter une attention particulière aux contrastes des éléments les plus importants dans le parcours utilisateur principal.

Quelques outils :

Les deux animateurs de l’atelier nous ont fait une petite démo de tests automatiques et manuels sur le site du gouvernement stop-discriminations : verdict douloureux, surtout pour un site supposé non discriminant…

Les slides de cet atelier sont disponibles ici.

Voilà pour cette première journée d’atelier, j’essaierai de faire le résumé des conférences et le bilan des deux jours la semaine prochaine.

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.