UX Design : définir un parcours utilisateur

De Sylvain Martinod dans Design|Méthodes et Organisation

3 juin 2018

Parcours utilisateur

Une phase importante dans le processus de conception tournée vers l’utilisateur final (UX design) est la définition des parcours utilisateur. Avant même de penser aux wireframes il est important de les définir pour commencer à identifier le chemin qu’ils vont emprunter. Nous sommes au tout début de la conception de l’expérience et c’est une étape à ne pas négliger. Mais comment fait-on pour les créer ? De quelle manière ? Qu’est-ce qu’on en retire ? Quand et comment les utilise-t-on ? Nous allons tenter de répondre à toutes ces questions.

L’importance des parcours utilisateur

Vous l’aurez compris, le parcours utilisateur est un outil redoutable lorsqu’il est bien utilisé. Il permet de s’assurer que l’expérience utilisateur est optimale, d’identifier les points d’effort pour l’équipe, anticiper certains coûts, mettre en évidence des potentielles lacunes organisationnelles du client (ce qui est assez délicat à faire remonter). Il permet aussi de mettre en évidence les écrans stratégiques pour le client (business model) et aussi pour l’utilisateur (le gain que lui procure le service). Et enfin il permet d’imaginer des solutions innovantes.

 

Démarrer avant la conception des wireframes

Wireframes

Petit rappel de ce qu’est un wireframe : ce sont des écrans qui vont poser les principes ergonomiques en niveau de gris. Il y a plusieurs applications pour réaliser des wireframes comme par exemple : Balsamiq, Adobe XD, UX Pin, in Vision, etc. Certains peuvent aller jusqu’au prototype avec des rendus haute fidélité. Un bon vieux crayon et papier suffisent aussi. Mais ce n’est pas notre sujet ici. Donc avant de rentrer dans ce degré de détail, il faut identifier les différentes phases/étapes que va devoir traverser l’utilisateur pour arriver à son but final, ce pour quoi il utilise le dispositif, et arriver à l’information souhaitée. Et c’est là qu’on peut identifier les points d’amélioration, les points noirs et même bloquants, qui anéantiraient l’expérience au risque de ne plus revoir l’utilisateur. On peut aussi identifier les risques côté client sur sa propre organisation interne car cela peut aussi générer une mauvaise expérience.

 

Qu’ai-je besoin pour commencer ?

Avant de vouloir entamer cette phase, vous devez avoir fait vos interviews, donc avoir identifié vos cibles, défini les contours de votre projet, créé vos personas, défini le contexte d’utilisation et la vision d’où il va aller. Et bien évidemment, toutes ces informations doivent être partagées avec l’équipe projet. Sans ces informations, le risque est de partir sur des suppositions et donc dans de mauvaises directions.
Donc pour résumé, vous devez connaître :

  • la ou les cibles
  • le contexte du projet
  • les objectifs
  • l’équipe projet à disposition

 

Mais pourquoi doit-on avoir l’équipe de disponible ?

Lorsqu’on met en place le parcours, les zones à risques vont être identifiées, il faut aussi pouvoir identifier les étapes ou écrans complexes qui vont demander plus d’efforts aux développeurs. Pour un chef de projet, il va pouvoir aussi identifier les écrans les plus coûteux. L’équipe qui est partie prenante du projet aura le même niveau d’information et peut ainsi anticiper les difficultés.

 

Objectif MVP



MVP = Minimum Viable Product
Il s’agit d’envisager le produit avec les fonctionnalités suffisantes pour satisfaire les utilisateurs (ces fonctionnalités pourront évoluer pour être plus abouties). Plutôt que d’essayer de construire une Ferrari tout de suite et prendre le risque d’échouer à la mise en production à cause des objectifs trop élevés, il faut avoir la vision du produit fini tout en le construisant avec précaution.

 

Les outils

Il y a plusieurs outils pour définir un parcours : personas, customer journey, experience map, user story, storyboard, point de contact, cas d’usage, service blueprint, parcours utilisateur… tous ne sont pas à faire à chaque projet car ils ne répondent pas tous au même besoin.

 

Pour différencier les outils

Un outil pour prendre le point de vue des usagers ou pour le point de vue du service, ça ne remplit pas les mêmes objectifs.

 

Quels outils à notre disposition ?

