Toutes les méthodes du processus de design, et quand les utiliser.

Sur cette page

1. À retenir
2. Comment lire ce guide
3. Quelles sont les cinq phases du processus de design ?
4. Comprendre : que font réellement les personnes ?
5. Définir : quel est précisément le problème ?
6. Imaginer : comment passer de nombreuses idées à une seule ?
7. Prototyper : que construire avant de savoir ?
8. Tester : comment savoir si cela fonctionne ?
9. Quels modèles utiliser à chaque phase ?
10. Questions fréquentes
11. Sources

En 2023, je concevais Wfrah, une application pour les éleveurs de moutons et de chèvres du Golfe. Avant le premier écran, le fondateur, Abdullatif, nous avait expliqué l’obstacle : les éleveurs exercent comme leurs pères le leur ont appris et ne croient pas qu’une application connaisse mieux leurs animaux qu’eux.

Nous sommes donc allés les écouter. Dix entretiens approfondis avec des éleveurs d’expériences diverses, complétés par l’observation des outils qu’ils utilisaient déjà. Demandez pourquoi l’exploitation perd de l’argent, et la réponse revient : l’alimentation coûte cher et les acheteurs paient trop peu.

Les entretiens ont révélé ce qui se cachait derrière. Beaucoup d’éleveurs n’arrivaient pas à calculer les besoins nutritionnels quotidiens de leur troupeau à partir des équations. Convaincus que le marché était responsable, ils négligeaient l’alimentation et la gestion. La fonction la plus utile est devenue un calculateur nutritionnel qui fait le calcul pour chaque animal et chaque stade de croissance. Personne ne l’avait demandé. Les entretiens ont montré combien en avaient besoin.

Trois ans plus tard, j’ai construit l’interface de caisse de Dot, mon application de fidélité. La première version était mauvaise. Elle demandait le montant, puis un pays, puis le téléphone, puis un bouton : six pressions plus la saisie, sans aucun champ actif à l’ouverture. La refonte est partie d’une personne, décrite en une ligne : un caissier fatigué à un comptoir chargé, une main sur le téléphone et l’autre sur le gobelet. Le téléphone vient d’abord, le champ montant reçoit automatiquement le curseur et un client connu ne demande plus que deux pressions.

Deux situations, une même leçon. L’écran n’a fonctionné qu’une fois la personne placée en premier. C’est le rôle d’un processus de design et la raison d’être de listes comme la liste de contrôle du processus de design de Barbara Vam. Elle réunit 64 méthodes dans les cinq phases du design thinking. Ce guide les reprend toutes, dans son ordre, avec ce que leur pratique m’a appris.

À retenir

• Le design thinking comprend cinq phases : comprendre, définir, imaginer, prototyper, tester. Le parcours est itératif. Un test raté ramène généralement à la définition, pas au début.
• Aucun projet n’utilise les 64 méthodes. Chaque phase repose sur une ou deux méthodes essentielles. Les ignorer revient à deviner.
• Comprendre : interrogez les personnes sur la dernière fois qu’elles ont accompli la tâche, puis classez leurs propos dans un diagramme d’affinités.
• Définir : un énoncé du problème et des questions « comment pourrions-nous », avant d’ouvrir Figma.
• Imaginer : dessinez le flux utilisateur avant les écrans, puis triez les idées avec une matrice de priorisation.
• Prototyper : construisez le minimum qui répond à la question ouverte. Transmettez les états, pas seulement les écrans.
• Tester : observez cinq personnes. Mesurez avec le SUS. Réservez les tests A/B aux produits qui ont assez de trafic.
• L’IA aide à rédiger, classer et vérifier. Elle ne remplace pas la personne pour qui vous concevez.

Comment lire ce guide

Lisez d’abord l’introduction des cinq chapitres : le rôle de chaque phase et les conséquences quand une équipe l’ignore. Utilisez ensuite les méthodes comme référence. Chacune explique sa nature, quand elle mérite le temps investi, comment la mener, ce qu’elle produit et l’erreur habituelle. Lorsqu’une méthode se prête à l’IA, un court paragraphe explique comment utiliser Claude et quoi vérifier.

Les modèles gratuits partagent un exemple détaillé : Bunn, une application de café fictive, et Rana, une designer produit à Amman qui commande du café pour son équipe.

Sommaire

1. Quelles sont les cinq phases du processus de design ?
2. Comprendre : que font réellement les personnes ?
3. Définir : quel est précisément le problème ?
4. Imaginer : comment passer de nombreuses idées à une seule ?
5. Prototyper : que construire avant de savoir ?
6. Tester : comment savoir si cela fonctionne ?
7. Quels modèles utiliser à chaque phase ?
8. Questions fréquentes

Quelles sont les cinq phases du processus de design ?

L’Interaction Design Foundation décrit le design thinking comme un processus itératif et non linéaire qui aide à comprendre les utilisateurs, interroger les hypothèses, redéfinir les problèmes et créer des solutions. Cinq phases, chacune répondant à une question.

Un test qui échoue sur les formulations ramène au prototype. Si personne ne veut du produit, il ramène à la définition.

Comprendre : que font réellement les personnes ?

Comprendre, c’est cesser de deviner : qui sont les personnes, que font-elles aujourd’hui, à quel coût et avec quels mots ? Une hypothèse fausse repérée ici coûte une conversation. Après le lancement, elle coûte le développement.

Les équipes sautent cette phase parce qu’elles pensent déjà savoir. Sur Wfrah, les éleveurs eux-mêmes étaient convaincus que le marché était en cause. Les entretiens ont pourtant révélé leurs angles morts. Sans cette phase, la première version traduit l’avis de l’équipe et la deuxième sert à le découvrir.

Définir l’objectif

Une phrase précise ce que le projet doit changer et comment le constater. « Les clients connus gagnent des points en moins de dix secondes » est un objectif. « Améliorer l’expérience de caisse » est un souhait. Rédigez-la avec la personne responsable du résultat, avec la mesure qui le prouverait, avant toute recherche. Vous obtenez un filtre : chaque méthode suivante sert l’objectif ou attend. L’erreur consiste à nommer une solution, comme « construire une application de fidélité ». Le design sprint de GV répond aux questions métier par le design, le prototypage et les tests en cinq jours. Il commence de la même façon : un accord sur l’objectif à long terme avant le premier croquis.

Entretiens utilisateurs

Un entretien utilisateur, c’est une personne et une conversation sur ce qu’elle a fait, avec ses mots. Le guide des entretiens utilisateurs de Nielsen Norman Group décrit une démarche de questions, d’écoute et de relances pour comprendre les utilisateurs, leurs expériences et leurs besoins. Il en rappelle la limite : les données dépendent de la qualité de l’intervieweur, et les questions orientées les faussent.

L’entretien est utile chaque fois que vous ne savez pas expliquer un comportement. Pour savoir combien de personnes l’adoptent, utilisez un questionnaire.

Comment procéder

1. Écrivez d’abord la question de recherche : « Comment les éleveurs choisissent-ils l’alimentation ? » Chaque question du guide doit la servir.
2. Recrutez cinq à huit personnes du public réel. Pas des collègues ni des amis bienveillants.
3. Interrogez le passé récent, jamais le futur. « Racontez la dernière fois que vous avez commandé du café pour l’équipe » produit un récit. « Utiliseriez-vous une commande groupée ? » produit un oui poli.
4. Relancez chaque réponse : pourquoi, comment, puis que s’est-il passé ? Barbara Vam le résume en trois mots : quoi, comment, pourquoi.
5. Gardez le silence après chaque réponse. La partie utile vient après la pause.
6. Notez les citations mot pour mot. La reformulation laisse entrer votre avis.

