Comment prototyper efficacement

En bref

Résumé

Le prototypage est l’art de construire une représentation interactive d’un produit, suffisamment réaliste pour être testée avec des utilisateurs, mais suffisamment rapide à produire pour rester jetable.

Objectifs

Choisir le bon niveau de fidélité en fonction de votre étape projet, construire un prototype testable en un minimum de temps et apprendre rapidement grâce aux retours utilisateurs.

Qu’est-ce que le prototypage en UX ?

Un prototype est une représentation simulée d’un produit qui permet de tester des hypothèses de conception avant d’investir dans le développement.

Le prototypage est au coeur de toute démarche de conception centrée utilisateur. L’idée fondamentale est simple : plutôt que de spécifier, développer et livrer un produit pour ensuite découvrir que les utilisateurs ne le comprennent pas, on construit une version simplifiée que l’on met entre les mains d’utilisateurs le plus tôt possible. On apprend, on itère, puis on recommence.

L’objectif est de trouver le bon équilibre entre la rapidité de production et le réalisme nécessaire pour obtenir des retours utiles. Un prototype trop sommaire ne permettra pas à l’utilisateur de se projeter. Un prototype trop abouti prendra trop de temps à produire, et vous aurez du mal à le jeter ou à le modifier en profondeur.

Ce principe a été parfaitement résumé par les concepteurs du Design Sprint : “Le prototype juste assez réaliste pour provoquer des réactions honnêtes.”

Les niveaux de fidélité

Le concept de fidélité (fidelity en anglais) décrit le degré de réalisme d’un prototype par rapport au produit final. On distingue généralement trois niveaux.

Basse fidélité (low-fi)

Quoi : des croquis papier, des wireframes en noir et blanc, des schémas à la main sur un tableau blanc.

Caractéristiques :

• Pas de couleur, pas de typographie, pas d’images réelles.
• Les zones de contenu sont représentées par des blocs gris ou des lignes ondulées.
• Les interactions sont simulées manuellement (on tourne les pages, on montre un nouvel écran).
• Temps de production : quelques minutes à quelques heures.

Quand l’utiliser :

• En phase de découverte, quand vous explorez plusieurs directions.
• Lors d’un atelier sketching avec des parties prenantes.
• Quand vous voulez tester l’architecture d’information ou la hiérarchie d’un écran.
• Quand vous avez besoin de tester 3 ou 4 concepts différents dans la même journée.

Avantages :

• Extrêmement rapide à produire.
• Pas de biais esthétique : l’utilisateur se concentre sur la structure et le contenu, pas sur les couleurs ou les images.
• Facile à modifier en temps réel pendant un test.
• Tout le monde peut dessiner : pas besoin d’être designer.

Limites :

• Difficile de tester des interactions complexes (animations, transitions, formulaires dynamiques).
• Certains utilisateurs ont du mal à se projeter face à des croquis.

Outils : papier et feutres, tableau blanc.

Prototype papier place sur une tablette pour simuler l’experience. Credit : Tobe101, CC BY-SA 4.0, via Wikimedia Commons

Moyenne fidélité (mid-fi)

Quoi : des wireframes interactifs en niveaux de gris, avec une navigation cliquable, du vrai contenu textuel mais sans identité visuelle.

Caractéristiques :

• Niveaux de gris avec quelques accents de couleur pour les éléments interactifs.
• Vraie typographie et vrais contenus textuels (ou contenus réalistes).
• Navigation cliquable : l’utilisateur peut parcourir les écrans de manière autonome.
• Temps de production : quelques heures à une journée.

Quand l’utiliser :

• Quand la direction générale est validée et que vous avez besoin de tester les parcours de navigation.
• Pour valider l’organisation du contenu avec du vrai texte.
• Quand vous préparez un test utilisateur et que le contexte demande un minimum de réalisme.

Avantages :

