Une interface peut sembler évidente à toute l’équipe projet et poser problème dès qu’une personne la découvre pour la première fois.
Nous savons où se trouve le bouton. Nous connaissons l’arborescence. Nous avons participé aux réunions pendant lesquelles « Solutions » et « Expertises » ont été définies. L’utilisateur arrive sans tout cela.
C’est précisément ce que je cherche à observer pendant un test utilisateur.
Je ne lui demande pas s’il trouve la maquette jolie. Je lui donne une tâche.
Par exemple :
« Vous cherchez une agence capable de refaire votre site e-commerce. Essayez de vérifier si cette entreprise peut répondre à votre besoin et trouvez comment la contacter. »
Je regarde ce qu’il fait. La rubrique qu’il ouvre en premier. Les mots qui le font hésiter. Les contenus qu’il ignore. Les retours en arrière. Le moment où il cherche un autre chemin.
Un problème peut apparaître en quelques minutes alors que l’équipe projet ne le voyait plus depuis des semaines.
Un test utilisateur ne sert pas à demander si une interface plaît. Il sert à vérifier si une personne arrive à faire ce qu’elle est venue faire.
Ce que mesure réellement un test utilisateur
Un test d’utilisabilité consiste à demander à une personne représentative du public visé d’accomplir certaines tâches sur une interface pendant que l’on observe son comportement.
Le support peut être très différent selon l’avancement du projet : wireframe, prototype Figma, site déjà en ligne, application ou nouvelle fonctionnalité.
Le Nielsen Norman Group décrit le dispositif autour de trois éléments : un participant, des tâches et un facilitateur qui observe la session.
Voir : Nielsen Norman Group – Usability Testing 101.
Ce cadre suffit déjà pour répondre à des questions très concrètes.
Une personne trouve-t-elle les tarifs ? Comprend-elle que ce bouton ouvre un devis et non une commande ? Réussit-elle à modifier sa réservation ? Sait-elle quoi saisir dans le champ « Budget » ?
Je préfère ce type de question à un objectif très général comme « tester le site ».
Observer un comportement plutôt que demander un avis
Une personne peut me dire :
« Oui, le menu est clair. »
Puis ouvrir trois rubriques avant de trouver la page recherchée.
Les deux informations sont intéressantes, mais elles ne répondent pas à la même question.
Si je cherche à savoir si le contenu est facile à trouver, le parcours observé compte davantage que l’opinion déclarée.
Je préfère donc une consigne comme :
« Vous souhaitez vérifier si l’agence a déjà réalisé un projet pour une entreprise industrielle. Montrez-moi comment vous chercheriez cette information. »
à :
« Est-ce que vous trouvez la rubrique Réalisations facile à trouver ? »
La seconde formulation attire déjà l’attention sur la rubrique que je veux évaluer.
Les questions d’opinion viennent plutôt après la tâche, lorsque j’ai déjà observé le comportement.
Tester avant que tout soit développé
Il n’est pas nécessaire d’attendre la mise en ligne.
Un wireframe peut suffire pour tester une organisation de page, un parcours ou la compréhension d’un menu.
Un prototype plus abouti permettra ensuite de tester des interactions plus précises.
Je peux enfin revenir aux tests sur le produit réel lorsqu’il faut observer un comportement que Figma simule mal : saisie mobile, clavier virtuel, performances, fonctionnement d’un tableau complexe ou utilisation d’une technologie d’assistance.
Le GOV.UK Service Manual recommande lui aussi les tests modérés avec des prototypes ou des services déjà développés.
Voir : GOV.UK Service Manual – Using moderated usability testing.
Une erreur de navigation corrigée dans un prototype demande quelques modifications. La même erreur découverte après le développement de cinquante pages demande beaucoup plus de reprises.
Définir ce que l’on cherche à apprendre
Je commence toujours par les questions auxquelles le test doit répondre.
Sur un site de services, elles peuvent être très concrètes :
- les visiteurs distinguent-ils deux offres proches ?
- trouvent-ils les réalisations correspondant à leur secteur ?
- comprennent-ils ce qui se passe après le bouton « Demander une estimation » ?
- arrivent-ils à remplir le formulaire sans disposer d’informations qu’ils n’ont pas encore ?
Ces questions déterminent le reste du protocole.
Si je teste la navigation, je laisse le participant chercher depuis une page où le menu est visible.
Si je m’intéresse au formulaire, je recrée le contexte qui conduit normalement jusqu’à lui. Le comportement n’est pas toujours le même lorsqu’un formulaire apparaît sans explication et lorsqu’il arrive après plusieurs minutes de recherche.
Recruter des personnes pertinentes pour la tâche
Un collègue peut repérer un bug. Il est rarement le meilleur participant pour tester une arborescence sur laquelle il travaille depuis deux mois.
Il sait déjà où les informations sont rangées.
Je recherche plutôt les caractéristiques qui peuvent réellement modifier l’usage.
Pour un logiciel destiné à des experts-comptables, la connaissance de la comptabilité compte davantage que l’âge exact du participant.
Pour un site grand public, je ne recruterais pas uniquement des professionnels du web habitués à reconnaître toutes les conventions d’interface.
Pour une application utilisée quotidiennement, je peux aussi vouloir comparer nouveaux utilisateurs et utilisateurs expérimentés. Ils n’ont pas les mêmes besoins : le premier cherche ses repères ; le second peut privilégier la vitesse.
La règle des cinq utilisateurs mérite d’être nuancée
« Il faut cinq utilisateurs » est devenu une sorte de règle UX.
Elle vient d’un contexte précis : les études qualitatives destinées à découvrir des problèmes d’utilisabilité.
Le Nielsen Norman Group recommande actuellement couramment un petit groupe, souvent de l’ordre de 5 à 8 participants, pour ce type de test.
Voir : Usability Testing 101 et How Many Test Users in a Usability Study?.
Cela ne signifie pas que cinq personnes répondent à toutes les questions.
Un produit peut avoir deux groupes d’utilisateurs qui travaillent de manière très différente. Dans ce cas, les mélanger dans un unique groupe de cinq peut masquer les problèmes propres à chacun.
Et lorsqu’on cherche à mesurer un taux de réussite avec une précision statistique, le besoin en participants change complètement.
Test qualitatif et test quantitatif
| Qualitatif | Quantitatif | |
|---|---|---|
| Objectif | Repérer les problèmes et comprendre pourquoi ils apparaissent | Mesurer une performance |
| Données principales | Comportements, hésitations, commentaires | Taux de réussite, temps, nombre d’erreurs |
| Échantillon | Petit groupe ciblé | Plus important |
| Usage | Améliorer la conception | Comparer ou établir un benchmark |
Le Nielsen Norman Group distingue explicitement ces deux approches.
Voir : Quantitative vs. Qualitative Usability Testing.
Dans mes tests qualitatifs, je cherche surtout à comprendre les difficultés : pourquoi ce lien est-il ignoré ? Pourquoi cette personne hésite-t-elle à envoyer le formulaire ? Que pense-t-elle trouver derrière « Solutions » ?
Je ne transforme pas ensuite cinq observations en statistiques sur l’ensemble des utilisateurs du site.
Écrire une tâche sans donner la solution
Une mauvaise consigne peut rendre le test inutile.
Supposons que je souhaite tester la rubrique « Réalisations ».
Je ne demande pas :
« Allez dans Réalisations et trouvez un projet dans le secteur de la santé. »
Le principal problème à tester vient justement de disparaître.
Je peux écrire :
« Vous travaillez dans le secteur de la santé et vous souhaitez vérifier si l’agence connaît déjà ce type de projet. Cherchez une information qui pourrait vous rassurer. »
Je vois alors si le participant choisit « Réalisations », « Secteurs », « Agence » ou un autre chemin.
Le Nielsen Norman Group recommande des tâches réalistes dont la formulation n’intègre pas les termes susceptibles de révéler directement la solution.
Voir : Writing Tasks for Quantitative and Qualitative Usability Studies.
J’évite aussi les scénarios trop romancés. Le participant n’a pas besoin de mémoriser une histoire de quinze lignes pour tester un menu.
Ce que l’on peut déjà tester dans Figma
Un prototype cliquable permet de vérifier beaucoup de choses :
- le choix d’une rubrique ;
- la compréhension des libellés ;
- l’ordre des informations ;
- la visibilité d’une action ;
- l’enchaînement d’un parcours.
Il faut simplement rester dans les limites du support.
Je ne tirerais pas de conclusion définitive sur un clavier mobile à partir d’un prototype qui n’affiche pas réellement ce clavier.
Même chose pour un chargement, une animation complexe ou certaines interactions accessibles au clavier.
Le niveau de fidélité doit être suffisant pour la question testée. Pas davantage.
Observer sans aider trop tôt
Lorsqu’une personne hésite, mon premier réflexe naturel serait de l’aider.
Je connais le site. Je vois très bien le bouton qu’elle cherche.
Mais cette hésitation fait partie du test.
Si je dis :
« Regardez peut-être dans le menu en haut. »
je viens d’introduire la solution.
Je peux plutôt demander :
« Qu’est-ce que vous cherchez à faire ? »
ou :
« Qu’est-ce que vous vous attendiez à trouver ici ? »
Si le participant reste complètement bloqué et que le problème est suffisamment documenté, je peux ensuite l’aider à passer cette étape afin de tester la suite.
Le but n’est pas de le laisser échouer pendant dix minutes. Il est de ne pas masquer trop vite le point de friction.
Utiliser le think aloud avec mesure
Je demande souvent aux participants de dire ce qu’ils pensent pendant la tâche.
Une phrase comme :
« Je vais ouvrir Expertises parce que Solutions me fait plutôt penser à des produits. »
est beaucoup plus informative qu’un simple clic sur « Expertises ».
Elle donne accès au raisonnement derrière l’action.
Le Nielsen Norman Group décrit le thinking aloud comme une méthode de base du test d’utilisabilité qualitatif.
Voir : Thinking Aloud: The #1 Usability Tool.
Je ne pose pas pour autant une question après chaque mouvement de souris.
La personne doit pouvoir utiliser l’interface normalement. La verbalisation sert à éclairer certains choix, pas à transformer chaque clic en entretien.
Laisser à l’utilisateur le temps de réfléchir
Cinq secondes de silence paraissent longues lorsque l’on modère une session.
Elles sont parfois simplement le temps nécessaire pour lire l’écran.
Si je relance immédiatement, je risque d’attirer l’attention sur un endroit ou de faire croire qu’un problème était attendu.
J’attends donc quelques secondes.
Si j’ai besoin d’une relance :
« À quoi pensez-vous ? »
reste beaucoup plus neutre que :
« Vous ne trouvez pas le bouton ? »
Tester le protocole avant les participants
Une session pilote révèle rapidement les erreurs de préparation.
Une consigne emploie exactement le nom d’un bouton. Un écran du prototype manque. Une donnée nécessaire à la tâche n’a pas été fournie. Une tâche censée prendre cinq minutes en demande quinze.
Je fais donc au moins un passage complet avant la première vraie session.
Je contrôle aussi les liens du prototype, les accès éventuels et le matériel d’enregistrement.
Pour une étude qualitative, quelques ajustements restent possibles si une consigne se révèle réellement mauvaise. Une étude quantitative demande davantage de stabilité puisque les résultats de plusieurs participants doivent être comparables.
Présentiel, distance et test non modéré
Le test modéré à distance
C’est souvent le format le plus simple pour un site web.
Le participant partage son écran. Je peux l’observer et lui poser une question lorsqu’un comportement mérite d’être compris.
Il utilise aussi son propre ordinateur ou son propre téléphone, ce qui peut être intéressant.
Le présentiel
Il devient plus utile lorsque le geste, l’environnement ou un dispositif physique font partie de l’expérience.
Il permet aussi d’observer certaines réactions qui passent plus facilement inaperçues en visioconférence.
Le test non modéré
Le participant reçoit les tâches dans un outil et les réalise sans modérateur présent.
Ce format facilite l’organisation de davantage de sessions, mais je perds la possibilité de demander immédiatement :
« Pourquoi êtes-vous revenu sur cette page ? »
La préparation des tâches doit donc être particulièrement soignée.
Tester avec des personnes en situation de handicap
Un audit WCAG ou RGAA vérifie des critères. Un test utilisateur montre ce qui se passe réellement lorsqu’une personne essaie d’accomplir une tâche.
Les deux approches se complètent.
Le W3C recommande d’impliquer des personnes en situation de handicap dans l’évaluation de l’accessibilité tout en rappelant que ces tests ne remplacent pas une évaluation de conformité.
Voir : W3C – Involving Users in Evaluating Web Accessibility.
Une personne utilisant un lecteur d’écran peut par exemple montrer qu’un formulaire techniquement accessible reste très pénible à parcourir à cause de son ordre ou de ses instructions.
Inversement, une expérience satisfaisante lors de deux sessions ne démontre pas que tous les critères d’accessibilité sont respectés.
Je ne généralise pas non plus l’expérience d’un participant à toutes les personnes utilisant la même technologie d’assistance.
Prendre des notes exploitables
« Utilisateur perdu » n’est pas une note très utile.
Je préfère :
« Cherche les tarifs dans Solutions puis Ressources. Ne remarque le lien Tarifs dans le header qu’après environ 25 secondes. »
Je peux ensuite comparer ce comportement aux autres sessions.
Je note en priorité le contexte, l’action tentée, l’endroit où apparaît la difficulté et la manière dont elle est résolue.
Une citation mérite d’être conservée lorsqu’elle explique particulièrement bien une incompréhension :
« Je pensais que “Expertises” expliquait ce que vous savez faire et que “Solutions” correspondait à vos logiciels. »
Cette phrase peut être plus utile à l’équipe qu’une note abstraite indiquant « problème de vocabulaire ».
Transformer les observations en problèmes UX
Après les sessions, je regroupe les observations qui semblent avoir la même cause.
Plusieurs personnes cherchent les références clients dans « Agence ».
Trois comprennent mal le CTA « Échangeons ».
Deux restent bloquées sur le budget obligatoire du formulaire.
Le rapport final ne devrait pas être uniquement une succession de verbatims.
Je peux formuler :
Observation : plusieurs participants testés ne comprennent pas que « Nos univers » mène aux études de cas.
Impact : ils utilisent d’autres rubriques avant de trouver les références.
Hypothèse de correction : remplacer le libellé par « Réalisations » ou « Cas clients », puis vérifier la nouvelle version.
La dernière partie reste une hypothèse.
Le test permet d’identifier un problème. Il ne garantit pas que la première solution imaginée sera la bonne.
Prioriser selon l’impact sur la tâche
Je ne mets pas au même niveau une hésitation de deux secondes sur une icône et un formulaire impossible à envoyer.
Je regarde d’abord les conséquences.
Le problème empêche-t-il la tâche ? Provoque-t-il une erreur ? Fait-il prendre un détour important ? Concerne-t-il une action centrale pour le service ?
La fréquence observée entre également dans l’analyse, avec prudence lorsqu’il s’agit d’un petit échantillon.
Sur un site marchand, un blocage récurrent au paiement passe avant une incompréhension sur un filtre rarement utilisé.
Cette hiérarchisation évite aussi de transformer le test en liste de vingt-six détails à corriger avec la même priorité.
Ce que cinq participants ne permettent pas d’affirmer
Supposons que trois personnes sur cinq ne trouvent pas les tarifs.
Je prends le problème au sérieux.
Je n’écris pas :
« 60 % des utilisateurs ne trouvent pas les tarifs. »
L’échantillon est beaucoup trop petit pour produire ce type d’estimation.
Le Nielsen Norman Group insiste sur cette différence entre test qualitatif et mesure quantitative.
Voir : Why 5 Participants Are Okay in a Qualitative Study, but Not in a Quantitative One.
Trois observations similaires indiquent qu’il existe probablement quelque chose à investiguer ou corriger.
Elles ne donnent pas la fréquence du problème dans l’ensemble du trafic.
Corriger puis retester
Je préfère tester plusieurs fois pendant le projet plutôt que tout concentrer juste avant la mise en ligne.
Une première série fait apparaître un menu ambigu et un formulaire trop exigeant.
Je corrige ces deux points.
La nouvelle version est testée à son tour.
Le problème peut avoir disparu. Il peut également s’être déplacé.
Changer « Solutions » en « Services » peut rendre le premier niveau plus clair mais créer un conflit avec une autre rubrique. Rendre « Budget » facultatif peut résoudre un blocage mais laisser l’utilisateur se demander ce que l’on attend de lui.
L’itération permet de vérifier les corrections plutôt que de les considérer comme bonnes parce qu’elles semblent logiques en réunion.
Exemple : tester un formulaire de devis
Le formulaire demande :
Nom, entreprise, e-mail, téléphone, budget, date souhaitée de lancement et description du projet.
Sur la maquette, rien ne semble particulièrement compliqué.
Pendant une session, un participant arrive au champ Budget et dit :
« Je vous contacte justement parce que je ne sais pas combien ce projet doit coûter. »
Un autre choisit une fourchette au hasard pour pouvoir continuer.
Le problème ne vient ni de la taille du champ ni de sa couleur.
L’interface exige une information que certains prospects n’ont pas encore.
Je peux alors tester plusieurs solutions : rendre le champ facultatif, ajouter « Je ne sais pas encore » ou le supprimer du premier contact.
Cet exemple rejoint directement les frictions décrites dans mon article sur l’UX des formulaires web.
Organiser un test utile avec peu de moyens
Pour une PME, je préfère réduire le périmètre du test plutôt que remplacer tous les utilisateurs par les membres de l’équipe disponibles ce jour-là.
Cinq sessions de 30 à 45 minutes autour de quelques tâches prioritaires peuvent déjà produire beaucoup d’informations.
Le matériel nécessaire reste limité pour un site web : un prototype, une visioconférence, éventuellement un enregistrement avec consentement et un document pour les notes.
Le travail se concentre ailleurs : trouver les bons participants, préparer les scénarios, mener les sessions sans trop guider et analyser les observations.
Une session simple avec une personne qui correspond réellement à la cible m’intéresse davantage qu’un dispositif sophistiqué avec un participant qui n’utilisera jamais le service.
Les erreurs que je rencontre le plus souvent
Demander si le participant aime la maquette
La réponse peut compléter le test, mais elle ne mesure pas l’utilisabilité.
Tester uniquement avec des collègues
Ils connaissent déjà trop bien le projet et son vocabulaire.
Donner le nom de la rubrique dans la tâche
La navigation n’est alors plus réellement testée.
Intervenir dès que la personne hésite
Quelques secondes d’hésitation peuvent précisément révéler le problème recherché.
Poser une question orientée
« Vous trouvez ce bouton difficile à voir ? » n’est pas neutre.
Prévoir trop de tâches
Une session très longue finit par tester la fatigue autant que l’interface.
Tester uniquement le parcours parfait
Les erreurs, filtres sans résultat, retours arrière et informations manquantes font partie de l’usage réel.
Transformer un petit échantillon en pourcentages
Le test qualitatif permet de repérer des difficultés, pas d’en mesurer la fréquence dans toute la population.
Attendre la fin du projet
Les choix structurels deviennent alors plus coûteux à modifier.
Considérer la première correction comme validée
La nouvelle solution mérite elle aussi d’être testée.
Ma méthode pour préparer les sessions
1. Écrire les questions de recherche
Je liste ce que je veux apprendre : trouver une prestation, comprendre une offre, effectuer une réservation ou terminer un formulaire.
2. Choisir quelques tâches
Je privilégie les parcours ayant un impact réel sur l’objectif du site.
3. Définir les participants
Je retiens les caractéristiques qui peuvent modifier leur manière d’utiliser le service.
4. Rédiger les scénarios
Je retire les formulations qui donnent directement la réponse et je garde uniquement le contexte nécessaire.
5. Préparer le prototype
Tous les écrans nécessaires à la tâche doivent fonctionner suffisamment pour le sujet évalué.
6. Faire un pilote
Je vérifie les consignes, la durée et les éventuels problèmes techniques.
7. Observer
Je laisse le participant chercher. Les relances restent neutres.
8. Consolider les notes après chaque session
Quelques minutes juste après le test évitent de perdre des détails difficiles à retrouver plus tard.
9. Regrouper les observations
Je cherche les problèmes communs et les rattache à une tâche précise.
10. Prioriser puis retester
Les problèmes qui empêchent les tâches importantes passent en premier.
Le test permet ainsi de confronter le parcours utilisateur imaginé pendant la conception à ce que des personnes font réellement devant l’interface.
Checklist avant un test utilisateur
- La question de recherche est-elle suffisamment précise ?
- Les participants correspondent-ils aux usages que je veux observer ?
- Les tâches sont-elles plausibles ?
- Leur formulation évite-t-elle de donner la réponse ?
- Le prototype permet-il réellement de réaliser les tâches ?
- Tous les liens ont-ils été testés ?
- Une session pilote a-t-elle été réalisée ?
- Les relances prévues sont-elles neutres ?
- Les tâches les plus importantes sont-elles placées assez tôt ?
- Le participant connaît-il les conditions d’enregistrement et peut-il les accepter ou les refuser ?
- La prise de notes est-elle organisée ?
- Le temps prévu permet-il de garder quelques minutes pour les questions de fin ?
FAQ sur les tests utilisateurs
Qu’est-ce qu’un test utilisateur en UX ?
Il consiste à observer une personne représentative du public visé pendant qu’elle accomplit des tâches avec une interface. L’objectif est d’identifier les problèmes d’utilisation et de comprendre leur origine.
Combien de participants faut-il ?
Pour un test qualitatif destiné à découvrir des problèmes, quelques participants peuvent déjà être utiles. Le Nielsen Norman Group utilise couramment 5 à 8 personnes comme ordre de grandeur. Une étude quantitative nécessite davantage de participants.
Peut-on tester un prototype Figma ?
Oui. Navigation, compréhension des libellés, hiérarchie et enchaînement des écrans peuvent être testés très tôt. Il faut simplement éviter d’évaluer un comportement que le prototype ne reproduit pas correctement.
Quelle différence avec une interview utilisateur ?
L’interview recueille principalement ce que la personne raconte sur ses besoins, pratiques ou expériences. Le test d’utilisabilité observe ce qu’elle fait lorsqu’elle tente d’utiliser une interface.
Faut-il demander au participant de penser à voix haute ?
La méthode est utile pour comprendre certains raisonnements. Elle ne doit pas empêcher la personne d’utiliser naturellement l’interface.
Peut-on tester à distance ?
Oui. Pour un site ou un logiciel, le test modéré à distance fonctionne très bien dans de nombreux cas. Le choix du format dépend surtout de ce que l’on doit observer.
Qu’est-ce qu’un test non modéré ?
Le participant réalise seul les tâches préparées dans un outil. Le format facilite l’organisation d’un volume plus important de sessions mais ne permet pas de poser une question de relance en direct.
Un test utilisateur remplace-t-il un audit RGAA ?
Non. Les tests avec des personnes en situation de handicap montrent des difficultés réelles d’utilisation. Ils ne vérifient pas l’ensemble des critères techniques d’un référentiel d’accessibilité.
Comment prioriser les problèmes détectés ?
Je regarde d’abord leur impact sur la tâche et l’importance de cette tâche pour l’utilisateur et le service. La répétition entre plusieurs sessions apporte ensuite un signal supplémentaire.
Sources et ressources
- Nielsen Norman Group – Usability Testing 101 : définition, préparation et conduite des tests d’utilisabilité.
- Nielsen Norman Group – How Many Test Users in a Usability Study? : nombre de participants et logique des petits échantillons qualitatifs.
- Nielsen Norman Group – Why 5 Participants Are Okay in a Qualitative Study, but Not in a Quantitative One : limites statistiques de la règle des cinq participants.
- Nielsen Norman Group – Quantitative vs. Qualitative Usability Testing : différences entre découverte qualitative et mesure quantitative.
- Nielsen Norman Group – Writing Tasks for Quantitative and Qualitative Usability Studies : rédaction des tâches et scénarios.
- Nielsen Norman Group – Thinking Aloud: The #1 Usability Tool : utilisation de la verbalisation pendant les tests.
- Nielsen Norman Group – Unmoderated User Tests : fonctionnement des tests non modérés.
- GOV.UK Service Manual – Using moderated usability testing : préparation et conduite de tests modérés.
- W3C – Involving Users in Evaluating Web Accessibility : implication d’utilisateurs en situation de handicap dans l’évaluation d’une interface.
À lire également sur TooNetCreation
- UX et UI : quelles différences et pourquoi les deux sont indispensables à un site web ?
- Qu’est-ce qu’un wireframe ? Définition, utilité et méthode pour concevoir un site web
- Hiérarchie visuelle : comment organiser une page web pour guider l’utilisateur ?
- Comment construire un parcours utilisateur efficace sur un site web ?
- UX des formulaires web : comment réduire les frictions et les abandons ?
- UX mobile : pourquoi adapter l’expérience et pas seulement réduire la maquette ?
- Navigation UX : comment concevoir un menu qui aide vraiment l’utilisateur à trouver son chemin ?
- Microcopy UX : comment écrire les petits textes qui guident vraiment l’utilisateur ?
- Conception UX/UI et expérience utilisateur