Ce que vous obtenez : des récits, des citations exactes, le vocabulaire des personnes et les solutions de fortune qu’elles ont créées faute d’outil adapté.

L’erreur fréquente : présenter votre idée. Dès cet instant, l’entretien devient commercial et les personnes ménagent vos sentiments.

Le guide d’entretien et les notes gratuits comptent 18 questions en cinq parties, de l’introduction à « y a-t-il quelque chose que j’aurais dû demander ? ».

Avec Claude. Collez la question de recherche et demandez : « Rédigez un guide d’entretien de 30 minutes sur la dernière fois que cette personne a accompli la tâche. Aucune question hypothétique, aucune question nommant une fonctionnalité. Signalez toute question qui suggère sa réponse. » Supprimez ensuite tous les « utiliseriez-vous » restants. Ne laissez jamais un modèle jouer l’utilisateur : il restitue la moyenne de ses lectures.

Entretiens avec les parties prenantes

La même conversation avec les personnes responsables du budget, du système ou du risque. Le guide des entretiens avec les parties prenantes de Nielsen Norman Group explique qu’ils apportent le contexte, les objectifs métier et davantage de soutien au projet.

Menez-les avant que le brief se fige. Demandez ce que serait la réussite, ce qui a déjà échoué et ce qui inquiète. Sur Wfrah, le fondateur avait nommé l’obstacle avant le premier éleveur : la méfiance envers la technologie. Vous obtenez les contraintes jamais écrites. L’erreur est de prendre la parole du plus haut responsable pour de la recherche utilisateur.

Lean canvas

Une page expose le problème, les segments clients, la solution, la valeur distinctive, les canaux, les revenus, les coûts, les indicateurs clés et l’avantage difficile à copier. Barbara Vam le présente comme un moyen de documenter le problème et de faire émerger les hypothèses à valider.

Utilisez-le tant que le produit reste un pari. Évitez-le pour la refonte d’un produit déjà rentable. Vous identifiez l’hypothèse la plus risquée, à tester en premier. Marquez les cases qui relèvent de la supposition. Ce sont les plus utiles.

Questionnaires

Des questions fixes envoyées à de nombreuses personnes. Utilisez-les pour mesurer la fréquence d’un phénomène après que les entretiens l’ont expliqué. Sinon, vous écrirez les réponses selon vos propres idées et mesurerez très précisément vos hypothèses.

Restez sous dix questions et faites un essai avec deux personnes. Vous obtenez des chiffres et quelques raisons. Les 28 conseils pour les questionnaires qualitatifs de Nielsen Norman Group recommandent les questions ouvertes pour approfondir, et un essai avant diffusion pour corriger les problèmes.

Analyse des données

Lire l’existant : demandes au support, ventes, recherches, avis sur l’application, études passées. C’est le moins coûteux, donc le point de départ. Vous savez où regarder et quelles premières questions poser.

Pour Déconstruction, deuxième volet, nous avons vérifié dans l’ordre 179 startups MENA financées. 44 pour cent n’avaient pas de site en arabe. Aucun entretien n’aurait donné ce chiffre. Une lecture attentive des données publiques l’a fait. L’erreur est de s’arrêter au chiffre. Les données disent où les personnes abandonnent, jamais pourquoi.

Indicateurs

Les quelques mesures qui montrent si l’expérience s’améliore : réussite de la tâche, durée, conversion, fidélisation, satisfaction. Choisissez-les au début et relevez leur valeur actuelle pour disposer d’une référence après le lancement. Le guide de comparaison UX de Nielsen Norman Group décrit précisément cette mesure par rapport à une référence pertinente.

À la caisse Dot, la spécification comptait les pressions par client connu : six avant, deux après. Choisissez des mesures liées au résultat utilisateur, comme l’explique personne ne veut de votre produit. Un indicateur limité aux clics récompense le mauvais design.

Concurrents

Utilisez les produits dont vos utilisateurs dépendent aujourd’hui, y compris le tableur, le carnet et le groupe WhatsApp. Consacrez-y tôt un après-midi et notez leurs points forts et leurs faiblesses. L’argument de Nielsen Norman Group pour les évaluations comparatives d’utilisabilité : observer ce qui fonctionne ailleurs évite de construire des fonctions inutiles.

Vous obtenez les habitudes déjà attendues et les besoins mal couverts. L’erreur est de regarder uniquement les concurrents directs. Pour un éleveur, le vrai concurrent est le carnet de son père.

Groupes de discussion

Six à neuf personnes échangent sur un sujet avec un animateur pendant environ deux heures. L’article de Jakob Nielsen sur les groupes de discussion pose clairement leur limite : ils montrent ce que les personnes disent faire, pas ce qu’elles font. Ils servent à découvrir leurs attentes, pas à évaluer l’utilisabilité.

Utilisez-les pour les attitudes, le vocabulaire et la dynamique collective. Jamais pour juger un design. La personne la plus sonore donne la réponse et les autres approuvent.

Observations

Regardez les personnes accomplir la tâche dans leur cadre habituel : au comptoir, dans l’enclos, sur leur téléphone dans une mauvaise lumière. Faites-le chaque fois que l’environnement influence le travail. L’article de Nielsen Norman Group sur les études de terrain défend la sortie du bureau pour découvrir l’inattendu.

Sur Wfrah, les couleurs et les caractères ont été adaptés au soleil fort et à la faible lumière, car les éleveurs ouvrent l’application dans l’enclos. Vous découvrez les astuces devenues si habituelles qu’ils ne les mentionnent plus. L’erreur est d’aider. Votre rôle est d’observer la difficulté.

Diagrammes d’affinités

Un diagramme d’affinités reprend toute la recherche, un constat par note, puis regroupe les notes jusqu’à voir apparaître des thèmes. Le guide des diagrammes d’affinités de Nielsen Norman Group décrit ce regroupement d’observations liées et son intérêt pour la recherche comme pour les idées d’atelier. Il le distingue du tri de cartes, une méthode de recherche sur la navigation, et non un classement de vos notes.

Faites-le juste après la recherche. Sinon, l’entretien le plus marquant emporte le débat. C’est généralement le plus extrême.

Comment procéder

1. Notez une observation par fiche, si possible avec les mots du participant et son identifiant.
2. Étalez toutes les notes. Ne partez pas de catégories.
3. Regroupez-les en silence. Cela évite que la personne la plus haut placée décide des thèmes à voix haute.
4. Nommez chaque groupe par une phrase constat, comme « Les frais de livraison apparaissent tard et semblent trompeurs », plutôt que « Prix ».
5. Comptez les participants par thème. Le propos d’une seule personne reste une anecdote.

Ce que vous obtenez : cinq ou six thèmes, chacun étayé par plusieurs personnes.

L’erreur fréquente : écrire vos interprétations. « Les utilisateurs veulent de la transparence » est votre conclusion. « Les frais apparaissent au paiement, après tous mes choix » est une donnée.

Le diagramme d’affinités gratuit existe en arabe et en anglais, en clair et en sombre.

Avec Claude. Collez les transcriptions et demandez : « Extrayez chaque observation sur une ligne avec l’identifiant du participant et une citation exacte. Proposez ensuite des groupes. Ne transformez pas le propos d’un seul participant en thème. » Vérifiez que chaque note renvoie à une vraie citation et qu’aucun thème n’a été inventé. Les modèles savent classer. À vous de repérer les conclusions plausibles qui comblent les trous.

Exploration du contexte

Les participants préparent de petits exercices avant la séance : journal, photos de leur journée, collage. Ils vous expliquent ensuite leur travail. L’Interaction Design Foundation présente l’exploration du contexte comme un moyen de révéler les besoins et d’inspirer le design.

