Analyser les attentes de lutilisateur

1. Objectifs

   • Distinguer le besoin, l'attente et l'envie d'un utilisateur
   • Repérer les attentes explicites et les attentes implicites
   • Recueillir les attentes à partir de plusieurs sources : entretien, questionnaire, observation, avis
   • Classer les attentes avec le modèle de Kano
   • Transformer une attente floue en exigence vérifiable et en récit utilisateur
   • Prioriser les attentes avec la méthode MoSCoW

1. Présentation

   • Dans la leçon précédente, vous avez identifié le besoin de l'utilisateur : ce qu'il doit accomplir. Mais deux applications qui répondent au même besoin peuvent être jugées très différemment : l'une paraît « évidente », l'autre « pénible ».
   • La différence vient des attentes: la façon dont l'utilisateur imagine que les choses doivent se passer. Une attente non satisfaite provoque de la déception, même quand la fonctionnalité existe. Analyser les attentes, c'est apprendre à les découvrir, à les comprendre puis à les traduire en décisions de conception.

• Nous continuons avec BiblioCampus, notre application fictive de réservation de livres. Pour les activités, créez le dossier 08-attentes-utilisateur/ dans votre dépôt GitHub ui-ux-design-bts.

1. Besoin, attente et envie

   • Ces trois mots sont souvent confondus. Ils décrivent pourtant trois niveaux différents :
     • le besoin est le but à atteindre, indépendamment de l'application ;
     • l'attente est la manière dont l'utilisateur pense que cela doit se passer : ce sont ses critères pour juger le service ;
     • l'envie est un plus qui ferait plaisir, sans être indispensable. Nous l'étudierons dans la leçon suivante.

1. Exemple 1 : le même besoin, deux attentes différentes

   • Deux étudiants ont le même besoin : emprunter le livre de Flutter pour le projet de fin d'année.
     • Amine vient tous les jours sur le campus : il attend surtout de réserver vite et de passer prendre le livre entre deux cours ;
     • Salma habite loin et voyage en bus : elle attend d'abord de savoir avec certitude que le livre est disponible avant de se déplacer.
   • Une application qui affiche « disponible » sans être à jour satisfait à peu près Amine, mais déçoit fortement Salma. Pour concevoir une bonne application, il faut donc connaître les attentes de chaque profil, pas seulement le besoin commun.

1. Attentes explicites et attentes implicites

   • Les attentes explicites sont celles que l'utilisateur exprime quand on l'interroge.
   • Les attentes implicites lui paraissent si évidentes qu'il ne pense pas à les dire : rapidité, fiabilité, sécurité, formats habituels… Elles sont pourtant les premières à provoquer de la colère quand elles ne sont pas respectées :

• Pour faire apparaître les attentes implicites, observez l'utilisateur en situation réelle et demandez-lui de raconter sa dernière mauvaise expérience : on découvre souvent ce qui « devrait aller de soi ».

1. Où trouver les attentes ?

   • Aucune source ne suffit à elle seule. Chacune apporte un éclairage et a ses limites :

1. Poser les bonnes questions

   • Lors d'un entretien, la façon de poser une question influence beaucoup la réponse. Comparez :
     • question fermée: « Vous aimez l'application ? » → on obtient « oui » ou « non », sans explication ;
     • question orientée: « Vous trouvez la recherche lente, n'est-ce pas ? » → l'utilisateur répond ce que vous voulez entendre ;
     • question ouverte: « Racontez-moi la dernière fois que vous avez cherché un livre. » → l'utilisateur décrit ce qu'il a vécu, avec ses mots.
   • Préférez les questions ouvertes sur des faits récents, puis demandez « Pourquoi ? » ou « Que s'est-il passé ensuite ? ». Ne proposez pas de solution pendant l'entretien : écoutez.

1. Comprendre l'utilisateur : la carte d'empathie

   • La carte d'empathie résume ce qu'un utilisateur type dit, pense, fait et ressent. Elle aide l'équipe à se mettre à sa place et à déduire des attentes qu'il n'exprime pas directement :

• Remarquez l'écart entre ce que Salma dit (« je n'ai pas le temps ») et ce qu'elle fait (elle demande à ses amis, elle fait des captures d'écran) : ces détours révèlent une attente forte de fiabilité.