• L’utilisateur peut interagir seul avec le prototype.
• Suffisamment réaliste pour tester des parcours complets.
• Pas de débat sur les couleurs ou le design visuel : on reste concentré sur l’usage.

Limites :

• Nécessite un outil de prototypage (Figma, Axure).
• Plus long à modifier qu’un croquis papier.

Outils : Figma (même si on peut aller plus loin), Axure RP.

Exemple de wireframe moyenne fidelite. Credit : doos, CC BY 2.0, via Wikimedia Commons

Haute fidélité (hi-fi)

Quoi : un prototype interactif pixel-perfect, avec la charte graphique finale, de vrais visuels, des animations et des micro-interactions.

Caractéristiques :

• Charte graphique appliquée (couleurs, typographie, iconographie).
• Images réelles ou illustrations finales.
• Interactions avancées : animations de transition, états de hover, micro-interactions.
• Données réalistes dans les champs, listes et tableaux.
• Temps de production : 1 à 5 jours selon la complexité.

Quand l’utiliser :

• En phase de validation finale, juste avant le développement.
• Pour communiquer une vision produit à des parties prenantes non techniques.
• Pour des tests utilisateurs sur des parcours critiques où l’esthétique influence le comportement (e-commerce, onboarding, landing pages).
• Pour le handoff aux développeurs.

Avantages :

• L’utilisateur interagit comme si c’était le vrai produit : les retours sont très proches de la réalité.
• Utile comme spécification visuelle pour les développeurs.
• Impressionne les parties prenantes et facilite l’alignement.

Limites :

• Long à produire, couteux à modifier.
• Risque de biais : l’utilisateur peut être impressionné par le visuel et ne pas oser critiquer.
• L’équipe peut s’attacher émotionnellement au prototype et résister aux changements.

Outils : Figma (prototypage avancé), Axure RP (logique conditionnelle), Framer (prototype avec code).

Tableau de synthèse

Construire un prototype testable en 1 jour : guide pas à pas

Voici une méthode éprouvée pour construire un prototype mid-fi testable en une journée. Cette approche est celle que j’utilise lors du jour 3 d’un Design Sprint. Elle fonctionne aussi bien en dehors du cadre d’un sprint.

Etape 1 : Définir le storyboard du parcours (1 heure)

Avant d’ouvrir Figma, prenez une feuille et dessinez le parcours que l’utilisateur va suivre pendant le test. L’objectif est de définir le chemin critique : l’enchainement d’écrans que l’utilisateur doit parcourir pour accomplir la tâche que vous allez lui donner.

1. Listez les étapes du parcours sous forme de cases, comme une bande dessinée. Chaque case correspond à un écran ou à un état d’écran.
2. Numérotez les cases dans l’ordre du parcours.
3. Indiquez les actions utilisateur entre les cases (clic, scroll, saisie).
4. Identifiez les points de décision (l’utilisateur peut aller dans deux directions).

Conseil : ne prototypez pas les cas limites dans votre parcours, juste le parcours principal. Si l’utilisateur clique sur un lien qui n’est pas dans le parcours critique, préparez un écran générique “Cette fonctionnalité n’est pas disponible dans ce prototype” redirigez-le vers l’étape suivante du parcours principal, ou ne faites pas de lien dessus. Cela vous fera gagner du temps en explications non nécessaires.

A la fin de cette étape, vous devez avoir un storyboard de 8 à 15 écrans maximum couvrant un parcours utilisateur complet.

Etape 2 : Collecter le contenu réel (30 minutes)

Un prototype avec du “Lorem ipsum” (texte générique sans rapport avec la page) partout ne provoquera aucune réaction utile. Prenez 30 minutes pour rassembler du contenu réaliste :

• Textes : titres, descriptions, labels de boutons, messages d’erreur. Si le contenu final n’existe pas encore, écrivez des textes plausibles.
• Données : noms de produits, prix, dates, quantités. Utilisez de vraies données ou des données réalistes.
• Images : photos de produits, avatars, illustrations. Utilisez Unsplash ou les images du produit existant.