Utilisez-la pour ce qui se dit difficilement : habitudes, émotions, environnement d’une tâche. Vous découvrez la vie autour de l’action. Ne sautez jamais l’échange final : les photos disent peu sans leur explication.

Définir : quel est précisément le problème ?

Définir transforme un mur de constats en décision : quel problème, pour qui et pourquoi maintenant ? C’est la phase la plus resserrée et la plus souvent expédiée, car tout le monde veut dessiner. L’ignorer produit un outil qui résout à moitié plusieurs petits problèmes.

Sur Wfrah, cette phase a donné un persona, Awad, et un énoncé : les éleveurs traditionnels hésitent à adopter de nouveaux outils malgré des gains réels, tout en peinant avec la nutrition, l’environnement et l’administration. Chaque écran devait donc gagner leur confiance avant de demander quoi que ce soit. Une phrase a suffi à fixer cette règle.

Personas

Un persona est le profil fictif et réaliste d’un type d’utilisateur, issu de la recherche : objectifs, contexte, comportements, frustrations et citation. L’article sur les personas de Nielsen Norman Group explique qu’une personne concrète retient mieux l’attention qu’une série de chiffres. Un bon persona repose sur une recherche concrète.

Il est utile lorsque chacun dit « l’utilisateur » en pensant à quelqu’un d’autre. Avant tout échange avec des utilisateurs, c’est une fiction accompagnée d’une photo de banque d’images.

Comment procéder

1. Partez du diagramme d’affinités. Chaque persona doit regrouper des comportements observés, pas une catégorie démographique.
2. Reprenez les objectifs et frustrations dans les mots des participants.
3. Ajoutez le contexte qui change le design : appareil, lieu, urgence, langue.
4. Choisissez une citation qui exprime la tension. Awad trouve la technologie trop compliquée, mais accepte d’essayer si elle aide. Cette tension constituait le brief.
5. Créez un persona principal, deux au maximum. Cinq personas signifient qu’aucun choix n’a été fait.

Ce que vous obtenez : une personne pour qui concevoir et une question à chaque revue : Awad comprendrait-il cet écran ?

L’erreur fréquente : emprunter le persona d’un modèle. Traduit de l’anglais, il conserve les attentes de son auteur anglophone. La version arabe du modèle de persona gratuit a donc été écrite en arabe, avec une biographie qui sonne comme celle d’une personne d’Amman.

Avec Claude. Donnez le diagramme et demandez : « Rédigez un persona uniquement à partir des faits de ces notes. Associez chaque ligne aux identifiants des participants concernés. Laissez vides les champs non documentés. » Supprimez toute ligne sans identifiant. Un modèle ajoutera volontiers un loisir et un chien.

Carte d’empathie

Quatre quadrants : ce que l’utilisateur dit, pense, fait et ressent. Remplissez-les en équipe juste après les entretiens. L’article sur les cartes d’empathie de Nielsen Norman Group explique qu’elles construisent une compréhension partagée et révèlent les lacunes. Le plus utile se situe entre les paroles et les actes : Rana juge les frais tardifs trompeurs et les vérifie deux fois avant de payer. Modèle gratuit de carte d’empathie. L’erreur consiste à inventer les pensées et les émotions. Sans preuve, laissez les cases vides.

Carte du parcours utilisateur

Cette carte couvre toute l’expérience, de la découverte du produit à l’abandon ou au retour, avec les actions, pensées et émotions à chaque étape. Le guide de cartographie des parcours de Nielsen Norman Group la définit comme la visualisation du processus suivi pour atteindre un objectif : une chronologie d’actions enrichie des pensées et émotions.

Utilisez-la quand le problème traverse plusieurs canaux ou équipes : une vidéo, une application, un livreur, une notification. Évitez-la si tout tient dans un écran.

Comment procéder

1. Choisissez un persona et un objectif. Un parcours pour tout le monde ne sert personne.
2. Nommez les étapes selon les utilisateurs, pas selon votre organigramme.
3. Renseignez les actions et points de contact issus de la recherche, puis les pensées entre guillemets.
4. Tracez les émotions étape par étape. Commencez par le point le plus bas.
5. Ajoutez une piste d’amélioration et un indicateur par étape pour déboucher sur des actions.

Ce que vous obtenez : le moment le plus pénible. Pour Bunn, c’est la commande : le code arrive en retard et le champ ne le lit pas.

L’erreur fréquente : cartographier le parcours prévu plutôt que le parcours réel. Carte gratuite du parcours client, en arabe et en anglais, en clair et en sombre.

Récits utilisateurs

« En tant que [utilisateur], je veux [action] afin de [résultat]. » Rédigez-les lorsque le travail entre dans le carnet de tâches pour conserver la personne et sa raison derrière chaque élément. Le guide GOV.UK sur la rédaction de récits utilisateurs les considère comme la trace de tout ce qu’une équipe doit faire pour répondre aux besoins. L’erreur est d’oublier le « afin de ». Sans lui, personne ne sait si la fonction a servi.

Énoncé du problème

Une phrase dit qui rencontre une difficulté, à quel moment et à quel coût. L’article sur les énoncés de problème de Nielsen Norman Group constate que les équipes qui commencent sans énoncé s’égarent. Certaines étudient directement des solutions, ce qui n’est plus de la découverte. Écrivez-en un pour chaque projet. C’est la précaution la moins chère du guide.

Comment procéder

1. Remplissez cinq champs à partir de la recherche : utilisateur, doit, parce que, mais, ce qui lui donne le sentiment de.
2. Lisez la phrase à voix haute. Si elle ressemble à une demande de fonction, le « parce que » manque.
3. Vérifiez chaque partie dans le diagramme d’affinités. Elle doit renvoyer à un thème.
4. Accordez-vous avec les personnes qui construiront. Si elles ne peuvent pas la répéter, elle est trop longue.

Ce que vous obtenez : le périmètre. « Rana doit commander du café pour trois personnes en moins d’une minute parce que la réunion de 10:00 commence à l’heure, mais les frais de livraison n’apparaissent qu’au paiement, ce qui lui donne le sentiment d’être trompée. » Tout ce qui ne sert pas cette phrase attend.

L’erreur fréquente : cacher une solution dans l’énoncé. « Les utilisateurs ont besoin d’un meilleur tableau de bord » donne la réponse sans poser le problème. Modèle gratuit d’énoncé du problème.

Avec Claude. Collez les thèmes et demandez trois énoncés au format des cinq champs, chacun citant son thème d’origine. Choisissez ensuite vous-même. Le modèle propose des formulations. Vous choisissez le problème.

Formulation d’hypothèse

« Nous pensons que [changement] pour [utilisateurs] produira [résultat]. Nous le saurons quand [signal]. » Utilisez-la lorsqu’une solution existe et doit être testée plutôt que défendue. Fixez le critère de réussite avant les résultats pour éviter de le déplacer. Pour Dot : nous pensons que demander le téléphone d’abord réduira le passage d’un client connu à deux pressions. Nous le saurons quand un caissier le fera sur l’écran livré.

Récits

Un court récit de la journée d’une personne, avec le produit dedans. Il montre aux parties prenantes où le produit entre dans une habitude réelle. Ancrez-le dans la recherche. L’article de Nielsen Norman Group sur les biais narratifs prévient que les professionnels UX accordent trop de crédit aux détails narratifs et aux explications causales. Un bon récit convainc même quand il est faux. Chaque phrase doit donc renvoyer à une action réelle.

Méthode HMW

« Comment pourrions-nous » reformule chaque problème en question assez ouverte pour plusieurs réponses, assez précise pour agir. L’article sur les questions HMW de Nielsen Norman Group explique que ce format freine les solutions favorites sans lien avec les constats et recentre l’idéation sur le bon problème.

