Plan de la démo
- Personas
- Exigences
- Tests d'utilisabilité
Le Persona est une méthode de modélisation utilisée avant l'étape de conception pour représenter les différents types d'utilisateurs.
Retraitée, vit en région rurale. Utilise une tablette principalement pour les appels vidéo avec ses petits-enfants. Jardinière passionnée mais peu à l'aise avec les terminologies techniques complexes.
Prend beaucoup de photos de ses plantes. S'impatiente devant les mises à jour obligatoires et les icônes abstraites sans étiquettes textuelles.
En équipe (ou individuellement), créez un persona pour une application de votre choix (ex: gestion de potager communautaire, météo, etc.).
Consignes :
1. Identifiez un profil type (motivation, contexte).
2. Définissez les 3 types d'objectifs (Vie, Final, Expérience).
3. Listez les comportements clés et les frustrations potentielles.
Une exigence efficace fait le pont entre le besoin et la solution. Pour réussir cette étape, il faut d'abord identifier les besoins humains et les parties intéressées.
Ce que le produit doit faire : fonctions et interactions.
Ex: Permettre d'ajouter un article au panier.
Les contraintes liées à la conception (Physique, Technique, etc.).
Précise et sans ambiguïté. Ne nécessite pas d'interprétation.
Possible avec les ressources et technologies disponibles.
Une mesure externe permet de valider la réponse.
C'est un but, pas une solution. Laisse place à la créativité.
Critiquez ces exemples d'exigences en identifiant quel critère n'est pas respecté (Spécifique, Réalisable, Testable, Non-limitative) :
Exemple 1 : « L'application doit être belle et utiliser la police Arial 12pt partout. »
Problèmes :
1. Vague : "Belle" n'est pas spécifique ni testable.
2. Limitante : Imposer une police précise dicte l'implémentation.
Exemple 2 : « Le système doit être extrêmement rapide pour tous les utilisateurs. »
Problème :
1. Vague : "Extrêmement rapide" n'est pas testable. Il faut une mesure
(ex: < 200ms).
Exemple 3 : « L'interface doit être développée uniquement avec des balises <table>. »
Problème :
1. Limitante : Dicte une solution technique obsolète.
Exemple 4 : « L'application doit être capable de lire dans les pensées de l'utilisateur. »
Problème :
1. Non-réalisable : Impossible avec la technologie actuelle.
Exemple 5 : « Le système doit envoyer un courriel de confirmation. »
Problème :
1. Non-spécifique : On ne sait pas quand, à qui, ni
avec quel contenu.
À partir du scénario suivant, proposez des exigences de différents types.
Le Scénario : Maxime est un utilisateur avec une déficience visuelle légère. Il utilise une application de cuisine par commande vocale dans une cuisine commune bruyante (colocataires, hotte, radio) pendant qu'il prépare un repas avec des ingrédients à budget limité.
Trouvez une exigence Fonctionnelle :
Exigence Fonctionnelle : « Le système doit permettre de naviguer entre les étapes de la recette uniquement par commande vocale (ex: "Suivant", "Répète"). »
Trouvez une exigence Technique (Contexte) :
Exigence Contextuelle (Technique) : « Le microphone doit être capable de filtrer le bruit ambiant jusqu'à 70dB pour reconnaître les commandes vocales de l'utilisateur. »
Trouvez une exigence Utilisateur (Contexte) :
Exigence Contextuelle (Utilisateurs) : « L'interface visuelle doit offrir un mode "Contraste Élevé" conforme aux normes WCAG 2.1 pour l'accessibilité. »
Trouvez une exigence De Données (Contexte) :
Exigence Contextuelle (Données) : « Le système doit mettre à jour le prix des ingrédients en temps réel via l'API du magasin pour respecter le budget de Maxime. »
Le Participant : Utilisateur réel qui réalise les tâches (doit être à l'aise).
Le Facilitateur : Gère la session et encourage le "penser à voix haute" (doit être neutre).
L'Observateur : Prend des notes détaillées sans interprétation subjective.
Notes manuelles : Simple, mais nécessite un observateur dédié.
Vidéo / Audio : Idéal pour revoir les moments critiques.
Capture d'écran & Logs : Méthode précise pour chaque clic et mouvement.
Accueil : Souhaiter la bienvenue et expliquer l'objectif (sans jargon technique).
Contexte : Établir un scénario réaliste (ex: « Imaginez que vous cherchez une collation... »).
Attribution : Donner une carte de tâche à lire à voix haute.
Penser à voix haute : Encourager l'utilisateur à verbaliser ses pensées et actions.
Données : Noter les blocages, hésitations (via triangulation : vidéo + notes + logs).
Débriefing : Questionnaire (ex: SUS pour la satisfaction ou NASA-TLX pour la charge de travail).
Pas de langage suggestif : Évitez les mots présents dans l'interface (ex: "S'inscrire").
Objectif vs Chemin : Donnez le but final, laissez l'utilisateur trouver la route.
Scénario Réaliste : Basez la tâche sur une motivation réelle et concrète.
En groupes de 4 (deux binômes), mettez en pratique les concepts de tests d'utilisabilité sur un site web de votre choix. Coordonnez-vous pour choisir des sites différents !
Chaque binôme prépare sa session :
Le binôme A teste le site du binôme B (10 min) puis inversement (10 min) :