1. Exemple 2 : analyser des avis d'utilisateurs

   • Les avis laissés sur le store sont une source précieuse et gratuite. Pour les exploiter, on les regroupe par affinités: chaque avis devient une note, on rassemble les notes qui parlent de la même chose, puis on compte :

1. Classer les attentes : le modèle de Kano

   • Le modèle du professeur Noriaki Kano montre que toutes les attentes n'ont pas le même effet sur la satisfaction :

• Conséquence pratique : on commence par garantir les attentes de base. Les améliorer au-delà du nécessaire ne rapporte presque rien, mais les oublier fait fuir les utilisateurs.
• Avec le temps, un facteur d'enthousiasme devient une attente de base : le paiement sans contact surprenait il y a quelques années, il est aujourd'hui attendu partout.

1. Formuler des exigences vérifiables

   • « Rapide », « simple », « joli » : les attentes sont souvent exprimées avec des mots flous. Le concepteur doit les traduire en exigences vérifiables, c'est-à-dire précises et mesurables, pour pouvoir les tester :

1. Le récit utilisateur (user story)

   • Le récit utilisateur est une phrase courte qui garde le lien entre la fonctionnalité et l'attente qui la justifie. Il suit le modèle : En tant que [profil], je veux [action], afin de [bénéfice].
   • On lui associe des critères d'acceptation, écrits sous la forme Étant donné… Quand… Alors…, qui permettront de vérifier que l'attente est satisfaite :

1. Prioriser les attentes : la méthode MoSCoW

   • Le temps et le budget sont limités : on ne peut pas tout réaliser dans la première version. La méthode MoSCoW classe chaque attente dans l'une de quatre catégories :

• Pour choisir la catégorie, croisez le modèle de Kano (une attente de base est presque toujours « Must ») et le nombre d'utilisateurs concernés.

1. Exemple 3 : de l'avis à la décision

   • Suivons une attente du début à la fin :
     • source: 14 avis disent « marqué disponible, mais plus en rayon » ;
     • attente: implicite, l'information affichée doit être exacte ;
     • Kano: attente de base, son absence provoque une forte colère ;
     • exigence: un changement de stock à l'accueil est visible dans l'application en moins d'une minute ;
     • MoSCoW: Must, à traiter avant toute nouvelle fonctionnalité.

1. Activité 1 : besoin, attente ou envie ?

   • Classez chaque phrase dans la bonne catégorie :
     • a) « Je dois rendre mon rapport de stage avant le 30 juin. »
     • b) « Je veux trouver un livre en tapant seulement le sujet. »
     • c) « Ce serait sympa d'avoir un badge quand j'ai lu dix livres. »
     • d) « La page doit s'afficher même avec le Wi-Fi du campus. »
     • e) « J'ai besoin de consulter des ouvrages de réseau pour mon examen. »
     • f) « J'aimerais voir quels livres lisent les étudiants de ma classe. »
   • Vérifier : a) et e) sont des besoins ; b) et d) sont des attentes ; c) et f) sont des envies. Laquelle de ces attentes est implicite ?

1. Activité 2 : révéler les attentes implicites

   • BiblioCampus va permettre de payer les amendes de retard en ligne. Les étudiants interrogés ont seulement dit : « Je veux pouvoir payer depuis mon téléphone. »
   • Listez au moins cinq attentes implicites liées à ce paiement.
   • Vérifier : vous pouvez citer par exemple le paiement sécurisé, le montant affiché avant de valider, un reçu envoyé par e-mail, aucun double paiement en cas de double clic, le montant en dinars, l'amende effacée immédiatement du compte.

1. Activité 3 : classer des avis

   • Voici les derniers avis laissés sur BiblioCampus. Regroupez-les par thème, puis indiquez pour chaque thème la catégorie de Kano correspondante :

• Vérifier : disponibilité fiable (avis 1) et connexion conservée (avis 5) sont des attentes de base ; rapidité (avis 2), lisibilité (avis 3) et simplicité de réservation (avis 6) relèvent de la performance ; rappel avant la date de retour (avis 4 et 7) est une attente forte, et les livres conseillés par les enseignants (avis 8) sont un facteur d'enthousiasme.
• Quel thème traiteriez-vous en premier ? Pourquoi ?