Utilisez-le à la fin de la définition, comme passage à l’idéation. Sans énoncé du problème, il ne fait que transformer des suppositions en questions.

Comment procéder

1. Prenez l’énoncé du problème et chaque thème fort du diagramme.
2. Écrivez une question par difficulté : « Comment pourrions-nous montrer les frais avant que Rana choisisse une boisson ? »
3. Vérifiez le périmètre. « Améliorer le café » est trop large. « Ajouter les frais dans l’en-tête » est une solution déguisée.
4. Sous chaque question, expliquez en une ligne ce qu’elle ouvre, sans nommer de fonction.
5. Votez pour les trois questions à explorer.

Ce que vous obtenez : des briefs d’idéation liés à des difficultés réelles. L’erreur fréquente est d’en garder trop. Vingt HMW forment un carnet de tâches, pas un brief. Le modèle gratuit d’énoncé du problème en contient six. Avec Claude, demandez de reformuler vos questions sans solution nommée, chacune limitée à un moment du parcours. Vérifiez ensuite que le problème n’a pas changé discrètement.

Cartographie des hypothèses

Listez tout ce qui doit être vrai pour que l’idée fonctionne, puis placez chaque point sur deux axes : importance et niveau de preuve. Faites-le avant tout développement coûteux. Le coin supérieur gauche, important et non démontré, indique l’hypothèse à tester en premier. Pour Wfrah, la plus risquée était que les éleveurs fassent confiance à un chiffre d’application. La recherche montrait une confiance faible. L’application présente donc sa valeur et les récits d’autres éleveurs avant de demander quoi que ce soit.

Analyse des tâches

Décomposez un objectif en toutes les étapes et décisions nécessaires, y compris hors du produit. L’article sur l’analyse des tâches de Nielsen Norman Group la définit comme l’étude systématique de l’accomplissement des tâches pour atteindre un objectif. Utilisez-la pour les tâches complexes ou expertes. Vous identifiez les étapes à supprimer, fusionner ou automatiser. L’optimisation de Dot l’illustre : chaque pression a été comptée, puis le passage du téléphone au montant a été automatisé dès le numéro complet.

Tâches à accomplir

L’approche « jobs to be done » décrit le progrès recherché dans une situation, quel que soit le produit utilisé. Une personne engage un produit pour une tâche et le remplace s’il échoue. J’en parle dans personne ne veut de votre produit, avec l’histoire du milkshake de Christensen : les nouveaux parfums ne changeaient rien, jusqu’à comprendre que le milkshake servait à occuper un long trajet ennuyeux.

Utilisez-la quand les données démographiques n’expliquent pas l’achat. L’article de Nielsen Norman Group sur les personas et tâches à accomplir apporte une nuance : les tâches ciblent les besoins et résultats, mais ne créent pas l’empathie d’un bon persona. Les deux se complètent.

Comment procéder

1. Repérez dans les entretiens le moment où la personne décide d’agir.
2. Écrivez trois lignes : quand je, je veux, pour pouvoir.
3. Utilisez ses mots. « Quand j’ouvre Bunn à 9:40 avec deux commandes criées depuis les bureaux voisins » décrit une tâche. « Quand j’utilise la commande » décrit un produit.
4. Listez ce qu’elle utilise aujourd’hui pour cette tâche. Ce sont vos concurrents.

Ce que vous obtenez : une tâche qui survit à la refonte et une liste de concurrents incluant le groupe WhatsApp.

L’erreur fréquente : choisir la mauvaise échelle. « Boire du café » est trop large pour concevoir ; « appuyer sur recommander » est trop précis pour apprendre.

Analyse concurrentielle

La version structurée de l’examen des concurrents : fonction par fonction, flux par flux, comparés au problème défini. Barbara Vam cite ses formes variées, de l’analyse visuelle au SWOT. Faites-la une fois le problème clair pour comparer ce qui compte. Vous savez où suivre le marché et où vous distinguer. Avec Claude, fournissez l’énoncé et les captures de trois flux concurrents. Demandez un tableau sur leur traitement du même moment, puis vérifiez chaque case : les modèles décrivent parfois des fonctions inexistantes.

Imaginer : comment passer de nombreuses idées à une seule ?

C’est la phase la plus large : 19 méthodes, en deux temps souvent confondus, ouvrir puis trier. La liste propose de nombreuses façons de produire des idées, aucune pour choisir. J’en ajoute donc une à la fin.

Sans ouverture, l’équipe construit sa première idée, généralement la plus évidente. Sans tri, elle livre douze fonctions inachevées.

Séances de remue-méninges

Le groupe produit un maximum d’idées sans les juger immédiatement. L’article sur le remue-méninges de l’Interaction Design Foundation insiste sur le problème clairement défini. C’est ce qui fait fonctionner la méthode. Apportez les HMW. Faites écrire chacun seul pendant cinq minutes avant toute discussion pour éviter qu’une voix impose la direction. Vous obtenez du volume. L’erreur est de débattre pendant la production.

Cartes mentales

Un sujet central et des idées liées en branches. Seul ou à deux, explorez rapidement un domaine. La page sur les cartes mentales de l’Interaction Design Foundation les présente comme une visualisation des idées et de leurs liens. Vous découvrez des connexions qu’une liste masque, parfois une première navigation.

Scénarimages

Quelques cases de bande dessinée montrent un utilisateur face au problème, puis à la solution. Dessinez-les avant les écrans pour vérifier que l’idée tient dans une situation réelle, comme un éleveur aux mains sales dans l’enclos. L’article sur les scénarimages de Nielsen Norman Group souligne leur clarté et leur capacité à retenir l’attention. Une partie prenante comprend le récit en une minute. Des personnages bâtons suffisent.

Tri de cartes

Les participants regroupent vos contenus en catégories qui leur semblent logiques. En tri ouvert, ils nomment aussi les catégories. L’article sur le tri de cartes de Nielsen Norman Group explique qu’il révèle les modèles mentaux liés à l’architecture de l’information : au moins 15 participants en qualitatif, 30 à 50 en quantitatif. Les noms proposés sont rarement définitifs. Pour vérifier une navigation, il recommande le test d’arborescence plutôt que le tri fermé.

Faites-le avant toute navigation comptant plus d’une douzaine d’éléments.

Comment procéder

1. Écrivez 30 à 60 cartes, un contenu par carte, en mots simples. Évitez les noms envisagés pour ne pas tester uniquement ces noms.
2. Lancez un tri ouvert : les participants regroupent et nomment. Demandez-leur de penser à voix haute.
3. Repérez les cartes souvent réunies et celles placées partout. Ces dernières posent les plus gros problèmes de nommage.
4. Proposez une structure, puis vérifiez-la avec un test d’arborescence.

Ce que vous obtenez : les regroupements attendus et les contenus qui resteront difficiles à placer.

L’erreur fréquente : trier vous-même. Le modèle mental de l’équipe a justement créé la navigation confuse.

Parcours utilisateur

Le chemin principal vers un objectif dans le produit, à un niveau plus global que le flux. L’article de Nielsen Norman Group sur les parcours et flux utilisateurs explique qu’ils décrivent tous deux un processus vers un objectif, mais diffèrent par leur périmètre, leur rôle et leur format. Sur Wfrah, le parcours suivait Awad de la découverte au doute, puis à l’essai et à la décision. Les preuves arrivaient précisément au moment de l’hésitation. Utilisez-le pour convenir des routes principales avant les détails.

Flux utilisateur