Il peut y avoir plusieurs cas de figures : raconter une histoire dans le temps, raconter l’usage d’un produit ou service. Pour chaque phase on utilise un outil qui permet de définir de manière plus précise l’expérience attendue.

Ne pas se focaliser sur le nom donné de l’outil mais sur l’objectif à atteindre, se focaliser sur les contenus.

 

Le point de contact (pas un réel outil)

Il s’agit d’un moment où il y a une interaction entre le service et l’utilisateur, quel que soit le biais.

 

Les cas d’usage

C’est une liste de tous les contextes dans lequel une personne va utiliser le produit ou service.
L’objectif est de ratisser tous les cas où l’utilisateur va utiliser le service, identifier les difficultés. Il ne faut rien oublier.

  1. Lieu de l’usage ?
    Quels sont les lieux d’usage pour ce service ?
    Exemple : une application de musique est utilisée partout (chez l’utilisateur, dans la rue, chez une autre personne, dans la voiture, dans le bus, etc.).
    Il faut tout lister.
  2. Les objectifs de l’utilisateur?
    Qu’est-ce que l’utilisateur veut faire pour utiliser le service ?
    Exemple : une application de musique fait passer le temps, aide à se relaxer.
  3. Les éléments extérieurs qui interfèrent avec les cas d’usage ?
    Quels éléments vont avoir une influence dans l’utilisation du service ?
    Exemple : une application de musique peut être utilisée seul(e), avec des amis ou en famille, il peut s’agir d’une première utilisation ou d’une reprise d’utilisation, etc.
  4. Les personas
    Ils sont les yeux utilisés pour se projeter, ils permettent de compléter les cas d’usage. Plusieurs personas peuvent être cumulés pour couvrir plus de cas d’usage.

Participants : 2 à 4 personnes
Matériel : Sur post-it
Temps : Recherche de 7 min à 10 min, segmentation des idées 5 min

 

Les scénarios d’usage

User Story

Un scénario d’usage peut également être appelé User Story, Story Board. C’est l’extension des cas d’usage. Le principe est simple : on prend un des personas préalablement établi avec soin, on lui assigne un usage du service et on raconte une histoire. Une image et un texte représentent une histoire (il faut prévoir un texte suffisamment clair qui définit bien l’histoire, soit un enchaînement d’image et de textes pour la décomposer).

L’objectif est de se projeter sur les cas d’usage : on choisit les cas un peu extrêmes, ceux qui sont les plus challengeant. On veut se projeter et idéaliser l’expérience pour l’utilisateur.

L’intérêt est de mettre en évidence l’importance de chaque fonction dans le service. On vérifie comment les usages évolueront. On vérifie les émotions, le rythme/temps, on cherche à apporter uniquement du positif même dans des cas complexes. Rendre tangibles des situations intangibles.

Recette : On prend un cas d’usage, on mélange avec un persona, ce qui nous donne un scénario. Prévoir un scénario par persona.

Participant(s) : Seul(e) ou 2 à 4 personnes
Matériel : Feuille A4, stylo. Si on ne veut pas dessiner : Google Images (outils -> type -> dessins au trait)
Temps : Petite journée pour 3 à 4 scénarios (seul(e))

 

Experience MAP

Experience map
L’experience map peut aussi être appelée costumer journey, point de contact. Ce sont des scénarios d’usage augmentés, toujours sur le point de vue des usagers/utilisateurs, il se définit en étapes et avec les points de contact. Il n’y a pas de schéma spécifique à utiliser, tout va dépendre du contexte du projet.

Vous pouvez mettre les lignes suivantes :

  • les étapes définies chronologiquement
  • une ligne de temps (les étapes ont une durée)
  • les points de contact : lieux et supports (application smartphone, opérateur téléphonique, boutique, etc.)
  • les actions de l’utilisateur
  • une cartographie des émotions avec en parallèle une cartographie de l’engagement de l’utilisateur. Cela permet d’alerter sur les points noirs, c’est-à-dire quand l’engagement est plus fort que l’émotion (émotion négative).

Aucun des éléments listés ci-dessus n’est obligatoire. Cela va dépendre de ce que vous souhaitez analyser.

 

Current state vs futur state

Le current state est l’état actuel des choses, il faut faire une synthèse de l’expérience actuelle, identifier les points noirs. Ensuite il faut initier un travail d’amélioration en mettant en évidence les axes à corriger et aussi identifier les opportunités d’innovation.

