Ch. 5-6 — Conception et prototypage

Pourquoi une conception centrée utilisateurs

Les échecs ergonomiques sont bien réels : une entreprise abandonne son logiciel de gestion des ordres de mission et des états de frais — ergonomie insatisfaisante, maintenance difficile — et repasse temporairement au papier. La réponse est la conception centrée utilisateurs (CCU), normalisée par ISO 9241, qui mesure l'utilisabilité par des critères concrets : temps d'apprentissage, rapidité d'utilisation, taux d'erreur, facilité de mémorisation, satisfaction subjective. Bénéfices attendus : productivité accrue, coûts de formation et de support réduits, accessibilité élargie, stress diminué, avantage compétitif.

Un processus itératif

Le processus se déroule en boucle : comprendre et spécifier (le contexte d'utilisation), ordonner les exigences, produire des solutions par prototypage rapide, évaluer auprès des utilisateurs — puis recommencer. Le prototypage, rapide, n'a qu'un objectif : améliorer la conception en observant les utilisateurs sur les points clés du produit, jusqu'à un résultat satisfaisant.

Comprendre et spécifier

On identifie d'abord les catégories d'utilisateurs du produit et on crée des scénarios décrivant leur journée typique. Point d'honnêteté du cours : vous ne représentez pas nécessairement l'utilisateur moyen de votre système, et il est rarement possible de concevoir pour tout le monde — on vise 95 % de la population.

Les personas sont des personnages fictifs représentatifs, détaillés : compétences, métiers, connaissances, contexte (environnement technique : machines, périphériques, bande passante, réseaux), activités. L'analyse des tâches recense les tâches des utilisateurs : les critiques, les plus fréquentes, leur importance, leurs durées, leur difficulté, leur déroulement pas à pas et leurs interdépendances.

On fixe ensuite des objectifs d'utilisabilité qualitatifs et quantitatifs : temps d'exécution, taux d'erreur, nombre d'étapes, vitesse d'apprentissage, recours à une aide, satisfaction.

Les critères dépendent du contexte

Les critères d'utilisabilité varient avec le contexte — un système critique n'a pas les mêmes exigences qu'un jeu vidéo :

Les exigences sont ensuite ordonnées selon leur importance : elles serviront de critères d'acceptation lors des tests utilisateurs.

Brainstorming

Objectif : générer autant d'idées que possible sur un problème bien défini — la quantité prime sur la qualité. Petits groupes aux profils différents, durée limitée à 30-60 minutes, un modérateur par groupe (fait participer, arrête les critiques, surveille le temps) et un scribe (note et relit les idées). Interdits : discuter, critiquer ou ignorer les idées, changer de sujet — et chacun doit proposer au moins une idée qui semble stupide. Phase II : on relit toutes les idées, chacun vote pour 3, on classe selon le nombre de votes, puis on discute.

Séquences d'interaction et schémas d'interface

Pour transformer les besoins en prototype, deux documents se complètent :

• les séquences d'interaction — la macrostructure, image globale du système : « boîtes + flèches » illustrant des exemples de chemins d'interaction, avec les chemins alternatifs. Si le diagramme devient illisible, on le re-factorise en composants réutilisables (un composant « Naviguer carte » partagé par plusieurs écrans) ;
• les schémas d'interface — la microstructure : le contenu de chaque interface, l'arrangement visuel, les widgets, formulaires et données, la navigation entre les éléments. Ils contiennent suffisamment de détails pour qu'un développeur commence à implémenter le système.

La séquence donne l'image globale ; le schéma, le contenu et la fonctionnalité à chaque étape d'interaction — il faut les deux pour décrire un système interactif.

Fidélité et exhaustivité du prototype

Pourquoi prototyper ? Un retour rapide sur la conception, des problèmes réglés avant d'écrire du code, des coûts réduits, plusieurs interfaces testées facilement.

La fidélité est le degré de ressemblance en apparence et en performance avec le produit final. En faible fidélité, le prototype ne ressemble pas au produit final et son fonctionnement peut être simulé : simple et rapide à concevoir, il permet plus d'itérations et se révèle plus créatif. En haute fidélité, il ressemble et fonctionne comme le produit final : plus précis, mais il donne une fausse idée d'aboutissement — les utilisateurs se concentrent sur le look plutôt que sur l'interaction. Procédure : commencer avec peu de détail, améliorer la conception en faible fidélité, ajouter du détail quand c'est nécessaire.

L'exhaustivité compare prototype et produit final sur deux axes : la largeur (nombre d'éléments, options et commandes) et la hauteur (interactivité et fonctionnalité). Le prototypage horizontal couvre tous les éléments d'un écran mais peu de fonctionnalité ; le prototypage vertical réalise une tâche complète de bout en bout. Attention aux « culs de sac » et aux zones sans fonctionnalité.

Un prototype fonctionnel est une représentation limitée d'une conception qui permet aux utilisateurs d'interagir et d'évaluer sa pertinence — objectif : retour maximal pour un minimum d'effort. Exemples : maquettes papier avec « processeur humain », vidéo, modèles physiques (bois, carton), logiciel à fonctionnalité limitée.

Le prototypage papier : rôles et protocole

Dans un test de prototypage papier, l'utilisateur réalise une tâche réelle avec une version papier de l'interface, manipulée par une personne jouant le rôle de l'ordinateur. On déplace les widgets au besoin, on plie et déplie le papier pour faire apparaître les menus déroulants, on empile des cartes pour les onglets, on échange les contenus pour simuler les changements d'état. L'effort de codage est nul tant que l'interface n'est pas stabilisée.

Quatre rôles se partagent le travail : le facilitateur met les participants à l'aise et récupère les données ; le médiateur est le seul membre de l'équipe qui parle — il donne les instructions et encourage la réflexion à voix haute ; l'ordinateur connaît le fonctionnement de l'application et simule toujours les réponses du système ; l'observateur prend des notes, en silence.

Le protocole : accueil (formulaires), test (le médiateur explique la tâche, relance « À quoi pensez-vous maintenant ? », « Pensez tout haut »), debriefing (questionnaires post-évaluation, questions sur les parties problématiques, remerciements). Ensuite : trier et prioriser les observations, rédiger un rapport, planifier les changements, réitérer. Outils cités : Balsamiq, Figma.

A retenir

• la conception est centrée utilisateurs (ISO 9241) : comprendre et spécifier, ordonner, produire, évaluer — de façon itérative ;
• personas, scénarios et analyse des tâches précèdent toute solution ; les critères d'utilisabilité dépendent du contexte ;
• séquences d'interaction (macro) et schémas d'interface (micro) décrivent le système avant le code ;
• prototype faible fidélité d'abord : plus rapide, plus d'itérations, plus créatif.

---