Un flux représente chaque écran, décision et branche d’une tâche par des cases et des flèches. Il révèle les impasses et erreurs cachées par les écrans. Un écran montre uniquement le scénario idéal. Beaucoup de mauvais produits placent un bon écran dans un mauvais flux.

La caisse Dot est mon exemple le plus clair. La première version enchaînait montant, sélecteur de pays, pays, téléphone, génération. Chaque case semblait logique isolément. Dessiné, le coût devenait visible : le clavier téléphonique n’a pas de touche Suivant, donc chaque changement de champ exige une pression. L’optimisation a redessiné le flux : téléphone, montant, ajout des points. Les écrans ont suivi.

Dessinez-le avant les écrans pour toute tâche comportant une décision.

Comment procéder

1. Choisissez une tâche et un persona. Fixez le départ et l’arrivée.
2. Dessinez le scénario idéal, une case par écran ou étape.
3. À chaque étape, demandez ce qui arrive en cas d’échec : saisie invalide, absence de connexion, déconnexion, résultat vide. Chaque réponse forme une branche.
4. Dessinez les décisions en losanges avec un oui et un non. Chaque non doit mener quelque part.
5. Comptez les étapes principales, puis essayez d’en retirer une.

Ce que vous obtenez : la liste complète des écrans et états. Elle dépasse toujours la première estimation.

L’erreur fréquente : dessiner uniquement le scénario idéal, celui qui demande le moins de réflexion. Modèle gratuit de flux utilisateur, avec les chemins oui et non.

Avec Claude. Décrivez la tâche, collez le scénario idéal et demandez : « Listez tous les échecs à chaque étape : saisie invalide, délai dépassé, hors ligne, double pression, accès refusé, données vides. Pour chacun, indiquez ce que voit l’utilisateur et la suite. » Vérifiez que chaque état nomme le champ et la correction, comme Dot : « Aucun ajout. Il manque 1 chiffre au téléphone. »

Architecture de l’information

L’architecture de l’information organise, nomme et relie les contenus. L’article de Nielsen Norman Group sur l’architecture et la navigation distingue l’ossature de l’information, documentée par tableaux et schémas, de la navigation, partie visible qui y donne accès.

Sur Wfrah, elle couvrait les troupeaux, le calculateur nutritionnel, les conseils d’environnement, le marché, les connaissances et le compte. La présentation progressive montrait l’essentiel au débutant et permettait à l’expert d’aller plus loin. Sur Zain Cash, les indices en arabe apparaissaient là où les attend un lecteur de droite à gauche.

Comment procéder

1. Inventoriez chaque contenu et chaque tâche.
2. Regroupez-les selon le tri de cartes, pas votre organigramme.
3. Nommez chaque groupe avec les mots entendus en entretien.
4. Fixez la profondeur : accessible en une pression ou au niveau suivant.
5. Testez l’arborescence avant le design visuel.

Ce que vous obtenez : une structure pour la navigation et des mots pour les textes. L’erreur fréquente est d’organiser par service interne.

Plan du site

Un schéma de toutes les pages et de leur hiérarchie. Il sert à définir le périmètre, trouver les pages isolées et compter. Le nombre de pages amorce l’estimation du développement. Actualisez-le à chaque livraison.

Plans de service

Une carte de parcours prolongée sous la surface : ce que font les équipes, systèmes et partenaires derrière chaque étape visible. La définition des plans de service de Nielsen Norman Group les présente comme une visualisation des processus organisationnels derrière l’expérience. Utilisez-les pour un produit dépendant des opérations : livraison, assistance, comptoir. Dans Dot, une pression implique le caissier, les contrôles antifraude et le registre. Vous identifiez la panne interne derrière la plainte visible.

Canevas de modèle économique

Neuf blocs sur une page : clients, valeur, canaux, relations, revenus, ressources, activités, partenaires, coûts. Strategyzer publie le canevas gratuitement. Utilisez-le lorsqu’une décision de design change les revenus, par exemple une offre gratuite ou une commission partenaire. Chaque choix rejoint alors le bloc économique qu’il modifie.

La pire idée

L’équipe propose volontairement de très mauvaises solutions, puis les inverse. L’Interaction Design Foundation décrit la pire idée possible comme un moyen de détendre le groupe. Utile quand une séance bloque ou que chacun craint le ridicule. « Cacher les frais jusqu’après le paiement » devient « montrer les frais avant la connexion ».

Crazy 8

Pliez une feuille en huit cases et dessinez huit idées en huit minutes, une minute chacune. Le Design Sprint Kit de Google le place dans la phase de croquis. La limite de temps fait la méthode : personne ne peut peaufiner en une minute, donc personne ne s’attache trop.

Faites-le juste après le vote HMW, avant tout outil de design. Sans question précise, huit croquis de « l’application » deviennent huit logos.

Comment procéder

1. Prenez une question HMW et un écran ou moment.
2. Pliez une feuille A4 trois fois pour obtenir huit cases.
3. Réglez huit minutes. Une idée par case. En silence.
4. Chacun présente sa feuille en deux minutes. Sans critique.
5. Chacun vote avec des points sur les cases à construire, puis la personne responsable tranche.

Ce que vous obtenez : huit pistes sommaires par personne.

L’erreur fréquente : autoriser les cases vides. Vers le cinquième croquis, les idées évidentes s’épuisent et les pistes utiles commencent.

Remettre les hypothèses en question

Listez les convictions partagées sur le problème, puis demandez ce qui change si chacune est fausse. Barbara Vam propose ainsi de retourner les croyances de l’équipe pour regarder le problème autrement. La première caisse Dot supposait que le montant venait d’abord. Interroger cet ordre a permis les deux pressions. Utilisez la méthode lorsque toutes les idées se ressemblent.

Croquis et séances de croquis

Des dessins rapides sur papier, jetables, seul ou en tours chronométrés avec l’équipe. La page de l’Interaction Design Foundation sur les croquis les décrit comme des représentations préliminaires dessinées à la main des résultats de recherche, interfaces et interactions. Faites-les avant tout logiciel : un outil donne trop vite une apparence définitive.

Principes de design produit

Quelques énoncés qui règlent les arbitrages récurrents. L’article sur les principes de design de Nielsen Norman Group les décrit comme des valeurs qui cadrent les décisions et assurent la cohérence entre équipes. Wfrah en avait cinq : attentionné, autonomisant, fiable, efficace, familier. « Efficace » signifiait supprimer des étapes et ajouter de la friction uniquement avant les décisions importantes. Écrivez-les quand le même débat revient. Un principe qui ne permet de rejeter aucune idée décore seulement.

Planche d’ambiance

Images, typographies, couleurs et textures réunies pour fixer une direction visuelle. L’article sur les planches d’ambiance de Nielsen Norman Group les présente comme un outil d’inspiration et de choix. Cherchez hors de votre secteur. Dans notre lecture de 150 dépôts shadcn/ui, la plupart utilisaient deux polices et une couleur principale grise. Une planche limitée aux concurrents produit le même résultat.

Planches de style

Une planche applique polices, couleurs et éléments d’interface, sans mise en page. Les Style Tiles de Samantha Warren ont introduit cette étape entre l’ambiance et la maquette complète. Présentez-en deux ou trois, jamais une : une seule ne permet qu’un oui ou un non.

Guide de style

Les règles écrites de typographie, couleur, espacement, images et ton. Ajoutez la raison de chaque règle pour que le prochain designer puisse la prolonger. Une règle comme éviter le noir pur en mode sombre dure davantage lorsqu’elle explique la fatigue visuelle et la perte de profondeur.

Système de design

Le guide devient composants, jetons et documentation partagés entre design et code. Le guide des systèmes de design de Nielsen Norman Group les définit comme des normes pour gérer le design à grande échelle, réduire les répétitions et créer un langage commun. Le GOV.UK Design System est un exemple public utile. L’investissement se justifie dès que plusieurs équipes ou produits partagent une interface.