Etape 3 : Construire les écrans dans Figma (4 à 5 heures)

C’est la phase de production. Voici comment optimiser votre temps :

1. Commencez par un frame principal et définissez la taille d’écran cible (mobile 375px ou desktop 1440px). Prenez les templates Figma qui sont très bons.
2. Construisez un premier écran complet avec les composants de base : header, navigation, zones de contenu, boutons. Ce premier écran vous servira de référence pour les suivants.
3. Dupliquez et modifiez. Pour chaque écran suivant, dupliquez le précédent et modifiez uniquement ce qui change. Cela garantit la cohérence et vous fait gagner un temps considérable.
4. Utilisez un design system existant. Figma propose des librairies de composants gratuites (Material Design, iOS, etc.). Utiliser des composants prêts à l’emploi vous fera gagner 2 à 3 heures.
5. Restez en mid-fi. Niveaux de gris, une seule couleur d’accent pour les éléments cliquables. Ne perdez pas de temps sur le design visuel.

Timeboxing : allouez-vous un budget temps par écran. Si votre storyboard fait 10 écrans, vous avez environ 25 à 30 minutes par écran. Si un écran vous prend plus de temps, simplifiez-le.

Etape 4 : Relier les écrans avec le prototypage Figma (30 minutes à 1 heure)

Dans Figma, basculez en mode “Prototype” et reliez les écrans entre eux :

1. Sélectionnez l’élément cliquable (bouton, lien, zone).
2. Tracez un lien vers l’écran de destination.
3. Choisissez une transition simple (dissolution ou glissement). Évitez les animations complexes, elles prennent du temps et n’apportent rien pour un test mid-fi.
4. Testez le parcours complet en mode aperçu. Cliquez sur chaque lien et vérifiez que le parcours est fluide.

Etape 5 : Tester en interne avant le vrai test (30 minutes)

Avant de confronter votre prototype à de vrais utilisateurs, faites d’abord un test avec vous même, puis un test rapide avec un collègue qui n’a pas participé à la conception. Donnez-lui la consigne que vous donnerez aux participants et observez :

• Arrive-t-il au bout du parcours ?
• Y a-t-il des liens manquants ou des culs-de-sac ?
• Comprend-il les intitulés des boutons et des menus ?

Corrigez les problèmes identifiés. Ce test interne de 30 minutes peut vous sauver une session de test utilisateur entière.

La technique du “Wizard of Oz”

Le prototypage “Wizard of Oz” (ou “Magicien d’Oz”) est une technique dans laquelle une partie de l’interaction est simulée manuellement par un humain caché, sans que l’utilisateur ne le sache. Ca peut être utile pour un calcul, un résultat de recherche ou ce genre de choses. C’est un peu désuet à l’air de l’IA.

Le principe

L’utilisateur interagit avec ce qu’il pense être un système automatisé, mais en réalité, c’est un humain (le “wizard”) qui produit les réponses en temps réel. Le terme vient du film : le “grand et terrible Oz” n’est en réalité qu’un homme derrière un rideau.

Exemples concrets

• Chatbot : vous testez un concept de chatbot intelligent. Plutôt que de développer l’IA, un membre de l’équipe tape les réponses en temps réel dans une fenêtre de chat. L’utilisateur pense converser avec un robot.
• Recherche intelligente : vous voulez tester un moteur de recherche qui propose des résultats personnalisés. Le wizard observe la requête de l’utilisateur et sélectionne manuellement les résultats les plus pertinents à afficher.
• Recommandation de produits : vous affichez une interface de recommandation mais les suggestions sont choisies à la main par un expert produit qui observe la session.

Quand utiliser cette technique ?

