Identifier les besoins utilisateurs

C’est pour quoi faire ?

Alexia Dupré-Doàn
Pretto
4 min readApr 30, 2024

--

La forme suit la fonction.” (Louis Sullivan — 1896)

Étape 1 : trouver les problèmes

“Soyez attentifs à ce que les utilisateurs font, pas à ce qu’ils disent. Les demandent spontanées ne sont pas fiables tout comme les spéculations qui concernent des comportements futurs. Les utilisateurs ne savent pas ce qu’ils veulent” (Jakob Nielsen)

Il faut pouvoir distinguer très clairement ce qui relève d’un comportement de ce qui relève d’une envie.

Analyser les Feedbacks

Les demandes spontanés
Exemple : “j’aimerais que…”, “j’ai besoin de…”, “il faudrait que…”
➡ ️On les récolte et on les agrège. C’est la récurrence qui fait l’information, pas son contenu.

Perception
Exemple : “c’était mieux avant, c’est long, c’est moche…”
➡ Derrière ce jugement personnel peut se trouver un problème qui biaise la perception de l’outil. À nous de trouver ce qui cause cette perception en s’appuyant notamment sur l’étude des biais cognitifs.
(ressource : https://growth.design/psychology).

Remontées métiers
Exemple : “on est souvent obligé de…”, “il est techniquement impossible de…”, “la convention n’existe pas pour…”
➡ On les récolte et on les agrège. Il s’agit souvent de contraintes sur lesquelles il sera nécessaire de communiquer régulièrement pour suivre leur niveau de criticité et leur impacte sur le business et les users.

Blocages
Exemple : “je n’arrive pas à…”, “comment faire pour…”
➡ Expriment un problème UX, une fonctionnalité manquante ou incomplète, un bug. Une enquête permettra de comprendre d’où vient le problème.

Observations

Data analyse
De nombreux problèmes peuvent être identifiés par la data : un drop important, des objectifs non atteints, une incohérence…
Ces observations sont souvent à la base d’un pitch de projet (chez Pretto on travaille par Batch) car facilement imputables à des OKR.

Shadowing
Lorsqu’un utilisateur vise un objectif que le produit ne permet pas d’atteindre, il cherche des solutions de contournement. Détecter les comportements de contournement permet d’identifier des besoins. Attention car parfois la solution de contournement est extérieur au Produit ! Exemple : je prends mon téléphone et j’appelle un numéro trouvé sur Internet au lieu d’utiliser le répertoire du Produit.
➡ Pour cela il sera utile de pratiquer des sessions de shadowing ou de visionner des sessions Hotjar. On réalisera une synthèse sous forme d’un ou plusieurs task flow pour comprendre quelles sont les stratégies de contournement adoptées par les utilisateurs.

Étape 2 : Opportunités de solutions

Une fois le problème identifié, on aura des questions à poser et à se poser pour tenter de mieux les comprendre et identifier des solutions potentielles.

Co-conception

On pourra faire participer nos utilisateurs à la co-conception de solutions via des ateliers thématiques autour d’un des problèmes préalablement identifiés. À défaut ces ateliers pourront être réalisés entre stakeholders.

  • Brainstorming
  • Card Sorting
  • Crazy 8

Sondages

Grâce aux problèmes identifiés il sera possible de réaliser des questionnaires afin de récolter des informations quantitatives sur des comportements observés qualitativement. Par exemple, si on a observé 2 personnes mettre du ketchup sur les pommes de terre et 4 de la mayonnaise, on pourra poser la question à un panel plus grand pour confirmer l’hypothèse selon laquelle 2x plus de gens prennent de la mayonnaise.

Veille Produit et Benchmark

Il est important d’intégrer la veille comme une activité quotidienne de la vie des Product Managers, Product Designer et Développeurs. Au delà du domaine d’activité d’un produit, il sera utile de repérer tout au long de l’année des fonctionnalités ou des solutions UI/UX inspirantes pour pouvoir s’en souvenir le cas échéant.

Côté benchmark, on se concentrera sur le problème plus que sur le domaine d’activité en réalisant un document composé de screenshots et d’un descriptif détaillé du fonctionnement de la solution concurrente en précisant ce qui semble adapté à notre cas de ce qui ne l’est pas.

⚠️ Le domaine d’activité a peu d’importance. Par exemple, si je suis un courtier en ligne et que je souhaite explorer le meilleure solution de téléchargement pour des fichiers volumineux, il sera plus intéressant d’analyser la solution d’un WeTransfer que d’un MeilleurTaux !

Exemple :

User Flow

Généralement on réalisera ici encore des user flow intégrants les solutions envisagées. On y fera apparaître la liste des écrans a designer et les chantiers techniques nécessaires à la réalisation de cette solution.

💡 Ce document est une base précieuse qui permet d’évaluer la charge de travail des différents acteurs du projet. C’est la Big Picture de la solution qui permettra au PM d’écrire les Specs.

--

--