C’est l’idée d’ux-skill : compiler un système depuis le brief plutôt que coller partout un modèle. J’explique pourquoi dans les spécifications de marque sont des données d’entraînement. La caisse Dot utilise son système de design. Ses maquettes d’optimisation n’ont inventé aucun jeton : chaque valeur venait du fichier, chaque manque était listé comme ajout. Vous assemblez les écrans au lieu de les redessiner. L’erreur est de construire les composants avant que les motifs se répètent : un système trop précoce fige vos premières suppositions. Le kit de compétence système de design enseigne vos jetons à Claude Code.

Matrice de priorisation

Absente de la liste d’origine, je l’ajoute toujours. Placez chaque idée selon l’impact utilisateur et l’effort de l’équipe. Le coin supérieur gauche, fort impact et faible effort, passe en premier. La matrice oblige à expliquer pourquoi le reste attend. Évaluez l’impact selon la recherche, pas l’enthousiasme.

Matrice de priorisation gratuite.

Prototyper : que construire avant de savoir ?

Un prototype est une question que l’on peut manipuler. Le guide de Nielsen Norman Group sur les prototypes de basse et haute fidélité le qualifie d’hypothèse, une solution possible testée par l’observation. Il rappelle une phrase à afficher dans chaque équipe : jeter du code coûte très cher, jeter un prototype beaucoup moins.

Construisez le minimum qui répond à la question ouverte. Une formulation se teste sur papier. Un geste ou la rapidité exigent du code. La fidélité a un coût : payez-le seulement là où le test l’exige.

Sans cette phase, le produit devient le premier prototype et les vrais clients réalisent le premier test après le lancement.

Prototype papier

Des écrans dessinés sur papier, changés à la main lorsqu’une personne touche du doigt. L’article sur le prototypage papier de Nielsen Norman Group explique qu’il teste les premières idées à faible coût et corrige l’utilisabilité avant de financer une mauvaise réalisation. Utilisez-le pour les premiers tests de flux et de formulation. Les personnes critiquent librement le papier, dont le coût paraît nul. Vous trouvez les problèmes avant le logiciel de design.

Micro-interactions

Les petits retours : bascule, actualisation par glissement, erreur sous un champ. L’article sur les micro-interactions de Nielsen Norman Group explique qu’elles indiquent l’état du système, évitent les erreurs et expriment la marque, chacune avec un déclencheur et un rôle. Concevez-les une fois le flux fonctionnel. Pour Dot, la plus importante est invisible : le curseur passe au montant après le dernier chiffre du téléphone. La spécification a aussi supprimé une apparition animée de 600 millisecondes à chaque visite. Ralentir une caisse chargée n’est pas une finition.

Flux utilisateurs détaillés

Le flux d’idéation enrichi de tous les états : vide, chargement, erreur, réussite, hors ligne, cas limites. Les wireflows de Nielsen Norman Group combinent précisément maquettes filaires et diagrammes. La spécification Dot liste huit états pour un écran, du repos au blocage antifraude et au mode hors ligne, avec contenu visible, focus et action du bouton. Dessinez-les avant la haute fidélité. La liste complète dépasse généralement l’estimation initiale.

Maquettes

Des écrans statiques réalistes, avec le vrai contenu et le design visuel, sans interaction. Ils servent à revoir l’apparence et la longueur des textes dans les deux langues, car les lignes arabes et anglaises coupent rarement au même endroit. Vous validez l’aspect visuel. Le comportement demande toujours un prototype : une maquette approuvée comme « le design » cache tous les états absents.

Prototype interactif

Des écrans liés sur lesquels cliquer ou appuyer, assez proches du réel pour faire oublier leur nature fictive. Le guide GOV.UK sur la création de prototypes les présente comme le moyen d’essayer des idées avec les utilisateurs pendant la construction d’un service.

Utilisez-le pour une question de navigation, de séquence ou de comportement. Pour savoir si quelqu’un veut du produit, un entretien coûte moins cher.

Comment procéder

1. Écrivez la question. « Rana peut-elle lancer une commande groupée sans aide ? » en est une. « L’application fonctionne-t-elle ? » n’en est pas une.
2. Construisez uniquement le chemin testé et les erreurs probables.
3. Utilisez de vrais contenus : prix, noms, arabe. Le faux texte masque les problèmes de mise en page.
4. Testez si possible sur le téléphone du participant. Le grand moniteur du designer teste surtout le moniteur.
5. Corrigez les problèmes évidents entre les séances.

Ce que vous obtenez : des preuves de comportement et des corrections classées par nombre de personnes bloquées.

L’erreur fréquente : tout prototyper. Après un prototype de 60 écrans, l’équipe s’y attache trop pour changer.

Maquettes filaires

Des mises en page de basse fidélité : structure, hiérarchie, contenu, sans style visuel. La page sur les maquettes filaires de l’Interaction Design Foundation les décrit comme des représentations simples de la structure d’interface. Leur intérêt tient à ce qu’elles omettent. Sans couleur, le débat porte sur la place et la priorité. Utilisez-les pour toute hiérarchie d’écran non évidente.

Comment procéder

1. Partez du flux détaillé. Une maquette par écran et état important.
2. Classez le contenu selon la tâche. Pour Dot : téléphone, client, montant, bouton.
3. Marquez une action principale par écran. Si vous ne pouvez pas choisir, l’écran fait deux métiers.
4. Vérifiez la portée du pouce. Le bouton principal de Dot est juste au-dessus du clavier, dans sa zone d’accès. C’est la loi de Fitts : agrandir et rapprocher ce qui compte.
5. Pour un produit arabe, dessinez maintenant la version de droite à gauche. L’inversion tardive casse les mises en page.

Ce que vous obtenez : une ossature convenue avant le débat sur la couleur.

L’erreur fréquente : des maquettes filaires trop finies, évaluées comme du design définitif.

Design haute fidélité

Le design final, avec les vrais textes, données et états. Réalisez-le pour les écrans destinés à être livrés. Chaque valeur doit venir des jetons du système, pour que les développeurs construisent des règles au lieu de mesurer des pixels. Vous obtenez leur référence de construction. L’erreur est de soigner uniquement la réussite et de laisser les erreurs en notes.

Transmission aux développeurs

Tout ce qu’un développeur doit savoir sans deviner : écrans dans l’ordre du flux, liens, états, jetons et comportements. J’en donne la version complète dans la transmission du design. La règle reste la même : c’est un livrable, pas un export. Le développeur est le premier utilisateur de votre fichier.

Prévoyez-la dès le premier écran pour chaque projet transmis au développement.

Comment procéder

1. Classez et nommez les écrans par flux : « Caisse, téléphone invalide », pas « Écran 12 final v3 ».
2. Livrez chaque état avec autant de soin que le scénario idéal. Dot possède un tableau : état, vue du caissier, focus, libellé du bouton.
3. Écrivez les règles des textes. Sur Dot, chaque erreur commence par la vérité du registre, « Aucun ajout. », car le caissier veut d’abord savoir si l’opération a eu lieu.
4. Écrivez les règles invisibles : ne jamais effacer la saisie en cas d’erreur ; revenir au repos après 30 secondes pour ne pas montrer le solde précédent au client suivant.
5. Restez disponible pendant le développement et examinez la version de préproduction.

Ce que vous obtenez : moins de questions en cours de sprint.

L’erreur fréquente : livrer des images. Un écran montre quoi construire, pas son comportement.

