Aller au contenu principal

Le cycle complet d’une expérience

Un projet UX/UI n’est pas une ligne droite qui part d’une idée et se termine à la mise en ligne. C’est une boucle d’apprentissage : une décision réduit une incertitude, une interface rend l’hypothèse visible, un test révèle l’écart, puis l’équipe choisit la prochaine amélioration.

observer → cadrer → structurer → concevoir → prototyper
    ↑                                             ↓
    └──────── mesurer ← livrer ← tester ←─────────┘

La boucle ne signifie pas « tout recommencer ». Elle signifie conserver une trace de ce qui est connu, de ce qui reste incertain et de la prochaine preuve à produire.

0. Recevoir une idée sans la confondre avec un besoin​

Une demande peut être un symptôme, une contrainte métier ou une solution déjà imaginée. Reformule-la :

Demande : « Ajoutons un tableau de bord. »
Question : quelle décision le tableau de bord doit-il rendre plus facile ?
Personne : qui la prend, dans quel contexte et avec quelles données ?
Preuve : comment verrons-nous que la décision est devenue plus fiable ?

Écris également les non-objectifs. Ils protègent le projet contre le périmètre qui grandit sans preuve.

1. Observer et rechercher​

Choisis une méthode qui répond à l’incertitude : entretien pour comprendre une expérience, observation pour voir le contexte, analyse de contenu pour repérer les mots et les catégories, test de tâche pour vérifier un parcours, données existantes pour mesurer un comportement déjà produit.

Une recherche responsable :

  • obtient un consentement compréhensible ;
  • collecte le minimum nécessaire ;
  • protège les notes et les enregistrements ;
  • ne demande pas une information que l’équipe n’utilisera pas ;
  • conserve les contre-exemples ;
  • explique ce qui est observé et ce qui est interprété.

2. Cadrer le problème​

Le cadrage donne une direction sans prétendre connaître déjà la solution.

Pour [personne] qui [situation],
le problème est [friction observable],
parce que [indice ou contexte].
Nous saurons que cela s’améliore quand [critère observable].
Nous ne cherchons pas à [non-objectif].

Un bon cadrage accepte d’être corrigé. Si la recherche invalide l’hypothèse, le projet a appris quelque chose ; il ne faut pas maquiller ce signal pour conserver la première solution.

3. Structurer l’information et le flux​

Avant la haute fidélité, définis :

  • les intentions principales ;
  • les catégories et leurs étiquettes ;
  • le point d’entrée et le point de sortie ;
  • les données nécessaires à chaque décision ;
  • le flux nominal ;
  • le chargement, le vide, l’erreur, l’accès refusé et la reprise.

Un wireframe simple permet de vérifier l’ordre et la densité sans distraire avec les couleurs. Si les personnes ne trouvent pas le bon contenu en noir et blanc, le polish ne réparera pas la taxonomie.

4. Concevoir l’interface​

Travaille de l’essentiel vers le détail :

  1. sémantique HTML et ordre du contenu ;
  2. objectif principal et action suivante ;
  3. hiérarchie visuelle et largeur de lecture ;
  4. composants et tokens ;
  5. microcopy, aides et erreurs ;
  6. états, focus, responsive et mouvement ;
  7. détails visuels qui renforcent la compréhension.

Chaque décision répond à une question :

  • que doit reconnaître la personne ?
  • que doit-elle pouvoir prévoir ?
  • quel retour reçoit-elle ?
  • comment corrige-t-elle ou annule-t-elle ?

5. Prototyper au bon niveau​

Le prototype est une question matérialisée. Un croquis teste la structure ; un prototype cliquable teste l’ordre, les mots et les états ; un prototype proche du code teste le comportement responsive, la donnée et l’accessibilité.

N’ajoute pas de fidélité sans question correspondante. Une animation parfaite peut donner une illusion de progrès alors que le parcours n’est pas compris.

6. Tester avec des tâches​

Une consigne de test décrit un résultat, pas le chemin :

Tu reviens après deux jours. Reprends ta session d’apprentissage
et explique comment tu sais quelle carte ouvrir.

Observe sans corriger trop vite : premier regard, premier clic, hésitation, retour, erreur, demande d’aide, reformulation et réussite. Demande ce que la personne cherchait à faire ; ne lui demande pas de noter chaque écran comme à l’école.

7. Livrer avec des garde-fous​

Avant la mise en ligne, vérifie :

  • les données affichées et leur source de vérité ;
  • les états de chargement et les erreurs récupérables ;
  • le clavier, le focus, les labels et le contraste ;
  • le mobile, le zoom et le texte long ;
  • la confidentialité et la minimisation des données ;
  • le build, les tests et les logs sans données sensibles ;
  • la version déployée, le smoke test et le retour arrière.

Une livraison UX inclut le contenu et les messages, pas seulement le bundle JavaScript.

8. Mesurer et apprendre après lancement​

Choisis peu de mesures, chacune reliée à une décision. Décris le numérateur, le dénominateur, la population, la période et les limites.

Taux de reprise sans aide
= sessions reprises correctement / sessions interrompues éligibles
Segment : débutants sur mobile
Période : sept jours après la version 2
Si le taux baisse : observer le parcours et vérifier la source de vérité

Une hausse de clics peut cacher une confusion. Surveille les effets secondaires sur erreurs, abandons, accessibilité, confiance et support. Une mesure est un signal pour décider, pas une récompense pour l’équipe.

9. Documenter la décision​

Conserve un journal court :

Faits : …
Hypothèse : …
Décision : …
Preuve attendue : …
Version : …
Résultat : …
Suite : …

Cette trace évite de réouvrir les mêmes débats et permet à une nouvelle personne de comprendre pourquoi le produit ressemble à ce qu’il est. Elle décrit des éléments observables, pas une chaîne de pensée privée.

Exemple fil rouge : reprendre une session​

Une recherche montre que des apprenants reviennent après une interruption mais ne savent pas quelle carte reprendre.

  1. Cadrage : friction observable, débutants, mobile, session interrompue.
  2. Architecture : un état « à reprendre » avec la dernière salle, la carte courante et une action explicite.
  3. Interface : titre, progression textuelle, bouton « Reprendre », erreur réseau récupérable et statut annoncé.
  4. Accessibilité : éléments natifs, focus vers le titre, contraste, responsive, texte sans dépendance au survol.
  5. Prototype : tester l’ordre, le libellé et le message de reprise.
  6. Mesure : reprise correcte sans aide sur sessions éligibles, temps et erreurs de navigation.
  7. Itération : changer une variable à la fois lorsque le signal permet de l’isoler ; documenter le résultat.

Atelier final​

Choisis une friction de ton projet et complète :

  • personne, contexte et comportement observé ;
  • problème et non-objectif ;
  • hypothèse et critère de succès ;
  • flux principal et deux états alternatifs ;
  • structure HTML et action principale ;
  • états de composant, erreurs et récupération ;
  • clavier, lecteur d’écran, mobile, zoom et contraste ;
  • prototype et tâche de test ;
  • métriques avec dénominateurs ;
  • décision d’itération et plan de retour arrière.

Si tu ne peux pas expliquer comment une décision sera vérifiée, elle est encore une préférence ou une hypothèse.

Sources sérieuses​

Le parcours UI/UX interactif transforme chaque étape en production vérifiable. Pour l’implémentation, consulte les composants du système de design et les règles d’accessibilité.