1. Activité 4 : analyser un extrait d'entretien

   • Lisez cet extrait. Relevez les attentes explicites, puis les attentes implicites que vous en déduisez :

• Vérifier : attentes explicites : chercher par matière, fonctionner avec le Wi-Fi du campus. Attentes implicites : obtenir de l'aide en dehors des horaires de la bibliothécaire, retrouver sa réservation même si l'application plante (la capture d'écran est un détour qui le prouve).
• Repérez dans l'extrait une question ouverte posée par l'enquêteur.

1. Activité 5 : construire une carte d'empathie

   • Réalisez la carte d'empathie de Madame Ben Salah, bibliothécaire du campus, qui gère les retours et les réservations sur un ordinateur de l'accueil.
   • Complétez les cases Dit, Pense, Fait, Ressent, puis déduisez au moins trois attentes.
   • Vérifier : vos attentes concernent son travail réel (aller vite pendant l'affluence, éviter les erreurs de saisie, voir les retards d'un coup d'œil), et non celles des étudiants.

1. Activité 6 : rendre les attentes vérifiables

   • Transformez chaque attente en exigence vérifiable :
     • « L'application doit être sécurisée. »
     • « Je veux trouver facilement mes anciens emprunts. »
     • « L'inscription doit être rapide. »
     • « L'application doit marcher partout. »
   • Vérifier : chaque exigence contient une valeur ou une condition précise (un nombre d'écrans, un délai, une liste d'appareils, une règle de mot de passe…) qui permet de répondre par oui ou par non.

1. Activité 7 : écrire des récits utilisateur

   • Écrivez trois récits utilisateur pour BiblioCampus : un pour un étudiant, un pour un enseignant et un pour la bibliothécaire.
   • Ajoutez à chacun au moins deux critères d'acceptation Étant donné… Quand… Alors…
   • Vérifier : chaque récit a un profil précis, une action et un bénéfice ; chaque critère décrit une situation testable.

1. Activité 8 : prioriser avec MoSCoW

   • L'équipe ne dispose que de quatre semaines pour la prochaine version. Classez ces attentes dans un tableau MoSCoW et justifiez chaque choix :
     • stock affiché toujours à jour ;
     • rappel deux jours avant la date de retour ;
     • paiement des amendes en ligne ;
     • mode sombre ;
     • recherche par matière ;
     • classement des meilleurs lecteurs.
   • Vérifier : le stock à jour est un « Must » (attente de base) ; votre justification s'appuie sur le modèle de Kano, le nombre d'utilisateurs concernés et le temps disponible.

1. Activité 9 : mener un mini-entretien

   • Par deux, préparez cinq questions ouvertes sur la façon dont votre camarade révise ses examens. Menez un entretien de dix minutes en prenant des notes.
   • Rédigez ensuite trois attentes explicites et deux attentes implicites, puis faites-les valider par la personne interrogée.
   • Vérifier : aucune de vos questions n'est fermée ou orientée ; vos attentes reprennent des faits racontés, pas vos suppositions.

1. Activité 10 : déposer votre travail sur GitHub

   • Regroupez dans 08-attentes-utilisateur/README.md vos réponses, votre carte d'empathie, vos récits utilisateur et votre tableau MoSCoW. Ajoutez les photos de vos schémas, puis envoyez le tout :

git add 08-attentes-utilisateur
git commit -m "Ajoute la leçon sur l'analyse des attentes de l'utilisateur"
git push

• Vérifier : le fichier README.md et vos images apparaissent bien sur la page GitHub du dépôt.

1. Erreurs fréquentes

1. À retenir

   • Le besoin est le but ; l'attente est la manière dont l'utilisateur pense l'atteindre ; l'envie est un plus.
   • Les attentes implicites ne sont pas dites, mais leur absence déçoit le plus.
   • On recueille les attentes en croisant entretiens, questionnaires, observation, avis, support et statistiques.
   • Le modèle de Kano distingue attentes de base, attentes de performance et facteurs d'enthousiasme.
   • Une attente devient utile quand elle est formulée en exigence vérifiable ou en récit utilisateur avec des critères d'acceptation.
   • La méthode MoSCoW aide à décider ce qui entre dans la prochaine version.

L'utilisateur ne juge pas votre application sur ce qu'elle fait, mais sur l'écart entre ce qu'il attendait et ce qu'il a vécu.