Le futur state, quant à lui, est une projection réaliste d’une solution idéale pour l’utilisateur. Il consiste à vérifier que l’émotion reste positive et au-dessus de l’engagement qu’on lui demande. Cela permet de concevoir des solutions concrètes et réelles et prendre des décisions stratégiques sur l’expérience qui lui sera proposée.

Recette : on prend un persona pour créer une map, on reste là aussi sur une experience map par persona.

Rien n’est définitif, l’experience map peut être modifiée dans le temps et intégrée dans une itération. Elle peut être mise en place après la création de wireframes. Il est cependant préférable de la créer en amont car elle représente un bon support pour la création des wireframes.

L’experience map permet de faire une projection de ce que sera l’expérience par la suite au même titre qu’un business plan. Elle peut être créée en atelier de co-conception mais demande une bonne maîtrise dans la conception de ce document et la gestion de l’atelier.

La formalisation de l’experience map se fait généralement en tableau, mais cette écriture peut être laborieuse surtout quand l’expérience est longue et complexe. Dans ce cas, on peut très bien imaginer de découper le document avec des slides, où une diapositive représente une action.

Participant(s) : Seul(e) ou plusieurs (mais compliqué)
Matériel : Logiciel de votre choix (Photoshop, Illustrator, etc.), Excel peut aussi être utilisé
Temps : Deux heures à deux jours en fonction de la complexité de l’usage

 

Le service Blueprint

Serive Blueprint
Le but du service Blueprint est d’améliorer l’organisation, l’orchestration interne d’une société. C’est un design de service. L’élaboration de ce document fait appel à du bon sens. L’objectif est d’orchestrer et organiser le service de façon concrète. Cela permet d’éclaircir les rôles, d’ajuster l’organisation interne et améliorer l’expérience client (CX Design).

On définit (de haut en bas) :

  • Les points de contact (physical evidences)
    Case liée à utilisateur.
    Exemple : site web, mail, lettre, etc.
  • Étape du parcours utilisateur ?
    Case liée à utilisateur.
  • Ligne des interactions
  • Action visible du service
  • Ligne de visibilité
  • Action invisible du service ?
  • Ligne des interactions internes
  • Action interne ?
    L’engagement de la société (formation interne, etc.)

Participant(s) : Des phases seul(e) et des phases en atelier
Matériel : Post-it et stylos pour les ateliers, un logiciel au choix pour la présentation du document
Temps : Une semaine

 

Comment utiliser le bon outil au bon moment ?

Il est difficile de donner un processus standard et utilisable dans toutes les situations. Il faut se poser la question de quel outil utiliser en fonction des projets plus ou moins complexes avec des utilisateurs très différents. Chacun de vos clients a aussi des enjeux différents.

 

Cas 1 : J’ai affaire à un projet complexe.

Solution : Commencer le service Blueprint pour faire un état des lieux de la société pour une application interne. Si c’est l’XP qui est à remettre en cause, il faut établir une experience map.

 

Cas 2 : J’ai des personnes qui sont trop extrêmes avec trop de différences, ou qui sont en dehors de la cible, mais je dois prendre en compte toutes ces personnes.

Solution : Utiliser des scénarios d’usage en priorité pour détailler l’expérience des personnes.

 

Cas 3 : J’ai un projet qui ne cesse d’avoir de nouvelles fonctions.

Solution : Il faut être capable de recadrer le projet et de redéfinir les cas d’usage. Poser la question de « pourquoi ? », il faut garder du sens dans le projet. Il faut redéfinir les priorités, sinon c’est votre travail qui va en pâtir.

 

Cas 4 : Les priorités données pour le projet ne sont pas les bonnes.

Par exemple si on identifie des freins pour les utilisateurs ou qu’il n’est pas au centre des réflexions ou encore que l’équipe projet n’a pas conscience de la réalité du terrain.

Solution : L’experience map est utile pour travailler sur les courbes des émotions et de l’engagement pour mettre en évidence devant le client que la direction n’est pas bonne et que le projet risque d’échouer.

Et pour finir en beauté, je vous laisse entre les mains de Melo, UX Designer qui donne la pêche et prêche les bonnes pratiques (Merci MELO !) :

Commentaire

9 − deux =

iMDEO recrute !

REJOIGNEZ-NOUS

A la recherche de nouveaux talents (développeurs web et mobile, chefs de projet,...)

Voir les annonces