💻 Développement

dev-ux-research-guide

Guide de recherche UX : interviews, tests utilisateurs, personas et analyse.

⚡ Installation & lancement en 1 commande

Copiez-collez dans votre terminal : le skill s'installe dans ~/.claude/skills et Claude Code se lance directement dessus.

macOS / Linux
curl -fsSL https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.sh | sh -s -- dev-ux-research-guide --launch
Windows (PowerShell)
iex "& { $(iwr -useb https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.ps1) } dev-ux-research-guide -Launch"

🚀 Déjà installé ?

claude "/dev-ux-research-guide"

Ou tapez /dev-ux-research-guide dans une session Claude Code, ou décrivez simplement votre besoin — le skill se déclenche automatiquement via le skill-router.

🔑 Déclencheurs automatiques

Le skill s'active automatiquement quand votre demande contient :

UX researchrecherche utilisateurinterview utilisateurtest utilisateurpersonauser testingusabilityparcours utilisateur

📦 Installation manuelle

git clone https://github.com/khalilbenaz/claude-skills-collection.git cp -r claude-skills-collection/skills/dev-ux-research-guide ~/.claude/skills/

Payload du plugin : skills/dev-ux-research-guide · source éditable : dev-skills/ux-research-guide

đź“– Manuel

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 :

2. Choisir la méthode adaptée

ObjectifMéthode recommandéeParticipantsDurée
Comprendre motivations/contexteEntretiens semi-directifs5–845–60 min
Valider une interfaceUsability test modéré5–830–60 min
Tester à grande échelleTest non-modéré (Maze, Lookback)20–5010–20 min
Valider une arborescenceTree testing (Treejack)50+10 min
Organiser le contenuCard sorting (ouvert/fermé)15–3020–30 min
Mesurer un changementA/B test1000+/varianteselon trafic
Détecter des signaux faiblesAnalytics + 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]

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 :

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)

ScoreSignificationPriorité
0Pas un problèmeIgnorer
1CosmétiqueBacklog
2Mineur, contournableSprint futur
3Majeur, ralentitSprint suivant
4Bloquant, empêche la tâcheUrgent

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ègeSymptômeCorrection
Biais de confirmationOn retient les observations qui valident la solution prévueCoder 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 UXDesigner dans la session = participants performent mieuxModérateur ≠ designer du produit testé
Personas fictifsPersonas créés sans données ("Marie, 35 ans, aime la simplicité")Chaque attribut doit être tracé à une source
Insights sans décisionRapport lu puis ignoréChaque insight = 1 décision produit associée dans le backlog
Trop de participants qualitatif20 entretiens pour une question simpleS'arrêter à saturation (généralement 6–8)
Tester trop tôtTest sur wireframes non finalisés = feedback sur l'esthétiqueTester le flow, masquer les éléments décoratifs

Bonnes pratiques 2026