Une interface se conçoit dans cet ordre : tu décris le parcours de l'utilisateur, tu le traduis en wireframes (des schémas d'écrans en gris), puis tu fais tester ces wireframes par de vrais utilisateurs avant de soigner l'apparence. Exemple : pour une appli qui réserve les salles de travail de la bibliothèque universitaire, tu notes les étapes d'une étudiante qui veut réviser à quatre, tu dessines les écrans correspondants, puis tu regardes cinq étudiants essayer de réserver. Ce qui les bloque se corrige au crayon, avant toute ligne de code.
UX, UI et utilisabilité
L'UI (user interface, interface utilisateur) est ce que tu vois et touches : écrans, boutons, couleurs, textes. L'UX (user experience, expérience utilisateur) est plus large. La norme ISO 9241-11 la définit comme les perceptions et les réactions d'une personne qui résultent de l'utilisation, réelle ou anticipée, d'un système, d'un produit ou d'un service.
Définition : l'utilisabilité est la mesure dans laquelle un système, un produit ou un service peut être utilisé par des utilisateurs donnés pour atteindre des objectifs donnés avec efficacité, efficience et satisfaction, dans un contexte d'utilisation donné (ISO 9241-11:2018).
Retiens le mot « donnés » : une appli n'est pas utilisable dans l'absolu. Celle d'un livreur peut être claire au bureau et pénible d'une main, sur un vélo.
| Critère | Ce qu'il veut dire | Ce que tu mesures |
|---|---|---|
| Efficacité | Le but est atteint, en entier et sans erreur | Le taux de réussite des tâches |
| Efficience | Ce que coûte le résultat : temps, effort | Le temps ou le nombre d'actions par tâche |
| Satisfaction | Les réactions de l'utilisateur répondent à ses besoins et attentes | Un questionnaire après le test |
Le parcours utilisateur
Une carte de parcours utilisateur (journey map) représente les étapes qu'une personne traverse pour atteindre un but. Au centre, un acteur, souvent un persona : un profil type bâti sur de vraies données d'utilisateurs. Un scénario fixe son objectif, puis, phase par phase, tu notes ce qu'il fait, pense et ressent. Tu termines par les pistes d'amélioration.
Voici le parcours d'Inès, en deuxième année de licence, qui cherche une salle pour réviser jeudi avec trois amis.
| Phase | Ce qu'elle fait | Ce qu'elle pense | Ce qu'elle ressent |
|---|---|---|---|
| Chercher | Affiche les salles libres jeudi | « Où je choisis le nombre de places ? » | Agacée |
| Réserver | Remplit le formulaire, doit se reconnecter : tout est effacé | « Je recommence tout ? » | Au plus bas |
| Confirmer | Reçoit un courriel de confirmation | « C'est réservé. » | Soulagée |
| Venir | Cherche la salle dans le bâtiment | « La salle 2, c'est où ? » | Perdue |
Le point le plus bas dit où travailler en premier : la reconnexion qui efface le formulaire. La piste d'amélioration s'en déduit : garder la saisie pendant la reconnexion. La carte ne dessine aucun écran, elle dit ce que les écrans devront régler.
Piège classique : écrire le parcours depuis ton bureau, sans avoir parlé à un seul utilisateur. Tu obtiens tes propres suppositions déguisées en faits. Sans données, écris « hypothèse » dans chaque case, puis vérifie en entretien ou en test.
Les wireframes
Un wireframe (maquette fil de fer) est le schéma d'un écran en niveaux de gris. Il place les zones (titre, menu, liste, bouton) et fixe leur ordre d'importance, sans couleur ni image. Il répond à une question : que doit trouver l'utilisateur sur cet écran, et dans quel ordre ?
Chaque phase du parcours donne un ou plusieurs écrans. Pour Inès, l'écran de recherche met en haut la date et le nombre de places, puis la liste des salles libres. Le point bas du parcours devient une annotation en marge : « la saisie reste en mémoire pendant la reconnexion ».
| Livrable | À quoi il ressemble | Ce qu'il valide |
|---|---|---|
| Wireframe | Croquis ou blocs gris, avec les vrais textes | Le contenu et la hiérarchie de chaque écran |
| Maquette (mockup) | L'écran final figé : couleurs, typographie, images | L'apparence, donc l'UI |
| Prototype | Des écrans reliés, sur papier ou à l'écran, qu'on parcourt comme le vrai produit | Le parcours, pendant un test |
Un prototype peut rester grossier (basse fidélité) ou ressembler presque au produit final (haute fidélité) : pour un premier test, des wireframes reliés suffisent. Écris les vrais textes dès le wireframe : un bouton en faux texte ne se teste pas. Le mot « maquette » sert parfois aussi pour le wireframe : précise toujours le niveau de fidélité.
Le test d'utilisabilité
Un test d'utilisabilité consiste à regarder de vrais utilisateurs accomplir des tâches réelles sur ton prototype, sans les aider. Tu observes ce qu'ils font, pas ce qu'ils disent aimer.
Étape 1 : Écris des tâches scénarisées, avec un but et un contexte mais jamais le chemin : « Tu révises jeudi de 14 h à 16 h avec trois amis : réserve une salle. »
Étape 2 : Recrute des participants qui ressemblent à tes utilisateurs : pour Inès, des étudiants, pas tes collègues designers.
Étape 3 : Demande-leur de penser à voix haute : dire ce qu'ils cherchent et ce qu'ils comprennent. Tu notes hésitations et erreurs sans jamais montrer la solution.
Étape 4 : Relève tes mesures, classe les problèmes du plus grave au plus léger, corrige le prototype et teste de nouveau.
Piège classique : la tâche qui souffle la réponse. « Clique sur l'onglet Réservations » donne le chemin : tu testes alors la lecture de la consigne, pas l'interface. Écris la tâche avec les mots de l'utilisateur, jamais avec ceux des boutons.
Le nombre de participants
Jakob Nielsen et Tom Landauer ont modélisé la part des problèmes d'utilisabilité qu'un test révèle selon son nombre de participants (Nielsen, 2000).
Formule : avec $n$ participants, la part des problèmes trouvés vaut
$$P(n) = 1 - (1 - L)^n$$
où $L$ est la part qu'un seul participant révèle : $0{,}31$ en moyenne sur les projets qu'ils ont étudiés.
Avec cinq participants, $P(5) = 1 - 0{,}69^5 \approx 0{,}84$ : environ 84 % des problèmes (Nielsen annonce 85 %). Chaque participant suivant retrouve surtout des problèmes déjà vus, et la courbe s'aplatit. D'où son conseil : trois tests de cinq, avec une correction du prototype entre chacun, plutôt qu'un test de quinze.
Piège classique : la règle des cinq vaut pour des utilisateurs comparables. Avec deux publics très différents, des étudiants et des bibliothécaires, Nielsen recommande 3 ou 4 personnes par groupe. Et cinq personnes révèlent des problèmes, pas des statistiques : 4 réussites sur 5 ne prouvent pas que 80 % des étudiants réussiront.
Exercices corrigés
Exercice 1 : Pendant un test du prototype de réservation, tu notes trois observations. Pour chacune, dis quel critère de l'ISO 9241-11 elle concerne. a) 2 participants sur 5 n'arrivent pas à réserver. b) Réserver prend en moyenne 4 minutes, pour 1 minute visée. c) Un participant réussit après plusieurs retours en arrière, puis déclare « c'était facile ».
Correction :
a) Efficacité : le but n'est pas atteint. b) Efficience : la tâche aboutit, mais coûte trop de temps.
c) C'est le piège : la tâche est réussie (efficacité), mais les retours en arrière montrent une efficience médiocre, alors que la satisfaction déclarée est bonne. On mesure ce que fait le participant, pas seulement ce qu'il dit.
Exercice 2 : Un collègue a préparé cette tâche : « Clique sur l'onglet Réservations, puis choisis la salle 2 pour jeudi. Tu trouves ce menu clair ? » Repère ses deux défauts, puis réécris-la.
Correction :
Premier défaut : elle donne le chemin (l'onglet, la salle). Le participant suit la consigne et tu n'apprends rien sur l'interface. Second défaut : la question finale demande un avis et souffle la réponse attendue. Tu récoltes un oui poli au lieu d'une observation.
Version corrigée : « Jeudi, tu révises de 14 h à 16 h avec trois amis. Trouve une salle qui vous convient et réserve-la. »
Exercice 3 : On reprend le modèle de Nielsen et Landauer avec $L = 0{,}31$. a) Quelle part des problèmes révèle un test à 3 participants ? b) Combien de participants faut-il au minimum pour en révéler au moins 90 % ?
Correction :
a) $P(3) = 1 - 0{,}69^3 = 1 - 0{,}328509 \approx 0{,}67$, soit environ 67 % des problèmes.
b) On cherche le plus petit entier $n$ tel que $1 - 0{,}69^n \geqslant 0{,}9$, c'est-à-dire $0{,}69^n \leqslant 0{,}1$. La fonction $\ln$ est croissante, donc $n \ln 0{,}69 \leqslant \ln 0{,}1$. Comme $\ln 0{,}69 < 0$, diviser par ce nombre inverse le sens de l'inégalité : $n \geqslant \dfrac{\ln 0{,}1}{\ln 0{,}69} \approx 6{,}2$. Il faut donc 7 participants.
Contrôle : $P(6) \approx 0{,}89$ et $P(7) \approx 0{,}93$. Deux participants de plus que la règle des cinq rapportent environ 8 points seulement : la courbe s'aplatit.
À retenir
À retenir :
- L'utilisabilité se juge pour des utilisateurs, des objectifs et un contexte donnés, selon l'efficacité, l'efficience et la satisfaction.
- Le parcours utilisateur vient d'abord, tiré de vraies données : phases, actions, pensées, émotions, pistes d'amélioration.
- Le wireframe fixe le contenu et la hiérarchie, la maquette l'apparence, et le prototype se teste.
- Une tâche de test donne un but et un contexte, jamais le chemin.
- $P(n) = 1 - (1 - L)^n$ : cinq participants comparables révèlent environ 85 % des problèmes, et trois tests de cinq valent mieux qu'un test de quinze.
Sources
- Norme ISO 9241-11:2018, Ergonomie de l'interaction homme-système, partie 11 : Utilisabilité, définitions et concepts : aperçu des premières pages (organisme slovène de normalisation).
- Jakob Nielsen, « Why You Only Need to Test with 5 Users », Nielsen Norman Group, 18 mars 2000 : article en ligne.