• Quand la fonctionnalité à tester repose sur une technologie complexe (IA, algorithme, intégration tierce) qui n’est pas encore développée.
• Quand vous voulez valider la proposition de valeur avant d’investir dans le développement technique.
• Quand le cout de développement d’un prototype fonctionnel est trop élevé par rapport à ce que vous voulez vérifier.

Mise en place pratique

1. Identifiez la partie à simuler. Quelle fonctionnalité nécessite une intelligence ou un traitement que vous ne pouvez pas prototyper simplement ?
2. Préparez l’interface “façade”. Construisez l’interface utilisateur normalement dans Figma ou en HTML/CSS.
3. Définissez les scénarios types. Préparez les réponses les plus probables pour que le wizard puisse réagir rapidement.
4. Briefez le wizard. Il doit connaitre le produit, les réponses attendues, et surtout respecter un temps de réponse réaliste (ne pas répondre trop vite, sinon l’utilisateur soupçonnera la supercherie).
5. Mettez en place la communication. Le wizard doit voir ce que fait l’utilisateur (partage d’écran, miroir) et pouvoir modifier l’interface en temps réel (via un outil comme Google Slides, un back-office web simple, ou tout simplement en envoyant les réponses dans le chat).

Les erreurs courantes à éviter

1. Trop de détails trop tôt. C’est l’erreur la plus fréquente chez les designers juniors. Passer 3 jours à peaufiner un prototype haute fidélité alors que la direction de conception n’est même pas validée. Si les utilisateurs ne comprennent pas la structure de votre écran, la beauté de votre design ne changera rien. Commencez toujours par valider la structure avant d’investir dans le visuel.

2. Ne pas tester. Un prototype qui n’est jamais mis entre les mains d’un utilisateur n’est pas un prototype. C’est une maquette. La valeur du prototypage repose entièrement sur ce qu’il vous apprend. Si vous ne testez pas, vous ne faites que du design. Pour savoir comment mener un test, consultez l’article sur les tests utilisateurs.

3. Prototyper tout le produit. Vous n’avez pas besoin de prototyper chaque écran. Concentrez-vous sur le parcours critique : le chemin principal que l’utilisateur suivra pour accomplir sa tâche. Les pages secondaires (mentions légales, paramètres, FAQ) n’ont pas besoin d’être prototypées pour un test.

4. Utiliser du faux contenu. “Lorem ipsum dolor sit amet” ne provoque aucune réaction chez l’utilisateur. Si votre prototype contient du faux texte, l’utilisateur ne pourra pas évaluer la clarté de vos messages, la pertinence de vos labels ou la compréhensibilité de vos descriptions. Utilisez du vrai contenu, même approximatif.

5. S’attacher à son prototype. Le prototype est jetable par définition. Si les tests montrent que le concept ne fonctionne pas, jetez-le et recommencez. C’est le but du prototypage : échouer vite et apprendre vite, plutôt que d’échouer après des mois de développement.

6. Confondre prototype et spécification. Un prototype Figma n’est pas un document de spécification. Il montre ce que le produit fait, pas comment il doit être développé. Complétez vos prototypes avec des annotations techniques si vous les utilisez pour le handoff développeur.

Prototypage et outils : le bon outil pour le bon moment

Mon conseil : Figma couvre 90 % des besoins de prototypage en UX. Investissez du temps pour maitriser les fonctions de prototypage de Figma (composants interactifs, variables, auto-layout) et vous n’aurez besoin d’un autre outil que dans des cas très spécifiques.

Pour aller plus loin

• Le Design Sprint : le cadre de référence pour passer d’une problématique à un prototype testé en 4 jours
• L’atelier sketching : pour explorer des concepts en basse fidélité avec un groupe
• Les tests utilisateurs : pour confronter votre prototype à de vrais utilisateurs
• L’experience map : pour identifier les parcours critiques à prototyper
• Knapp, J. (2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon & Schuster.
• Documentation officielle du prototypage Figma