Avec Claude. Collez le flux détaillé et demandez : « Pour chaque écran et état, écrivez la ligne de transmission : contenu visible, focus, action des boutons, délai dépassé, double pression. Signalez les états non définis. » Ces lacunes sont les questions qu’un développeur aurait posées au troisième jour.

Documentation du design

La trace des raisons : décisions, pistes écartées et recherches. Restez bref et écrivez au fil du travail. La spécification Dot explique en un paragraphe pourquoi le téléphone vient d’abord : le clavier numérique iOS n’a pas de touche Suivant et seul un champ de longueur connue peut avancer automatiquement. Six mois plus tard, personne ne doit deviner.

Prototypes HTML/JS

Un prototype codé dans le support réel. Utilisez-le pour les données réelles, la vitesse, l’animation, le clavier ou un geste impossible à simuler. Le passage automatique et le clavier n’existent pas dans une image statique : le nombre de pressions Dot ne pouvait être prouvé qu’en code. Avec Claude Code et un système de design, coder est souvent plus rapide que relier des écrans. Le guide gratuit Claude Code et Figma explique la configuration. L’erreur est de livrer le prototype sans tests.

Tester : comment savoir si cela fonctionne ?

À ce stade, l’équipe cesse d’être juge. Le guide des tests d’utilisabilité de Nielsen Norman Group explique que même les meilleurs designers doivent observer de vraies personnes et itérer pour réussir une interface.

Sans tests, les problèmes arrivent par le support, un client mécontent après l’autre, une fois le budget dépensé.

Tests d’utilisabilité

Un animateur donne une tâche réaliste à une personne, puis observe en silence sa tentative.

Combien de personnes ? L’article de Nielsen sur les tests avec 5 utilisateurs montre que les cinq premiers trouvent environ 85 pour cent des problèmes. Tout trouver demande au moins 15 personnes, mais mieux vaut trois séries de cinq avec corrections entre les séries.

Testez à chaque étape, du papier au produit livré. Ce n’est pas un test de préférence.

Comment procéder

1. Écrivez l’objectif, puis cinq tâches réalistes avec condition de réussite et durée limite : « Vous êtes au bureau et voulez un flat white. Avant de choisir, trouvez les frais de livraison. »
2. Recrutez cinq personnes correspondant au persona. Faites une séance pilote pour corriger les tâches.
3. Demandez de penser à voix haute. N’aidez pas. À « que dois-je faire ? », répondez « que feriez-vous si je n’étais pas là ? ».
4. Notez réussite, réussite partielle ou échec, avec durée et citation au moment du blocage.
5. Documentez chaque constat : gravité, emplacement, citation et correction. Traitez d’abord les problèmes critiques.

Ce que vous obtenez : les blocages, leurs raisons et la citation qui convainc la partie prenante persuadée que tout allait bien.

L’erreur fréquente : tester avec des collègues. Ils savent déjà ce que le bouton doit faire. Modèle gratuit de test, avec plan, guide et tableau des constats.

Avec Claude. Après les séances, collez les notes : « Regroupez les constats. Pour chacun, donnez la gravité (critique bloque, grave ralentit, mineur gêne), les participants concernés et une citation exacte. Aucun constat sans citation. » Fixez ensuite vous-même la gravité. Le modèle ne sait pas quel retard coûte de l’argent.

Observation en immersion

Suivez une personne pendant une vraie journée d’utilisation. La page de l’Interaction Design Foundation sur l’observation en immersion décrit une technique ancienne, adoptée plus récemment en recherche UX. Utilisez-la pour les outils professionnels et services longs, comme une journée de caisse. Vous voyez comment le produit s’intègre au reste du travail. Convenez des moments de questions pour ne pas interrompre ce que vous observez.

Tests A/B

Deux versions en ligne reçoivent aléatoirement le trafic réel et sont comparées sur un indicateur. Le guide des tests A/B de Nielsen Norman Group les définit comme une méthode quantitative pour identifier la meilleure variante selon une mesure métier prédéfinie. Idéalement, un seul élément change.

Ils servent avec assez de trafic et un objectif mesurable. La taille d’échantillon dépend du taux initial et du plus petit changement à détecter. Sur un petit produit, il faut parfois des mois pour une réponse qu’un test d’utilisabilité donne en une semaine.

Comment procéder

1. Partez d’une hypothèse issue de la recherche : « Montrer les frais dans l’en-tête augmentera le passage du menu au paiement. »
2. Changez une seule chose, sinon vous ne saurez pas laquelle a agi.
3. Fixez avant le lancement l’indicateur, l’échantillon et la durée.
4. N’arrêtez pas dès qu’une courbe plaît. Les consultations précoces produisent de faux gagnants.
5. Gardez la variante uniquement si son avance est statistiquement significative.

L’erreur fréquente : prendre le gagnant pour une explication. L’A/B dit quelle version gagne. L’utilisabilité explique pourquoi l’autre perd.

Test SUS

La System Usability Scale contient dix affirmations, chacune avec cinq réponses possibles, juste après une séance d’utilisabilité. Le guide SUS de MeasuringU rappelle sa publication par John Brooke en 1986 comme mesure rapide, puis sa validation sur matériel, logiciels, sites et téléphones. Le score moyen de 500 études est de 68.

Utilisez-la pour comparer les séries. Elle ne dit pas ce qui ne va pas ; la séance le montre.

Comment procéder

1. Gardez les dix affirmations standard. Traduisez soigneusement pour un test en arabe et conservez l’ordre.
2. Donnez-les après les tâches, avant la discussion.
3. Calculez : pour les éléments impairs, retirez 1 à la réponse ; pour les pairs, retirez la réponse de 5. Additionnez les dix résultats et multipliez par 2.5. Le total va de 0 à 100.
4. Comparez à 68 et à la série précédente.

L’erreur fréquente : lire un pourcentage. MeasuringU rappelle que 68 est la moyenne. 70 se situe juste au-dessus, pas à « 70 pour cent utilisable ».

Évaluation heuristique

Quelques évaluateurs examinent l’interface selon des principes, souvent les dix heuristiques de Jakob Nielsen, publiées en 1994. Le guide de Nielsen Norman Group pour mener cette évaluation souligne son efficacité sur les problèmes évidents, presque toute interface et les prototypes, surtout tôt dans le projet.

Utilisez-la comme contrôle peu coûteux avant les utilisateurs et sur les écrans hérités. Les experts trouvent les règles enfreintes ; les utilisateurs, ce qui gêne leur journée.

Comment procéder

1. Fixez le périmètre : un persona, une tâche, un appareil.
2. Chaque évaluateur suit seul la tâche comme un utilisateur, puis la reprend heuristique par heuristique.
3. Gardez les évaluations séparées jusqu’à leur fin, comme le recommande le guide.
4. Fusionnez les constats, citez les heuristiques et évaluez la gravité.
5. Corrigez les problèmes critiques, puis testez avec les utilisateurs.

Ce que vous obtenez : une liste de violations classées par gravité en un après-midi.

L’erreur fréquente : un seul évaluateur. Chacun repère des problèmes différents. Avec Claude, fournissez une capture et les dix heuristiques. Demandez les violations avec principe, élément et correction. Traitez-le comme un évaluateur supplémentaire. Il comprend mal ce qui dépend du flux autour de l’écran.

Analyse des usages

Les données du produit en ligne : abandons, recherches, chemins suivis. Lisez-les en continu. L’article de Nielsen Norman Group sur l’analyse des usages en UX souligne sa valeur en complément de la recherche qualitative. Les données montrent où se trouve le problème. Les tests montrent sa nature.

Tests de performance

