| name | dev-ux-research-guide |
| description | Guide de recherche UX : interviews, tests utilisateurs, personas et analyse. Se déclenche avec "UX research", "recherche utilisateur", "interview utilisateur", "test utilisateur", "persona", "user testing", "usability", "parcours utilisateur". Also triggers on "user interviews", "usability testing". |
UX Research Guide
1. Définir l'objectif de recherche
Avant toute chose, formuler une research question précise et testable :
❌ "Améliorer l'expérience de checkout"
✅ "Pourquoi les utilisateurs abandonnent-ils leur panier à l'étape paiement ?"
Critères de décision — utiliser un framework SMART :
- Spécifique : une seule question par étude
- Mesurable : succès/échec quantifiable
- Atteignable : réaliste avec les ressources disponibles
- Relevant : directement liée à une décision produit
- Temporel : résultat attendu dans quel délai
2. Choisir la méthode adaptée
| Objectif | Méthode recommandée | Participants | Durée |
|---|
| Comprendre motivations/contexte | Entretiens semi-directifs | 5–8 | 45–60 min |
| Valider une interface | Usability test modéré | 5–8 | 30–60 min |
| Tester à grande échelle | Test non-modéré (Maze, Lookback) | 20–50 | 10–20 min |
| Valider une arborescence | Tree testing (Treejack) | 50+ | 10 min |
| Organiser le contenu | Card sorting (ouvert/fermé) | 15–30 | 20–30 min |
| Mesurer un changement | A/B test | 1000+/variante | selon trafic |
| Détecter des signaux faibles | Analytics + heatmaps (Hotjar) | — | continu |
Règle des 5 participants : pour les tests de facilité d'usage, 5 utilisateurs détectent ~85 % des problèmes. Augmenter l'échantillon si plusieurs segments cibles distincts.
3. Recruter les participants
Screener minimaliste (exemple pour une app fintech mobile) :
1. Avez-vous effectué un virement bancaire en ligne au cours des 3 derniers mois ? [oui/non]
2. Quel appareil utilisez-vous principalement ? [iOS / Android / Desktop]
3. Tranche d'âge ? [18-24 / 25-34 / 35-49 / 50+]
4. Avez-vous déjà utilisé [Produit X] ? [jamais / 1-5 fois / régulièrement]
- Recruter 20 % de plus que nécessaire (no-shows, disqualifications tardives)
- Incentive : 15–30 € pour 30 min, 40–60 € pour 1h (B2C) ; cartes cadeaux ou rapport personnalisé (B2B)
- Canaux : UserTesting, Respondent.io, réseau LinkedIn, panel interne clients
4. Construire le protocole
Guide d'entretien semi-directif
## Introduction (5 min)
- "Je ne teste pas vos compétences, je teste le produit."
- Rappel : enregistrement audio, consentement, droit de stopper.
## Questions contextuelles (15 min)
- "Racontez-moi la dernière fois que vous avez fait [action clé]."
- "Qu'est-ce qui vous a amené à utiliser [solution actuelle] ?"
- "Quels problèmes rencontrez-vous avec votre solution actuelle ?"
## Questions exploratoires (20 min)
- "Montrez-moi comment vous faites habituellement [tâche]."
- "Qu'est-ce qui vous faciliterait la vie ici ?"
## Clôture (5 min)
- "Y a-t-il quelque chose que je n'ai pas abordé et qui vous semble important ?"
Scénario de test d'utilisabilité
Contexte : "Vous venez de recevoir une facture de 250 € à régler."
Tâche : "Effectuez un paiement depuis votre compte principal."
Critère de succès : tâche réussie sans aide en < 3 min, ≤ 2 erreurs.
5. Conduire la session
Techniques de modération :
- Thinking aloud : "Dites ce que vous voyez / pensez à voix haute."
- Relance neutre : "Pouvez-vous m'en dire plus ?" / "Qu'est-ce que vous attendiez ?"
- Silence volontaire : attendre 5–7 secondes avant de relancer — les utilisateurs comblent eux-mêmes.
- 5 whys : creuser les causes profondes, pas les symptômes.
Prise de notes structurée (template) :
Timestamp | Observation factuelle | Citation exacte | Émotion observée | Hypothèse
00:04:32 | Hésite sur le bouton | "C'est où le paiement ?" | Frustration | Label ambigu
6. Analyser les données
Affinity mapping (Miro/FigJam)
1. Une observation = un post-it
2. Regrouper par similarité (bottom-up)
3. Nommer les clusters (≠ les titres prédéfinis)
4. Compter les occurrences : n=X/Y participants (ex : n=6/8)
5. Prioriser par fréquence × sévérité
Sévérité des problèmes (échelle Nielsen)
| Score | Signification | Priorité |
|---|
| 0 | Pas un problème | Ignorer |
| 1 | Cosmétique | Backlog |
| 2 | Mineur, contournable | Sprint futur |
| 3 | Majeur, ralentit | Sprint suivant |
| 4 | Bloquant, empêche la tâche | Urgent |
7. Créer les livrables
Persona (basé sur données, pas sur intuitions)
## Alex, 32 ans — Responsable comptable PME
**Citation réelle** : "Je perds 2h par semaine à réconcilier manuellement."
**Comportements** : vérifie ses comptes le matin sur mobile, Excel pour les exports
**Frustrations** : formats d'export incompatibles, pas de notifications en temps réel
**Objectifs** : clôture mensuelle rapide, zéro erreur de saisie
**Source** : composé de 6 participants sur 8 interrogés
Journey map — colonnes minimales
Étape | Actions | Pensées | Émotions | Pain points | Opportunités
Insight deck — structure par insight
Insight #3 : Les utilisateurs ne comprennent pas la distinction compte courant / compte épargne
Preuve : 5/8 participants ont cliqué sur le mauvais compte (tâche T2)
Impact : erreurs de virement, frustration (sévérité 3)
Recommandation : ajouter un libellé secondaire + solde visible dès la liste
Effort estimé : M (1 sprint)
8. Communiquer les résultats
Structure de présentation stakeholders :
1. Rappel objectif (1 slide)
2. Méthode + participants (1 slide)
3. Top 3 insights avec preuves (3 slides)
4. Recommandations priorisées (matrice impact/effort)
5. Prochaines étapes + responsables + dates
Anti-patterns et pièges
| Piège | Symptôme | Correction |
|---|
| Biais de confirmation | On retient les observations qui valident la solution prévue | Coder en aveugle, faire coder par 2 personnes |
| Questions suggestives | "N'est-ce pas que ce bouton est confus ?" | Reformuler en neutre : "Que pensez-vous de ce bouton ?" |
| Sur-représentation de la UX | Designer dans la session = participants performent mieux | Modérateur ≠ designer du produit testé |
| Personas fictifs | Personas créés sans données ("Marie, 35 ans, aime la simplicité") | Chaque attribut doit être tracé à une source |
| Insights sans décision | Rapport lu puis ignoré | Chaque insight = 1 décision produit associée dans le backlog |
| Trop de participants qualitatif | 20 entretiens pour une question simple | S'arrêter à saturation (généralement 6–8) |
| Tester trop tôt | Test sur wireframes non finalisés = feedback sur l'esthétique | Tester le flow, masquer les éléments décoratifs |
Bonnes pratiques 2026
- Recherche continue : sessions hebdomadaires courtes (20 min, non-modérées) en parallèle du développement plutôt que de grosses études ponctuelles.
- Repository centralisé : stocker tous les insights dans un outil dédié (Dovetail, Notion, Condens) pour réutilisabilité cross-équipe.
- Triangulation : croiser au minimum 2 sources (entretiens + analytics, ou tests + survey) avant de conclure.
- Accessibilité dans les tests : inclure systématiquement des participants avec handicaps (moteur, visuel, cognitif) pour détecter les barrières tôt.
- Ethics by default : anonymiser les données dès la collecte, consentement explicite, RGPD — ne stocker que ce qui est nécessaire.
Communication Rules — MANDATORY
- Ultra-concise. No filler, no preamble, no pleasantries.
- Never say "happy to help", "sure!", "great question", "let me", or similar.
- Tool first, talk second. Act before explaining.
- Result first. Lead with outcome, not process.
- Stop when done. No summary, no recap, no trailing commentary.
- No politeness wrappers. Direct and blunt.
- Minimum words. If one word works, do not use ten.
- No unsolicited explanations.
- No emoji unless asked.