Mesurez le chargement et la réactivité sur de vrais appareils et réseaux. L’article de Nielsen Norman Group sur les temps de réponse fixe trois seuils : 0.1 seconde paraît instantané, 1 seconde préserve le fil, 10 secondes atteint la limite de l’attention. GOV.UK propose un guide pratique des tests de performance frontend. La vitesse était un des trois principes de la refonte Zain Cash, surtout consultée sur téléphone. Dot recherche le client pendant la saisie du montant pour ne pas attendre le réseau. Testez sur un téléphone moyen en données mobiles, pas sur la fibre du bureau.

Observation

Observer le produit livré dans son usage et son contexte réels. Faites-le après le lancement, une fois les habitudes installées. L’enquête contextuelle de Nielsen Norman Group associe observation et entretien pour révéler ce que les autres méthodes manquent. Vous obtenez l’écart entre usage prévu et réel. Un caissier qui saisit d’un pouce tout en tenant un gobelet indique où commencer la prochaine optimisation.

Évaluation de la désirabilité

Montrez le design et demandez de choisir dans une liste fixe les mots qui le décrivent, puis d’expliquer chaque choix. Le guide de Nielsen Norman Group sur le Microsoft Desirability Toolkit présente un test d’attitude à vocabulaire contrôlé. Il permet d’évaluer une direction visuelle sur des preuves plutôt que sur les goûts. Vous vérifiez si elle exprime la marque. Si vous visiez « calme » et obtenez « vide », la planche d’ambiance est en cause, pas les utilisateurs.

Indicateurs

Mesurez à nouveau les chiffres choisis dans la phase de compréhension, après le lancement puis régulièrement. Le guide GOV.UK sur la mesure de la réussite couvre mesures, rapports et analyses. Vous savez si le changement a fonctionné face à la référence initiale. Sans référence, une variation reste un récit, pas un résultat.

Suivi du regard

Du matériel ou un logiciel avec webcam enregistre les zones regardées et leur durée. La page de l’Interaction Design Foundation sur le suivi du regard explique son usage pour l’engagement et l’utilisabilité. Réservez-le aux questions précises d’attention : voit-on le prix ou l’avertissement ? Vous obtenez des cartes de chaleur. Regardez-les avec prudence : voir n’est pas comprendre, et un regard long peut signifier confusion ou intérêt.

Quels modèles utiliser à chaque phase ?

Chaque modèle gratuit existe en arabe et en anglais, en clair et en sombre. Les pages arabes sont écrites en arabe, de droite à gauche. Commencer la recherche dans la mauvaise langue revient à choisir le mauvais utilisateur.

Les neuf existent aussi en un ensemble payant, UX AI Kit Pro Max, avec consignes Claude, guide d’animation et deuxième exemple pour chacun.

Questions fréquentes

Quelles sont les 5 étapes du processus de design ?

Comprendre, définir, imaginer, prototyper et tester. Les équipes reviennent d’une phase à l’autre. Un test raté ramène généralement à la définition, pas au départ.

Faut-il utiliser toutes les méthodes d’une liste de contrôle ?

Non. Choisissez dans chaque phase les une ou deux qui réduisent le plus l’incertitude. Pour la plupart des produits : entretiens et diagramme d’affinités, énoncé du problème et HMW, flux utilisateur, petit prototype, test d’utilisabilité.

Combien de personnes faut-il pour un test d’utilisabilité ?

Cinq par série. Elles trouvent environ 85 pour cent des problèmes. Faites plusieurs petites séries et corrigez entre chacune.

Quelles méthodes de design fonctionnent sans budget ?

La plupart. Données existantes, cinq entretiens, diagramme au mur, énoncé du problème, prototype papier et test dans un café coûtent du temps, sans argent. Le suivi du regard, les grands questionnaires et les tests A/B demandent des outils ou du trafic.

Quelle différence entre parcours et flux utilisateur ?

Le parcours couvre l’expérience dans le temps et les canaux, y compris hors du produit. Le flux détaille une tâche à l’intérieur du produit avec toutes ses branches. Cartographiez le parcours pour trouver le problème, puis dessinez le flux pour concevoir la correction.

L’IA peut-elle remplacer la recherche utilisateur ?

Non. Elle rédige bien les guides, classe les transcriptions et liste les échecs. Elle ne sait pas ce qu’Awad fait dans son enclos ni pourquoi Rana vérifie deux fois les frais. Lui demander de jouer l’utilisateur produit la moyenne de ses lectures, précisément l’hypothèse que la recherche doit tester.

Quelles méthodes comptent pour les personnes qui codent avec l’IA ?

Celles qui précèdent la consigne. Un énoncé du problème et un flux avec tous les échecs donnent une cible précise au modèle. Un test avec cinq personnes révèle ses erreurs. L’IA réduit le coût de construction : l’erreur coûteuse devient de construire vite la mauvaise chose.

D’où vient la liste de Barbara Vam ?

Barbara Vam a publié sa liste de contrôle du processus de design sur Notion, avec des notes et lectures pour la plupart des méthodes. La liste et son ordre sont les siens. Les explications, récits et modèles présentés ici sont les miens.

Sources

1. liste de contrôle du processus de design coconut-baroness-035.notion.site
2. processus itératif et non linéaire interaction-design.org
3. design sprint gv.com
4. guide des entretiens utilisateurs nngroup.com
5. guide des entretiens avec les parties prenantes nngroup.com
6. 28 conseils pour les questionnaires qualitatifs nngroup.com
7. guide de comparaison UX nngroup.com
8. évaluations comparatives d’utilisabilité nngroup.com
9. groupes de discussion nngroup.com
10. études de terrain nngroup.com
11. guide des diagrammes d’affinités nngroup.com
12. l’exploration du contexte ixdf.org
13. article sur les personas nngroup.com
14. article sur les cartes d’empathie nngroup.com
15. guide de cartographie des parcours nngroup.com
16. rédaction de récits utilisateurs gov.uk
17. article sur les énoncés de problème nngroup.com
18. biais narratifs nngroup.com
19. article sur les questions HMW nngroup.com
20. article sur l’analyse des tâches nngroup.com
21. l’histoire du milkshake de Christensen library.hbs.edu
22. personas et tâches à accomplir nngroup.com
23. article sur le remue-méninges ixdf.org
24. page sur les cartes mentales ixdf.org
25. article sur les scénarimages nngroup.com
26. article sur le tri de cartes nngroup.com
27. parcours et flux utilisateurs nngroup.com
28. l’architecture et la navigation nngroup.com
29. définition des plans de service nngroup.com
30. canevas strategyzer.com
31. pire idée possible ixdf.org
32. Design Sprint Kit designsprintkit.withgoogle.com
33. croquis ixdf.org
34. article sur les principes de design nngroup.com
35. article sur les planches d’ambiance nngroup.com
36. Style Tiles styletil.es
37. guide des systèmes de design nngroup.com
38. GOV.UK Design System design-system.service.gov.uk
39. prototypes de basse et haute fidélité nngroup.com
40. article sur le prototypage papier nngroup.com
41. article sur les micro-interactions nngroup.com
42. wireflows nngroup.com
43. création de prototypes gov.uk
44. page sur les maquettes filaires ixdf.org
45. guide des tests d’utilisabilité nngroup.com
46. les tests avec 5 utilisateurs nngroup.com
47. l’observation en immersion ixdf.org
48. guide des tests A/B nngroup.com
49. guide SUS measuringu.com
50. dix heuristiques de Jakob Nielsen nngroup.com
51. mener cette évaluation nngroup.com
52. l’analyse des usages en UX nngroup.com
53. temps de réponse nngroup.com
54. tests de performance frontend gov.uk
55. enquête contextuelle nngroup.com
56. Microsoft Desirability Toolkit nngroup.com
57. mesure de la réussite gov.uk
58. suivi du regard ixdf.org