Design UX et UI

Le projet

Vous concevez le parcours d’inscription à une séance d’essai gratuite à la MJC des Tilleuls : choix d’un atelier, réservation et confirmation. Le brief précise les contraintes.

Les exemples suivent Inès, qui commande dans l’appli d’un snack. Dans les ateliers, vous appliquez ces méthodes au site de la MJC, depuis les premiers entretiens jusqu’au test de réservation.

Liens de travail :

• Discord
• Tableau tldraw
• Figma ou Penpot
• draw.io, gratuit et sans compte, pour dessiner les schémas : sitemap, journey, user flow

Les ateliers UX

Les pages UX et UI et Lois de l’UX expliquent les notions utilisées dans ces ateliers.

Les ateliers UI

Travaillez dans un fichier personnel nommé “MJC des Tilleuls, votre prénom”. Indiquez l’origine des éléments UX repris d’un travail de groupe. Créez vos propres écrans et composants, puis faites vos corrections.

Construire la maquette dans Figma

À partir de vos wireframes, préparez les styles et les variables, créez les composants, puis assemblez et testez la maquette. Adaptez au moins la fiche atelier au mobile et au desktop.

Le moodboard et les harmonies colorées sont des approfondissements facultatifs. Pour l’atelier, vous pouvez utiliser la mini-charte du cours.

Gardez le brief, le persona et les user stories à portée de main. Chaque écran doit répondre à un besoin identifié dans ces documents.

Consultez Hiérarchie visuelle et Typographie et couleurs pour choisir les styles. La page User flow, séquence et UML explique le schéma d’enchaînement à rendre avec la maquette. Les diagrammes de séquence et d’états sont facultatifs.

Accessibilité

Apprenez à repérer une barrière, à la tester et à vérifier la correction. Vous appliquerez ces tests à votre projet MJC et ajouterez les résultats au dossier.

• HTML, accessibilité et ARIA
• Tester et documenter l’accessibilité
• Atelier : tester et corriger une page

Coder et présenter le projet

Le dossier à rendre

Rassemblez les rendus dans un dossier “Projet UX/UI, accessibilité et SEO”, dans l’ordre ci-dessous.

Introduction

• Contexte et objectif du projet, à partir du brief.

UX

1. Audit UX du site existant : captures annotées, lois UX et principes de la Gestalt utilisés
2. Deux fiches persona : besoins, motivations et difficultés
3. User journey : reprendre et adapter celui de tldraw ou en créer un. Indiquez s’il décrit le parcours actuel ou le parcours proposé
4. User stories : “En tant que…, je veux…, afin de…”
5. Sitemap du site de la MJC des Tilleuls
6. Story mapping du parcours d’inscription : organiser les étapes et prioriser les fonctionnalités

UI

1. Zoning
2. Wireframes des écrans du parcours choisi
3. Style guide : échelle typographique et palette de couleurs
4. Composants réutilisables et leurs principaux états
5. Maquettes en couleur
6. Prototype cliquable à partir des wireframes ou des maquettes

Accessibilité

1. Les problèmes trouvés sur a-corriger.html et sur un site existant : où, qui est gêné, quelle correction.
2. Trois corrections, avec le test avant et après.
3. Votre fichier corrige.html.

Les consignes de l’atelier détaillent chaque étape.

Présenter le projet

Montrez un problème rencontré, votre solution et une correction issue d’un test. Appuyez-vous sur votre prototype et la page publiée.

Le barème

Ce barème s’applique à chaque personne.

Le lien avec le titre DWWM

Ce module vous prépare à la compétence de maquettage du titre professionnel DWWM, niveau 5, RNCP37674. Les maquettes doivent répondre au besoin, respecter la charte et prévoir l’accessibilité et l’affichage mobile. Joignez un schéma d’enchaînement des écrans.

L’UX et l’UI

UX veut dire user experience, l’expérience utilisateur. UI veut dire user interface, l’interface utilisateur.

L’UX, l’expérience

L’UX couvre ce que vit une personne avant, pendant et après l’utilisation d’un produit. Un ou une UX designer :

• Comprend les besoins et les attentes des utilisateurs.
• Conçoit leur parcours et organise l’information.
• Interroge des utilisateurs et leur fait tester le produit.
• Vérifie que les utilisateurs arrivent à faire ce qu’ils souhaitent.

Ce travail commence avant la conception et se poursuit après la mise en ligne.

L’UI, l’interface

L’UI est la partie visible du produit :

• Les couleurs, les polices et la mise en page.
• Les éléments sur lesquels on agit : boutons, champs, cartes, menus.
• La hiérarchie visuelle, qui fait ressortir les éléments importants.
• La cohérence visuelle d’un écran à l’autre.

Les deux ensemble

Pour une appli de commande dans un snack, l’UX organise le parcours et l’UI dessine les écrans :

Les cinq plans

Jesse James Garrett décrit cinq plans de conception, de la stratégie à l’apparence des écrans. Chaque plan s’appuie sur les décisions du précédent.

L’UX travaille surtout les trois premiers plans. L’UI travaille surtout les deux derniers.

Utile et utilisable

Un site utile répond à un besoin. Un site utilisable permet d’accomplir une tâche sans difficulté. Il peut être utile tout en restant pénible à utiliser.

La norme ISO 9241-11 mesure l’utilisabilité avec trois questions, pour des utilisateurs et une tâche précis :

• L’efficacité : la personne arrive-t-elle au bout de sa tâche ?
• L’efficience : combien de temps et d’efforts lui a-t-il fallu ?
• La satisfaction : comment l’a-t-elle vécu ?

Une affordance est une possibilité d’action offerte par un objet à une personne. Une poignée permet par exemple de saisir une porte. Les indices qui font comprendre cette possibilité sont des signifiants (signifiers) : la forme de la poignée, le libellé d’un bouton ou le soulignement d’un lien. Sur le web, ces indices doivent correspondre à ce que l’élément permet de faire. Don Norman explique cette distinction.

Le design thinking

Le design thinking part des besoins des personnes pour concevoir, prototyper et tester une solution. On le découpe souvent en cinq étapes. Un test peut conduire à revenir sur une décision précédente.

flowchart TD
    accTitle: Les cinq étapes du design thinking
    accDescr: Empathie, définition, idéation, prototypage et test. Chaque étape mène à la suivante, et on peut revenir à la précédente.
    E["Empathie<br>Mieux connaître les usagers"] <--> D["Définition<br>Poser un problème précis"]
    D <--> I["Idéation<br>Chercher des idées et des solutions"]
    I <--> P["Prototypage<br>Fabriquer vite et pas cher"]
    P <--> T["Test<br>Faire essayer, puis améliorer avec les retours"]

À lire et à regarder

• L’UX, 60 secondes pour comprendre, vidéo d’Orange.
• L’UX Design c’est quoi ?, vidéo de la chaîne UX Time.
• Faites la différence entre UX et UI et Familiarisez-vous avec la notion d’usabilité, deux chapitres du cours gratuit d’OpenClassrooms.
• Comprenez le principe d’affordance, OpenClassrooms.
• It’s not you. Bad doors are everywhere., vidéo de Vox sur les portes qu’on pousse au lieu de les tirer. En anglais, activez les sous-titres.
• Dopamine, série d’ARTE. Chaque épisode montre comment une appli connue est conçue pour qu’on y revienne.
• Comment le web vous arnaque ? (Les dark patterns), vidéo de Basti UI. Un dark pattern est une interface conçue pour piéger l’utilisateur, par exemple un désabonnement caché.
• Whatnot : le nouveau sponsor YouTube qui te met en danger, enquête de Basti UI. Une appli d’enchères en direct reprend des mécanismes des casinos pour qu’on y reste.

Pour la discussion

• Une appli qui vous énerve : laquelle, et à quel moment précis ?
• Ce problème vient-il de l’UX ou de l’UI ?
• Une appli conçue pour qu’on y passe le plus de temps possible offre-t-elle une bonne expérience ? Bonne pour qui ?

Le roasting

Un roasting consiste ici à examiner une interface et à expliquer ce qui aide ou gêne son utilisation.

Choisissez un site de MJC ou de centre socioculturel. Cherchez une activité pour un jeune de 17 ans et comment s’y inscrire.

Gardez une idée à reprendre et un problème à éviter dans votre projet, avec une capture. Déposez vos remarques dans votre fichier de projet.

Arrêtez-vous avant tout envoi de formulaire. Ne créez pas de compte et ne payez rien.

Appuyez vos critiques sur un élément de l’interface et son effet sur la tâche. Par exemple : “Le bouton d’inscription est caché sous la photo, je ne l’ai pas trouvé.” Respectez les personnes qui ont conçu le site et choisissez des captures adaptées à un cours.

Les lois de l’UX

Les lois de l’UX décrivent comment les personnes perçoivent une interface, choisissent et agissent. Voici quatre lois et des principes de la Gestalt à utiliser dans l’audit UX. Vous trouverez d’autres lois sur Laws of UX.

La loi de Fitts

Plus une cible est grande et proche du pointeur, plus on l’atteint vite.

Dans une interface :

• Les boutons importants sont grands et faciles à atteindre.
• Deux boutons trop proches augmentent le risque d’erreur.
• Sur téléphone, chaque cible doit être assez grande pour un doigt.

Paul Fitts a publié sa formule en 1954 : T = a + b × log₂(2D / L). T est le temps pour atteindre la cible, D la distance, L la largeur de la cible. a et b dépendent du pointeur : souris, doigt, pavé tactile.

Fiche Laws of UX : loi de Fitts

La loi de Hick

Le temps de décision augmente avec le nombre et la complexité des choix.

Dans une interface :

• Les options d’un formulaire sont regroupées par sujet.
• Un menu garde peu d’entrées, rangées en groupes.
• Une longue liste a une recherche ou des filtres.

Fiche Laws of UX : loi de Hick

La loi de Jakob

Les gens passent la plupart de leur temps sur d’autres sites que le vôtre. Ils s’attendent à ce que votre site marche comme ceux qu’ils connaissent déjà.

Dans une interface :

• Le logo en haut à gauche ramène à l’accueil.
• Le panier est en haut à droite.
• Un texte souligné dans un paragraphe est un lien.

Si vous changez une convention, vérifiez que les utilisateurs comprennent la nouvelle interface.

Fiche Laws of UX : loi de Jakob

L’effet de gradation du but

Plus on se rapproche d’un but, plus on fait d’efforts pour l’atteindre. En anglais, on parle de goal-gradient effect.

Dans une interface :

• Une barre de progression montre ce qui reste à faire, par exemple “Étape 2 sur 3”.
• Un long formulaire est découpé en étapes, et chaque étape finie fait avancer la barre.
• Un avantage réel déjà obtenu apparaît dès le départ, comme deux tampons offerts sur une carte de fidélité.

En 2006, les chercheurs Joseph Nunes et Xavier Drèze ont distribué des cartes de fidélité dans une station de lavage. La première carte demandait 8 tampons. La seconde en demandait 10, dont 2 déjà offerts. Il fallait donc 8 lavages dans les deux cas. 19 % des clients ont rempli la première carte, et 34 % la seconde.

La progression affichée doit correspondre aux étapes restantes. Une barre trompeuse conçue pour retenir l’utilisateur est un dark pattern.

Fiche Laws of UX : effet de gradation du but

Les principes de la Gestalt

Au début du XXe siècle, des psychologues ont étudié comment nous regroupons les formes que nous voyons. Leurs principes, dits de la Gestalt (forme en allemand), aident à organiser un écran.

Fiches Laws of UX : loi de proximité, loi de similarité.

À lire et à regarder

• Les lois de l’UX par Maze, avec des captures d’interfaces réelles. En anglais.
• Concevez un produit simple, OpenClassrooms.
• Pourquoi le web est devenu si moche ?, vidéo de Basti UI sur la ressemblance entre les sites web. Regardez-la avec la loi de Jakob en tête.
• The UX Psychology Behind Apps People Can’t Stop Using, vidéo d’uxpeak. Six principes de psychologie, chacun avec un écran avant et après, dont une barre de progression qui ne part pas de zéro. En anglais, avec des sous-titres automatiques.

Repérer un principe UX

Cette observation peut se faire pendant le roasting ou l’audit : repérez une loi UX sur le site choisi et expliquez son effet sur votre tâche.

Pour la discussion

• Quel principe avez-vous trouvé le plus souvent ?
• Quel problème de ce site voulez-vous éviter dans votre page d’inscription ?

L’audit UX

Un audit UX repère ce qui aide ou gêne une personne lorsqu’elle utilise une interface.

1. Choisissez un site ci-dessous et faites la tâche proposée.
2. Notez ce qui vous aide ou vous gêne, en vous appuyant sur les lois UX vues en cours.
3. Ajoutez une capture pour illustrer vos remarques et proposez une amélioration.

Déposez le tout dans la section “Audit UX” de votre fichier Figma ou Penpot.

Les sites au choix

Ne créez pas de compte et ne publiez rien.

Les lois pour vous guider

Un exemple

Exemple pour l’appli d’un snack imaginaire :

Décrivez l’action et l’obstacle observés : “J’ai appuyé sur Annuler en voulant commander” permet de comprendre le problème.

Pour la discussion

• Une interface dense gêne-t-elle forcément la lecture ?
• Comment organiser beaucoup de choix sans en supprimer ?
• Un débutant et un habitué rencontrent-ils les mêmes difficultés sur Photopea ?
• Un site qui tient compte des cinq lois est-il forcément facile à utiliser ?

Pour approfondir

• Choisissez une autre loi sur Laws of UX et cherchez un exemple sur votre site.
• Lisez les 10 heuristiques de Nielsen, une autre grille d’audit très utilisée. En anglais.

Préparer la réservation

Le brief

La MJC des Tilleuls est une maison des jeunes et de la culture fictive. Elle propose des ateliers pour les 15–25 ans : photo, escalade, musique, théâtre, graff, jeu de rôle… La séance d’essai est gratuite et sans engagement.

Vous concevez le parcours qui permet de choisir un atelier, de réserver une séance d’essai et d’obtenir une confirmation. Ce projet relie tous les ateliers du cours.

Les règles du projet

Ces règles sont fixées pour l’exercice :

• Les ateliers accueillent les 15–25 ans, débutants compris.
• Le matériel est fourni. Prévoyez une tenue adaptée pour le sport. Un téléphone suffit pour la photo.
• La réservation demande un prénom, un nom, un âge, une adresse e-mail et une séance.
• Les moins de 18 ans peuvent réserver. Un message leur demande d’apporter une autorisation parentale le jour de la séance.
• Chaque séance a dix places. Quand elle est complète, on peut rejoindre une liste d’attente. La MJC contacte la personne par e-mail si une place se libère.
• La confirmation rappelle l’atelier, la date, l’heure, le lieu et ce qu’il faut apporter.

Choisissez une date, un horaire et un lieu fictifs pour votre séance. Si une autre information manque, proposez une solution et notez votre hypothèse.

Préparer votre parcours de réservation

1. Choisissez une activité pour votre MJC : photo, escalade, musique…
2. Interrogez une personne sur une inscription à une activité qu’elle a réellement vécue. Utilisez les questions ci-dessous et notez les difficultés qu’elle décrit.
3. À partir de ce récit et du brief, notez les informations à afficher et les actions à permettre.

Les questions à poser

• “Raconte la dernière fois que tu t’es inscrit à une activité.”
• “Comment as-tu choisi et trouvé les informations nécessaires ?”
• “Qu’est-ce qui t’a compliqué la tâche ou fait hésiter ?”

Pour préciser une réponse, demandez un exemple : “À quel endroit as-tu cherché cette information ?” ou “Qu’as-tu fait quand tu n’as pas trouvé ?” Un récit suffit pour cet exercice.

Rendu

Dans votre fichier Figma ou Penpot, créez une frame “1–2. Préparer la réservation” avec :

• L’activité choisie.
• Deux ou trois besoins ou difficultés entendus dans le récit.
• Ce que vous prévoyez dans le site pour y répondre.

Exemple fictif :

Séparez ce que la personne a raconté de ce que vous supposez. Marquez vos suppositions “à vérifier”. Notez seulement un prénom ou une initiale pour identifier le récit, sans coordonnées personnelles. Ce témoignage ne représente pas tous les utilisateurs.

Gardez cette frame pour construire ensuite votre persona et vos user stories.

Le persona

Un persona est un profil fictif construit à partir de besoins, d’objectifs et de difficultés observés. L’équipe s’y réfère pour choisir les contenus, les fonctionnalités et l’ordre des écrans. Sa fiche résume le brief et les entretiens, sans remplacer les échanges avec les utilisateurs.

Pourquoi en créer ?

Si les personnes interrogées hésitent à réserver sans connaître le matériel nécessaire, notez ce frein dans le persona. L’équipe peut alors afficher le matériel avant le bouton de réservation.

Il sert aussi à vérifier les suppositions de l’équipe. “Les jeunes veulent tous réserver sur téléphone” est une hypothèse tant que personne ne l’a confirmé. Notez-la comme telle, puis confrontez-la aux entretiens et aux tests.

Ce que contient la fiche

Gardez les détails qui peuvent changer une décision de conception. Une profession ou une tranche d’âge sans lien avec l’objectif n’aide pas à choisir un écran.

Deux exemples illustrés

Ces deux profils illustrent des besoins différents : acheter en ligne et trouver des conseils sur les plantes. Leur fiche dépend du projet, comme celle que vous créez pour la MJC.

Leur âge et leur métier donnent un contexte. Ce sont leurs objectifs, leurs freins et leur usage qui orientent ici les choix de conception.

Un exemple suivi dans ce cours

Inès est le persona de l’appli d’un snack de quartier. Le snack veut éviter la queue à midi.

Cet exemple fictif conduit à afficher les prix avant la commande et à prévenir Inès quand sa commande est prête. Vous retrouverez Inès dans les user stories et le parcours utilisateur. Pour votre persona, utilisez les propos et les difficultés recueillis en entretien.

Un persona et l’accessibilité

Pierre est un développeur aveugle qui utilise un lecteur d’écran. Sur un formulaire, une image sans texte alternatif ou un bouton sans nom lui cache une information ou une action.

Ces vérifications concernent la fiche de l’atelier, le formulaire et sa confirmation. Un persona rend un obstacle concret, mais ne couvre pas à lui seul tous les besoins d’accessibilité. Les cinq personas d’Orange montrent d’autres situations à examiner.

Atelier : créer un persona

Reprenez la frame “1–2. Préparer la réservation”. Créez un seul profil à partir du brief et du récit entendu : son objectif et ses principaux freins. Signalez ce que vous supposez avec “à vérifier”. Notez ce que ce profil vous conduit à prévoir sur la page.

Rendu : une fiche persona dans votre fichier de projet.

Pensez à tout le monde

Vos entretiens ne couvrent pas tous les besoins. Pensez aussi aux personnes qui lisent difficilement, distinguent mal les couleurs ou utilisent seulement le clavier. Si vous ajoutez un besoin que personne n’a exprimé, marquez-le “à vérifier”. Vérifiez aussi ces besoins sur votre page codée.

À lire

• Définissez un persona, OpenClassrooms.
• Persona en UX design : à quoi sert-il et comment le créer ?, Usabilis.
• Qu’est-ce qu’un persona UX ?, avec des exemples et des modèles.

Pour la discussion

• Dans votre persona, qu’est-ce qui vient des entretiens ? Qu’est-ce qui reste à vérifier ?
• Quelle décision de votre page vient d’un besoin du persona ?
• Un persona inventé par une IA, sans entretien, est-ce de la recherche ?

Les user stories

Une user story décrit ce qu’une personne veut faire et dans quel but.

Écrire une story

En tant que [persona], je veux [action] afin de [but].

Par exemple : “En tant qu’Inès, lycéenne, je veux voir les menus et leurs prix afin de choisir un repas à moins de 7 €.”

Décrivez ce que la personne veut faire. “Je veux un bouton vert” décrit déjà une solution.

Vérifier la story

Un critère d’acceptation précise ce qu’on doit pouvoir constater sur la page. Pour la story ci-dessus :

• Chaque menu affiche son prix et ce qu’il contient.
• Un menu indisponible est signalé comme tel.
• Si aucun menu n’est disponible, la page l’indique clairement.

Une bonne story

Les équipes vérifient leurs stories avec six critères, résumés par le mot anglais INVEST.

Une story décrit un besoin. Une spécification technique décrit comment réaliser la solution.

La story map

Une liste de stories ne montre pas le parcours en entier. La story map range les stories dans l’ordre où l’utilisateur les vit. Jeff Patton a rendu cette méthode populaire dans les équipes agiles.

Une équipe agile peut livrer un produit par petites versions, recueillir des retours, puis améliorer la suivante. La méthode Scrum est expliquée dans le cours Stories et backlog.

À quoi elle sert

• Voir le parcours complet, là où le backlog présente une liste de travaux à réaliser.
• Repérer les trous, par exemple une étape sans aucune story.
• Choisir ce qui entre dans la première version, et ce qui attend.
• Parler du produit avec toute l’équipe : design, développement, client.

Les trois niveaux

• Les activités sont les grandes tâches de l’utilisateur, par exemple “Commander un repas”.
• Les étapes découpent chaque activité, dans l’ordre, de gauche à droite.
• Les détails sont les actions précises de chaque étape. Ils s’empilent sous leur étape, le plus important en haut.

Chaque carte décrit ce que fait l’utilisateur. On écrit “Payer par carte”, pas “Appeler l’API de paiement”. Chaque détail devient ensuite une story, avec ses critères d’acceptation. Dans le backlog, une étape peut correspondre à une epic, un ensemble de besoins à découper en plusieurs stories.

La ligne de version

Une ligne horizontale, la release line, sépare la première version du reste. Au-dessus de la ligne, l’équipe place ce qu’elle livre d’abord. Cette première version doit permettre de faire tout le parcours, même simplement. On l’appelle le produit minimum viable, ou MVP (minimum viable product).

Dans votre projet, la première version est la page de réservation à coder.

Un exemple

Voici la story map de l’appli du snack. Elle se lit de gauche à droite, puis de haut en bas.

block-beta
  columns 4
  a["Commander un repas"]:4
  e1["Trouver<br>un plat"] e2["Composer<br>son menu"] e3["Payer"] e4["Récupérer"]
  v1["Version 1"]:4
  d1["Lire le menu<br>et les prix"] d2["Ajouter un plat<br>au panier"] d3["Payer<br>par carte"] d4["Montrer<br>son numéro"]
  d5["Voir le prix<br>étudiant"] d6["Choisir<br>sa boisson"] d7["Voir la<br>confirmation"] space
  v2["Plus tard"]:4
  d8["Voir les photos<br>des plats"] d9["Reprendre son<br>menu habituel"] d10["Payer avec<br>ses points"] d11["Être prévenue<br>quand c'est prêt"]
  classDef activite fill:#3b0764,stroke:#3b0764,color:#ffffff
  classDef etape fill:#7c3aed,stroke:#7c3aed,color:#ffffff
  classDef ligne fill:transparent,stroke-dasharray:6 4
  class a activite
  class e1,e2,e3,e4 etape
  class v1,v2 ligne

La première version permet à Inès de commander et de payer, sans photos ni points de fidélité. Elle règle les deux blocages de son journey : le prix étudiant est affiché, et une confirmation suit le paiement.

Story map ou journey map

La journey map suit la personne : ce qu’elle fait, pense et ressent, sur tous les canaux. La story map suit le produit : ce que l’équipe va construire, et dans quel ordre. Les étapes d’un journey peuvent servir de départ aux étapes d’une story map.

Atelier : écrire les besoins du persona

1. Reprenez le brief MJC et votre persona. En haut de la carte, notez l’activité “Réserver une séance d’essai”. Placez les étapes de gauche à droite : choisir un atelier, réserver un créneau, connaître le résultat.
2. Sous chaque étape, placez les actions précises de la personne, une par carte. Rangez les plus importantes en haut. Prévoyez aussi ce qui se passe si la séance est complète ou si la personne est mineure.
3. Tracez une ligne entre la première version et les améliorations futures. Vérifiez qu’avec les cartes au-dessus de la ligne, la personne peut aller du choix de l’atelier au résultat de sa réservation. Les règles du brief doivent être respectées dès cette version, y compris la liste d’attente et le message sur l’autorisation parentale.
4. À partir des cartes de cette première version, écrivez trois user stories : une pour choisir un atelier, une pour réserver un créneau et une pour connaître le résultat. Utilisez la forme “En tant que…, je veux… afin de…”.

Pour la réservation, ajoutez deux critères qui permettront de vérifier qu’elle fonctionne. Gardez en tête la séance complète et l’accord parental.

Rendu : la story map avec sa ligne de version, trois stories et deux critères dans la frame “4. Story map et user stories” de votre fichier de projet.

Pour aller plus loin

• Stories et backlog : scénarios, backlog et priorités.
• Mapping User Stories in Agile, Nielsen Norman Group : les trois niveaux, les lignes de version et la différence avec la journey map. En anglais.

Pour la discussion

• Quelle story compte le plus pour votre persona ? Pourquoi ?
• Une de vos stories décrit-elle une solution plutôt qu’un besoin ?
• Parmi vos stories, lesquelles entrent dans la première version ?

Le parcours utilisateur

Le parcours utilisateur, ou user journey, décrit les étapes suivies par une personne pour atteindre un objectif. Il inclut ses actions, ses pensées et ses émotions, y compris avant et après la visite du site. La journey map représente ce parcours sous forme de carte.

Trois mots proches

• Le customer journey suit un client dans toute sa relation avec une marque : la publicité, l’achat, le service après-vente. Le marketing s’en sert.
• Le user journey suit un persona qui veut atteindre un but précis avec votre produit. C’est celui que vous dessinez.
• Le user flow montre les écrans et les choix à l’intérieur du produit, sans les émotions. Il est expliqué sur la page User flow, séquence et UML.

Une carte peut montrer le parcours actuel ou celui que l’on veut concevoir. La MJC des Tilleuls est fictive : vous dessinez un parcours envisagé, en vous appuyant sur les expériences d’inscription racontées en entretien. Distinguez les faits recueillis de vos hypothèses.

Ce que contient la carte

En haut de la carte, notez le persona, son but et ses attentes. La ligne des émotions se dessine souvent comme une courbe. Ses creux signalent des difficultés à examiner. Si l’émotion est supposée, notez-la comme une hypothèse.

Comment faire une journey map

1. Choisissez un persona et un but. Une carte suit une seule personne.
2. Fixez le début et la fin du parcours, par exemple de “j’ai faim” à “j’ai mangé”.
3. Découpez le parcours en 4 à 6 étapes. Nommez chaque étape avec un verbe : découvrir, choisir, commander.
4. Remplissez les lignes pour chaque étape à partir de vos entretiens. Marquez “à vérifier” les cases que vous avez imaginées.
5. Tracez la courbe des émotions et repérez le point le plus bas.
6. Écrivez une piste pour chaque blocage. Le point le plus bas passe en premier.

Un exemple

Inès, 17 ans, commande au snack pour sa pause de midi. Son but : manger en moins de 20 minutes sans dépasser 7 €. Elle attend des prix clairs et une commande prête à l’heure.

%%{init: {"journey": {"leftMargin": 70, "width": 115, "taskMargin": 20}}}%%
journey
    accTitle: La courbe des émotions d'Inès
    accDescr: Chaque étape a une note de 1, très négatif, à 5, très positif. Le point le plus bas est la commande, sans confirmation.
    title Inès commande au snack
    section Découvrir
      Voit l'affiche: 3: Inès
    section Choisir
      Cherche le prix étudiant: 2: Inès
    section Commander
      Paie sans confirmation: 1: Inès
    section Récupérer
      Reçoit son menu: 4: Inès

Inès est surtout inquiète après le paiement : elle ne sait pas si sa commande a été reçue. L’écran doit lui donner une confirmation visible.

Atelier : dessiner le parcours du persona

Dessinez le parcours de votre persona, de la découverte de l’atelier à sa première séance. Pour chaque étape, notez ce qu’il fait, ce qu’il ressent et ce qui peut le bloquer.

Repérez le principal blocage et proposez une amélioration. Marquez “à vérifier” ce que vous supposez.

Rendu : un schéma dans votre fichier de projet. Un dessin sur papier pris en photo convient.

À lire

• Qu’est-ce que le parcours utilisateur ?, blog-ux.
• La carte du parcours utilisateur, avec un modèle à télécharger.
• Customer journey map : cartographier le parcours client, L’ADN, avec l’exemple d’un site d’annonces immobilières.
• User journey mapping, Figma : les éléments d’une carte, la différence avec le customer journey, et un exemple. En anglais.
• Journey Mapping 101, Nielsen Norman Group. En anglais.
• User Journeys vs. User Flows, Nielsen Norman Group, avec la journey map d’un patient qui cherche un médecin. En anglais.

Pour la discussion

• Quel est le moment le plus difficile de votre journey ?
• Ce moment se passe-t-il sur la page, ou avant, ou après ?

L’architecture de l’information

L’architecture de l’information organise et nomme les contenus pour aider les personnes à les trouver. Son abréviation anglaise, IA pour information architecture, apparaît dans le schéma ci-dessous. Elle ne désigne pas ici l’intelligence artificielle.

Trois cercles

Louis Rosenfeld et Peter Morville ont écrit un livre de référence sur l’architecture de l’information. Ils la placent au croisement de trois cercles.

%%{init: {"venn": {"width": 440, "height": 400}}}%%
venn-beta
  set U["Utilisateurs"]
  set C["Contenu"]
  set X["Contexte"]
  union U,C,X["IA"]
  style U fill:#3b82f6, fill-opacity:0.25
  style C fill:#eab308, fill-opacity:0.25
  style X fill:#ec4899, fill-opacity:0.25

Un menu rangé avec les mots du restaurateur peut être difficile à comprendre pour ses clients. Si ces clients commandent sur leur téléphone, une interface conçue seulement pour un grand écran risque aussi de les gêner.

De la structure aux écrans

Pour passer du contenu aux écrans, vous utiliserez trois documents :

Le sitemap

Le sitemap, ou arborescence, montre comment les pages du site sont regroupées. L’accueil est à la racine. Les liens de navigation déterminent ensuite le chemin réel entre les pages.

Voici le sitemap de l’appli d’un snack de quartier :

%%{init: {"flowchart": {"rankSpacing": 32, "nodeSpacing": 24}}}%%
flowchart LR
    accTitle: Le sitemap de l'appli du snack
    accDescr: L'accueil mène au menu, à la commande, à la fidélité, aux infos pratiques et au compte. Le menu se divise en plats, boissons et desserts. La commande contient le paiement et la confirmation.
    A[Accueil] --> M[Menu]
    M --> M1[Plats]
    M --> M2[Boissons]
    M --> M3[Desserts]
    A --> C[Ma commande]
    C --> C1[Paiement]
    C --> C2[Confirmation]
    A --> F[Fidélité]
    A --> I[Infos pratiques]
    I --> I1[Horaires et adresse]
    I --> I2[Allergènes]
    A --> K[Mon compte]

Plat ou profond

Regrouper les pages sous des intitulés clairs peut aider à choisir sans parcourir tout le site.

La navigation

La navigation relie les pages entre elles. Un site combine en général plusieurs types.

Atelier : organiser les pages du site

Dessinez l’arbre des pages de votre site. Donnez-leur des noms clairs et indiquez où se trouvent les informations nécessaires à l’inscription.

Vérifiez que votre persona peut trouver un atelier et réserver. Distinguez les pages de leur contenu : une confirmation peut être un état du formulaire.

Rendu : le sitemap dans votre fichier de projet. Un schéma simple suffit.

À lire

• What is information architecture?, Figma : les trois cercles, les systèmes d’organisation, de nommage (labeling), de navigation et de recherche, et les huit principes de Dan Brown. En anglais.
• Breadcrumbs: 11 Design Guidelines, Nielsen Norman Group, sur le fil d’Ariane. En anglais.

Pour la discussion

• Quelle carte a été la plus difficile à ranger ? Pourquoi ?
• En combien de clics votre persona arrive-t-il à la réservation depuis l’accueil ?

Le zoning et les wireframes

Inès ouvre l’appli du snack pour trouver un repas à moins de 7 €. Pour concevoir cet écran, il faut choisir où placer les plats et leurs prix, quelles informations afficher et comment passer une commande.

Le zoning, le wireframe, le mockup et le prototype permettent d’examiner ces choix à différents niveaux de détail. Vous allez les distinguer, puis dessiner le zoning et les wireframes de votre projet MJC.

Du besoin UX aux écrans de la MJC

Reprenez le brief, le persona et les user stories. Ils précisent les règles du service, les besoins à traiter et les résultats à vérifier.

Exemple : Yanis, 17 ans, veut réserver une séance d’essai et savoir quoi apporter. Ce profil fictif permet d’illustrer les règles du brief, sans remplacer vos entretiens.

Distinguez une page et ses états : la confirmation peut s’afficher dans le formulaire, sans créer une page dans le sitemap. Le schéma d’enchaînement montre comment passer d’un écran ou d’un état à l’autre.

Pour la story “En tant que mineur, je veux réserver une séance afin de découvrir une activité”, le brief impose de permettre la réservation dès 15 ans et d’indiquer l’autorisation parentale à apporter. Le wireframe prévoit ce message, la maquette le rend lisible et le test vérifie qu’il est compris. Un besoin du persona guide la présentation, sans supprimer une règle du brief.

Un test peut vous amener à revoir le contenu ou l’ordre des écrans. Le style guide et les composants vous aideront ensuite à appliquer les mêmes choix dans le code.

Du zoning au prototype

Ces représentations de l’interface sont des livrables : des dessins ou des fichiers que l’on partage pour discuter des choix de conception.

Dans ce cours, maquette désigne la maquette graphique. Le mot peut avoir un sens plus large dans une équipe : précisez si vous attendez un dessin en gris, un écran avec ses styles ou un parcours à essayer.

On peut relier des wireframes pour les tester avant de travailler les couleurs. Si le test révèle qu’une information arrive trop tard, on peut revenir au zoning pour changer sa place.

Avant le zoning, un croquis au crayon suffit souvent pour essayer une idée. Voici le croquis, le zoning et le wireframe de la page d’une voiture électrique :

Le zoning

Le zoning fixe la place des grandes zones d’un écran. On dessine des blocs nommés, avant de détailler leur contenu dans le wireframe.

1. Placez d’abord les informations nécessaires au choix de l’atelier.
2. Organisez les zones autour des besoins du persona.
3. Dessinez des blocs et nommez-les. Gardez les textes détaillés, les images et les couleurs pour la suite.

Voici le zoning de la page menu du snack, sur téléphone :

block-beta
  columns 1
  a["En-tête"]
  b["Recherche"]
  c["Catégories"]
  d["Liste des plats, avec les prix"]
  e["Bouton Commander"]

Le parcours d’Inès a montré qu’elle cherchait le prix du menu étudiant. On prévoit donc de l’afficher dans la liste des plats.

Imaginez deux zonings : dans le premier, une grande présentation du snack repousse la liste des plats en bas. Dans le second, la liste apparaît juste après les catégories. Pour Inès, qui doit choisir pendant sa pause, le second donne plus tôt accès aux prix. Vous pouvez comparer ces deux organisations avec quelques rectangles.

Avant de détailler l’écran, demandez à une autre personne de repérer la liste des plats et l’accès à la commande sur votre zoning. Si une zone manque ou semble mal placée, déplacez-la maintenant.

Un autre exemple montre une page d’accueil en zoning, en wireframe puis en prototype. Le bleu repère ici les éléments prévus pour être cliquables. Cette image fixe ne permet pas d’essayer leurs réactions : il faut ouvrir le prototype pour cela.

Le wireframe

Un wireframe, ou maquette fil de fer, détaille le contenu des zones : titres, textes, champs et boutons. Dans cet atelier, il reste en gris pour concentrer la discussion sur ce que la personne comprend et peut faire.

Vérifiez d’abord si les horaires sont faciles à trouver, les libellés compris et les actions complètes. Le gris aide à concentrer ce premier échange sur l’organisation. Il n’est pas obligatoire pour tous les wireframes et ne garantit pas leur accessibilité : vérifiez aussi les contrastes et les états.

Voici le wireframe de la même page :

Un rectangle barré d’une croix remplace une image.

Le zoning disait “Liste des plats, avec les prix”. Le wireframe écrit “Menu étudiant, 6,50 €”. Inès peut maintenant comparer ce prix à son budget. Le libellé “Commander” indique l’action proposée.

Le dessin laisse toutefois une décision ouverte : comment sélectionner un plat avant de commander ? Ajoutez un bouton “Ajouter” sur chaque ligne ou prévoyez une fiche qui permet de choisir. Annotez le comportement retenu. Un bouton dessiné indique une action possible, mais ne la fait pas encore fonctionner.

Un wireframe peut aussi se dessiner à la main. Sur ces deux écrans d’une appli de commandes, les croix marquent les images et des vagues remplacent les paragraphes. Les titres et les boutons gardent leurs vrais mots : “Cancel”, “Accept”.

Basse et haute fidélité

La fidélité désigne le degré de ressemblance avec le produit prévu. L’apparence, les contenus et les interactions peuvent avoir des niveaux de détail différents. Un croquis simple peut ainsi contenir des textes réalistes.

Dans cette illustration, haute fidélité désigne le wireframe plus détaillé du milieu. Le niveau de détail visuel ne dit pas si un écran est interactif : une image très soignée peut être statique, et un croquis peut servir à tester un parcours. Nielsen Norman Group distingue ces dimensions de la fidélité.

Pour cet atelier, restez en basse fidélité, avec de vrais libellés. Les styles se travaillent dans la maquette.

Pourquoi faire des wireframes

• Pour vérifier l’ordre des contenus avant de choisir les couleurs.
• Pour discuter avec le client et les développeurs à partir d’un même dessin.
• Pour déplacer un champ ou une section sans reprendre les styles d’une maquette détaillée.

Ce qu’on évite

• Les couleurs, les polices décoratives et les photos. On les choisit à l’étape de la maquette.
• Le faux texte lorem ipsum dans les titres et les boutons. Écrivez les vrais libellés : “Commander” dit ce que fait le bouton.
• Les détails : ombres, arrondis, icônes.

Pourquoi utiliser du vrai texte

Lorem ipsum remplit une surface, mais ne permet pas de vérifier si une personne comprend quoi faire. “Rejoindre la liste d’attente” indique une autre action que “Réserver”. Le message sur l’autorisation parentale permet de vérifier si un mineur comprend ce qu’il doit apporter.

Les vrais libellés révèlent aussi les problèmes de longueur : un nom d’atelier peut prendre deux lignes, un bouton peut déborder. Utilisez-les dès le wireframe, avec les règles du brief. Les noms, dates et coordonnées peuvent être fictifs. Signalez les textes provisoires et gardez une longueur réaliste.

Le mockup, ou maquette graphique

Le mockup montre l’apparence prévue de l’écran. On applique le style guide aux contenus du wireframe : typographie, couleurs, espacements, images et icônes.

Sur la page du snack, les rectangles barrés deviennent des photos de plats. On règle la taille et le contraste du prix de 6,50 € pour qu’il soit lisible sur téléphone. Le bouton “Commander” reprend le style des actions principales.

Examinez la maquette à la taille d’un téléphone : le prix se distingue-t-il de la description ? Un nom de plat long reste-t-il lisible ? Le bouton se reconnaît-il comme une action ? Si un texte ne tient pas, adaptez la mise en page. Le wireframe reste une base que l’on peut corriger.

À ce stade, vous pouvez montrer l’aspect du panier. Pour observer comment Inès y ajoute un menu puis corrige sa commande, il faut simuler ces actions.

Le prototype

Un prototype permet d’essayer une partie du fonctionnement prévu. On prépare les réactions aux actions de la personne, par exemple l’ouverture du panier ou l’affichage d’une confirmation.

Pour le snack, reliez uniquement les écrans nécessaires au scénario :

1. Sur la liste des plats, “Ajouter” place le menu étudiant dans un panier simulé.
2. Le panier affiche le menu, sa quantité et le total. “Retirer” permet de revenir à un panier vide.
3. “Commander” ouvre le récapitulatif et les étapes prévues pour valider la commande.
4. Une confirmation donne le numéro de commande et l’heure de retrait.

Faites essayer ce parcours avec la consigne : “Tu as 7 € et vingt minutes pour déjeuner. Commande un repas, puis indique quand tu pourras le récupérer.” Notez si la personne trouve le prix, comprend le total et repère l’heure de retrait.

Dans ce prototype d’exercice, aucun paiement n’est encaissé et aucune commande n’est envoyée au snack. Les écrans simulent ces résultats. Si une action n’a pas été préparée, notez cette limite au lieu de conclure que la personne ne sait pas utiliser l’interface.

Tester dès les wireframes

Vous pouvez faire ce premier essai avec des écrans en gris reliés dans Figma ou Penpot. Sur papier, la personne qui teste pointe un bouton ou un lien du doigt et vous présentez la feuille correspondant au résultat. Dans les deux cas, vous observez ses choix avant de finaliser les styles.

Si la personne cherche comment retirer le menu du panier, ajoutez ou clarifiez cette action et refaites l’essai. Les étapes pour relier les écrans et conduire le test sont détaillées dans La maquette et le test.

Quel livrable choisir ?

Choisissez le livrable selon la question à résoudre.

À vous de reconnaître

Pour chaque cas, nommez le livrable et dites ce qu’il permet de vérifier :

1. Une feuille contient quatre rectangles : “En-tête”, “Atelier”, “Créneaux”, “Réservation”.
2. Un écran gris montre le champ “E-mail”, un exemple de saisie et un message d’erreur.
3. Une image de la fiche atelier présente les photos, les couleurs et les polices retenues. On ne peut pas agir dessus.
4. Trois écrans en gris sont reliés. Un clic sur “Réserver” ouvre le formulaire, puis la confirmation.

Les outils de Figma

Figma permet de dessiner et de relier des écrans dans le navigateur. Plusieurs personnes peuvent modifier le même fichier en même temps. Nommez les calques et réutilisez les styles et les composants : vous retrouverez plus facilement un élément à corriger ou à reproduire en code.

L’interface

1. À gauche, le panneau des pages et des calques (Layers) permet de changer de page et de sélectionner ses éléments.
2. Au centre, le canvas est l’espace où vous dessinez vos écrans.
3. En bas, la barre d’outils permet de créer des frames, des formes et du texte.
4. À droite, le panneau affiche les réglages de l’élément sélectionné : dimensions, disposition et couleurs.
5. En haut à droite, Share permet de partager le fichier. Le bouton de présentation, en forme de triangle, lance le prototype.

La barre d’outils

Survolez un outil pour afficher son nom et son raccourci. À droite de la barre, gardez le mode Design sélectionné.

Pour trouver une commande, un plugin ou un composant, ouvrez le menu Actions avec Ctrl + K, ou Cmd + K sur Mac, et tapez ce que vous cherchez : “auto layout”, “Contrast”…

Les pages et les frames

Une frame est un cadre qui contient des éléments. Elle peut représenter un écran entier, mais aussi un bouton ou une carte. Avec l’outil Frame (F), choisissez un format dans le panneau de droite. Le préréglage iPhone 14 fait 390 × 844 px. Nommez cette frame “Fiche atelier”.

Une page regroupe plusieurs frames. Le fichier de la capture utilise ses trois pages disponibles pour les composants, les wireframes et la maquette. Une section (Maj + S) permet de regrouper les écrans d’une même étape au sein d’une page.

Chaque élément a son calque dans le panneau de gauche. Nommez-le “Bouton réserver” plutôt que “Rectangle 12”.

La grille

Une grille de colonnes donne des repères pour aligner les éléments. Pour l’exercice sur téléphone, partez de 4 colonnes, avec 24 px de marge de chaque côté et 16 px de gouttière (gutter) entre les colonnes. Alignez les textes et les boutons à l’intérieur de ces marges. Ajoutez la grille depuis le panneau de droite de la frame, puis enregistrez-la comme style pour la réutiliser sur les autres écrans.

L’auto layout

Si vous posez un texte sur un rectangle, allonger le libellé ne redimensionne pas le fond du bouton. L’auto layout (Maj + A) organise les éléments dans une frame. Avec une largeur réglée sur Hug, cette frame s’adapte au texte et conserve l’espace prévu autour.

Les réglages sont dans la section Layout du panneau de droite.

1. Le bouton en haut de Layout ajoute l’auto layout, comme le raccourci Maj + A.
2. Flow règle la disposition : en colonne, en ligne ou en grille. Le premier choix revient au placement libre, sans auto layout.
3. Les menus W (largeur) et H (hauteur) règlent les dimensions. Les options Fixed, Hug et Fill sont expliquées ci-dessous.
4. Ce bouton crée un composant réutilisable. Son raccourci est Ctrl + Alt + K, ou Cmd + Option + K sur Mac.

Une fois l’auto layout ajouté, de nouveaux champs apparaissent : l’espacement entre les éléments (gap), le padding (l’espace intérieur) et l’alignement.

Fixed, Hug, Fill

La largeur et la hauteur se règlent séparément. Les options disponibles dépendent de l’élément sélectionné et de la frame qui le contient.

Des espacements réguliers

Utilisez quelques valeurs d’espacement et répétez-les sur les écrans. Pour commencer : 8 px entre un libellé et son champ, 16 px entre deux champs, 24 px autour du contenu d’une carte et 32 px entre deux sections.

Pour ce bouton, essayez 12 px de padding en haut et en bas, et 24 px sur les côtés. Visez une hauteur d’au moins 44 px pour offrir une zone facile à toucher, puis vérifiez le résultat à la taille d’un téléphone.

Les frames en auto layout peuvent s’emboîter, comme les div en HTML : une frame pour le bouton, une autre pour la ligne de boutons, puis une pour la section qui les contient.

Le défi de l’auto layout

Combien d’auto layouts contient cet écran ? 1, 7, 10 ou 23 ?

Voir la réponse

Cette version en contient 23. Les pointillés montrent les frames et leur emboîtement dans les différentes parties de l’écran :

1. L’en-tête : le retour, la recherche et le panier.
2. La photo, puis le nom et le prix.
3. Chaque taille, chaque ligne de tailles, la grille.
4. La barre du bas : le favori et le panier.
5. L’écran entier, qui contient tout le reste.

Pour construire le vôtre, réglez d’abord un bouton. Placez-le ensuite dans une carte, puis la carte dans l’écran.

Les raccourcis

Ateliers : dessiner les écrans de la MJC

Travaillez dans votre fichier Figma ou Penpot. Si vous reprenez des documents UX réalisés en groupe, copiez-les et indiquez leur origine. Concevez vos propres écrans. Un camarade peut les tester.

Le zoning

Dessinez les grandes zones de la fiche atelier. Placez en premier ce dont votre persona a besoin pour décider de réserver. Des rectangles avec un nom suffisent.

Essayez deux ordres différents pour la description et les informations pratiques. Choisissez-en un en vous appuyant sur un besoin de votre persona, puis notez la raison en une phrase.

Prendre en main Figma

1. Ouvrez votre fichier de projet dans Figma. Si vous n’en avez pas, créez un fichier de design nommé “MJC des Tilleuls, votre prénom”.
2. Avec l’outil Frame (F), créez un écran au format téléphone. Nommez-le “Fiche atelier”.
3. Avec Rectangle (R) et Texte (T), reproduisez les zones de votre zoning. Ajoutez le nom de l’atelier, une description et le texte “Réserver une séance d’essai”.
4. Sélectionnez le texte du bouton et appliquez l’auto layout (Maj + A). Réglez la largeur sur Hug. Ajoutez un fond gris et du padding autour du texte.
5. Changez le libellé du bouton : sa frame doit s’adapter au texte. Renommez vos éléments dans le panneau des calques pour les retrouver.

Rendu : une fiche atelier en gris, avec un bouton qui s’adapte à son libellé. Utilisez ce fichier pour les wireframes.

Les wireframes

Dessinez trois écrans en gris, avec les vrais titres, libellés et boutons :

Ajoutez les états du parcours :

• Une confirmation avec l’atelier, la date, l’heure, le lieu et le matériel à prévoir.
• Une erreur de saisie qui indique quel champ corriger et comment.
• Une séance complète avec accès à la liste d’attente.
• Un message qui demande aux moins de 18 ans d’apporter une autorisation parentale.

Vérifiez qu’on peut suivre le parcours depuis la liste des ateliers jusqu’au résultat de la réservation.

Demandez à une autre personne de trouver un atelier adapté à son âge, de choisir une séance et d’indiquer ce qu’elle doit apporter. Laissez-la chercher sans la guider. Elle peut pointer les actions pendant que vous lui montrez l’écran suivant.

Avant de rendre, vérifiez que :

• Le prix de la séance d’essai, les âges acceptés et le matériel sont indiqués.
• Chaque champ a un libellé et l’erreur explique comment corriger la saisie.
• La réservation confirmée et l’inscription sur liste d’attente donnent des messages distincts.
• Le cas d’une personne mineure autorise la réservation et rappelle l’autorisation à apporter.

Corrigez une hésitation observée et gardez une courte note de ce que vous avez changé.

Rendu : le zoning et les trois écrans avec leurs états, dans votre fichier de projet. Ils serviront de base à la maquette UI.

À lire

• Quelle est la différence entre le zoning, wireframe, mockup et prototype ?, Blog UX, pour comparer les quatre livrables.
• UX Prototypes: Low Fidelity vs. High Fidelity, Nielsen Norman Group, sur les niveaux de fidélité et les tests sur papier ou écran. En anglais.
• Un wireframe, c’est quoi ?, blog-ux.
• Maquettage UX Design : wireframe, maquette ou prototype ?, Arquen.
• Appliquez les bonnes pratiques de prototypage, OpenClassrooms.
• Guide de l’auto layout, aide de Figma.
• What is a wireframe and how to make one, Penpot, l’équivalent libre de Figma. En anglais.

Pour la discussion

• Qu’est-ce qui a changé entre votre zoning et vos wireframes ?
• Que peut-on apprendre en faisant essayer un prototype en gris ? Que reste-t-il à vérifier sur le site codé ?

User flow, séquence et UML

Le journey raconte ce que vit une personne. Pour concevoir puis coder, il faut aussi décrire ce qui se passe dans le produit : les écrans, les choix, les échanges avec le serveur. Designers et développeurs utilisent ces schémas pour se mettre d’accord avant de coder.

Quel schéma pour quelle question

Le user flow

Un user flow représente les actions et les écrans nécessaires pour accomplir une tâche dans le produit. Il montre aussi les choix, les erreurs et les réponses de l’interface. Les pensées et les émotions figurent dans la journey map.

Nielsen Norman Group compare le journey et le user flow :

Un user flow détaille une étape du parcours utilisateur. Celui-ci détaille l’étape “Commander” du journey d’Inès.

Les rectangles sont des écrans. Les losanges sont des questions qui ont plusieurs réponses. Les flèches portent l’action de l’utilisateur.

flowchart TD
    accTitle: Le user flow d'une commande au snack
    accDescr: Inès ouvre le menu, ajoute un plat au panier, se connecte si besoin, puis paie. Si le paiement est accepté, elle voit la confirmation. Sinon, elle revient au paiement.
    A([Ouvre l'appli]) --> B[Menu]
    B -->|Choisit un plat| C[Fiche du plat]
    C -->|Ajoute au panier| D[Panier]
    D --> E{Connectée ?}
    E -->|Non| F[Connexion]
    F --> G[Paiement]
    E -->|Oui| G
    G --> H{Paiement accepté ?}
    H -->|Oui| I[Confirmation avec un numéro]
    H -->|Non| J[Message d'erreur]
    J -->|Réessaie| G

Chaque branche du flow doit apparaître dans les wireframes. Ici, il faut prévoir la connexion et le message d’erreur, en plus du parcours sans problème (happy path).

Nielsen Norman Group dessine aussi le user flow en wireflow : les wireframes des écrans, posés en ligne et reliés par des flèches. Chaque flèche part de l’élément sur lequel l’utilisateur clique ou appuie. Dans Figma, reliez vos wireframes avec l’outil flèche (Maj + L).

Le diagramme de séquence

Un diagramme de séquence montre les échanges entre plusieurs acteurs, dans l’ordre du temps. Le temps s’écoule de haut en bas.

• Chaque acteur a une ligne verticale, sa ligne de vie. Un acteur peut être une personne ou un système : l’appli, le serveur, la base de données.
• Chaque flèche est un message. Une flèche pleine envoie une demande. Une flèche en pointillés porte la réponse.
• Un bloc alt montre deux cas possibles, un seul se produit. Un bloc loop montre une action répétée. Un bloc opt montre une étape facultative.

%%{init: {"sequence": {"actorMargin": 24, "width": 110}}}%%
sequenceDiagram
    accTitle: Une commande au snack, vue par le système
    accDescr: Inès paie dans l'appli. L'appli envoie la commande au serveur. Si le paiement est accepté, le serveur enregistre la commande et l'appli affiche la confirmation. Sinon, l'appli affiche une erreur.
    actor I as Inès
    participant A as Appli
    participant S as Serveur
    I->>A: Appuie sur "Payer"
    A->>S: Envoie la commande
    alt Paiement accepté
        S->>S: Enregistre la commande
        S-->>A: Numéro de commande
        A-->>I: Écran de confirmation
    else Paiement refusé
        S-->>A: Erreur
        A-->>I: Message d'erreur
    end

Un développeur y lit ce qu’il doit coder : la demande envoyée au serveur, les deux réponses possibles, et l’erreur à afficher.

Ce schéma est écrit en texte, avec Mermaid. Voici le début du texte qui le produit :

sequenceDiagram
    actor I as Inès
    participant A as Appli
    I->>A: Appuie sur "Payer"

GitHub affiche les schémas Mermaid dans un README ou une issue. Vous pouvez donc garder vos schémas à côté de votre code.

UML

UML, pour Unified Modeling Language, est un langage standard de schémas pour décrire un logiciel. Il compte 14 types de diagrammes, rangés en deux familles.

• Les diagrammes de structure montrent de quoi le système est fait : ses classes, ses composants, ses serveurs.
• Les diagrammes de comportement montrent ce que fait le système, et comment il change dans le temps.

Quatre diagrammes de comportement servent souvent en UX :

Voici les états d’une commande au snack :

stateDiagram-v2
    accTitle: Les états d'une commande au snack
    accDescr: Une commande est reçue, puis en préparation, puis prête, puis récupérée. Une commande reçue peut encore être annulée.
    state "Reçue" as Recue
    state "En préparation" as Prep
    state "Prête" as Prete
    state "Récupérée" as Recuperee
    state "Annulée" as Annulee
    [*] --> Recue
    Recue --> Prep : la cuisine commence
    Recue --> Annulee : Inès annule
    Prep --> Prete : le plat est emballé
    Prete --> Recuperee : Inès montre son numéro
    Recuperee --> [*]
    Annulee --> [*]

Certains états donnent lieu à un message, comme “Ta commande est prête”. Le système garde aussi une trace de l’état de la commande.

Atelier : le schéma d’enchaînement

Le titre DWWM demande un schéma d’enchaînement des maquettes. C’est le user flow de votre réservation : ses étapes et ses choix possibles. Il fait partie du rendu individuel, avec la maquette. Le sitemap décrit, lui, l’organisation des pages du site.

Dans Figma, reliez des copies réduites de vos écrans ou des rectangles nommés. Indiquez l’action sur chaque flèche. Montrez au moins :

• Le choix d’un atelier, puis d’une séance disponible.
• Le formulaire, la correction d’une saisie et la confirmation.
• Une séance complète, puis l’inscription sur liste d’attente avec un résultat distinct.

Le message d’autorisation parentale apparaît dans le parcours d’une personne mineure. Il ne bloque pas sa réservation. Nommez les écrans et les états comme dans votre maquette.

Placez le schéma dans “8. UI et maquette”, à côté du prototype. Vous pouvez aussi le dessiner sur papier et le photographier, ou utiliser draw.io. Vérifiez le schéma, puis les connexions de l’onglet Prototype : les flèches dessinées ne rendent pas les écrans cliquables.

Les diagrammes de séquence et d’états sont facultatifs. Ils peuvent vous aider à préparer le code.

À lire

• User Journeys vs. User Flows, Nielsen Norman Group : les définitions, le tableau comparatif et l’exemple d’un patient qui cherche un médecin. En anglais.
• Wireflows, Nielsen Norman Group : dessiner un user flow avec des wireframes. En anglais.
• What is a sequence diagram?, Figma : les éléments, les blocs alt, loop et opt, et des exemples de connexion et de commande. En anglais.
• What is a UML diagram?, Figma : les 14 types de diagrammes UML. En anglais.
• Création de diagrammes, documentation de GitHub, pour écrire des schémas Mermaid dans un dépôt.

Pour la discussion

• Quel schéma vous aiderait à dessiner vos wireframes ?
• Quel schéma un développeur back-end voudrait-il recevoir ?

La hiérarchie visuelle

L’UI design définit l’apparence d’une interface : ses boutons, ses champs et leurs états, comme une erreur ou une sélection. La taille, le contraste, la position et l’espacement guident la lecture. Sur la fiche d’un atelier, le bouton “Réserver” doit se distinguer des liens secondaires.

Pour l’atelier, vérifiez l’ordre de lecture, l’association entre les champs et leurs libellés, et les contrastes. Les états doivent rester compréhensibles sans la couleur. Les exemples de composition permettent d’aller plus loin.

Du wireframe au design

La maquette reprend les contenus et l’ordre des wireframes. Elle précise la typographie, les couleurs, les espacements et les états des éléments interactifs.

Dans l’appli du snack, Inès cherche un repas à moins de 7 €. Les choix visuels doivent lui permettre de comparer les menus et de comprendre si sa commande est partie.

Une couleur seule ne suffit pas à expliquer un état. Écrivez “Indisponible” ou “Commande confirmée” et gardez le texte lisible sur son fond.

Où regarder en premier

La hiérarchie visuelle indique quoi lire en premier. Le titre identifie la page. Les autres styles distinguent la description, les informations pratiques et les actions.

Dans une étude publiée en 2006, Gitte Lindgaard et son équipe ont recueilli des jugements sur l’attrait visuel de pages web après 50 millisecondes d’affichage. Cette première impression porte sur l’apparence de la page. Elle ne dit pas si la personne saura y réserver une séance.

Si le titre, la description et les mentions secondaires ont le même traitement, leur ordre d’importance est difficile à repérer.

Dans un article de blog, on peut distinguer quatre niveaux :

1. Le titre annonce le sujet dans la plus grande taille.
2. Le chapeau présente le contenu avec une taille intermédiaire.
3. Le texte courant développe le sujet dans une taille adaptée à la lecture de paragraphes.
4. Les notes apportent des précisions dans une taille plus petite, qui doit rester lisible.

Les quatre leviers

La taille

Agrandir un élément le rend plus visible par rapport à ses voisins. Les journaux le font avec leurs titres. Dans cette comparaison, la baleine agrandie occupe presque toute l’image, alors qu’elle se distinguait peu du décor dans la première version.

Prévoyez deux ou trois tailles nettement différentes. Un titre à 24 px et un sous-titre à 22 px ont des tailles proches. Essayez 32 px et 18 px, puis vérifiez si les niveaux se distinguent avec votre police. La page La typographie et les couleurs explique comment calculer ces tailles.

Le contraste

Le contraste joue sur les différences :

• De couleur : une couleur vive au milieu de tons neutres.
• De valeur : un élément foncé sur un fond clair, ou l’inverse.
• De saturation : une couleur éclatante parmi des couleurs ternes.

Sur cette affiche de théâtre, le mot blanc occupe presque toute la largeur du fond rouge. Sa taille et sa couleur le font ressortir.

Un élément qui sort de la série attire aussi l’œil, comme une silhouette claire au milieu de silhouettes foncées. Les lois de l’UX appellent cela l’effet Von Restorff.

Réservez la couleur d’accent à l’action principale et aux messages importants. Si tous les éléments l’utilisent, elle ne permet plus de les distinguer.

La position

La partie visible sans défiler, au-dessus de la ligne de flottaison (above the fold), doit permettre de comprendre sur quelle page on se trouve. Placez ensuite les informations dans l’ordre où la personne en a besoin. Sur une fiche atelier, elle doit pouvoir lire les horaires avant de choisir un créneau.

En français, le sens de lecture va de gauche à droite. Le regard dépend aussi de la tâche, du contenu et de sa mise en page. Les parcours en F et en Z (F-pattern, Z-pattern) donnent des repères, sans imposer un trajet à chaque personne.

Une information nécessaire pour choisir un atelier, comme l’âge minimum, doit rester près de sa description. La placer uniquement dans le pied de page oblige la personne à la chercher ailleurs.

L’espacement

Placez chaque libellé plus près de son champ que du champ voisin. La personne comprend alors à quelle saisie il correspond. C’est la loi de proximité de la Gestalt.

L’espace vide, ou white space, aide à isoler un élément. Un bouton séparé du paragraphe voisin est plus facile à repérer comme une action distincte.

Ces deux versions d’un formulaire de paiement contiennent les mêmes champs. La première aligne tous les champs en trois colonnes serrées. La seconde les regroupe par sujet, avec le titre de chaque groupe à gauche et une ligne de séparation entre les groupes. Les coordonnées et les informations de paiement forment ainsi des blocs distincts.

Gardez moins d’espace entre un libellé et son champ qu’entre deux champs. Séparez davantage les sections du formulaire.

Vérifier la hiérarchie

Plissez les yeux devant votre écran (le squint test), ou floutez une capture, pour repérer les éléments qui dominent la page. Si une décoration ressort davantage que le titre ou l’action principale, revoyez sa taille, son contraste ou sa place. Vérifiez ensuite la lisibilité des textes sans le flou.

Essayez sur ces trois pages. Pour chacune, qu’est-ce que vous voyez en premier ? Quel levier produit cet effet ?

Le contraste et la lisibilité

Un texte doit rester lisible sur son fond. Le contraste se mesure par un rapport entre la couleur du texte et celle du fond, de 1:1 (aucune différence) à 21:1 (noir sur blanc).

Le RGAA, le référentiel d’accessibilité utilisé en France, fixe des seuils :

Quelques mesures sur fond blanc :

Dans cet exemple, un texte rose sur un fond rose pâle obtient 1,49:1. Ce rapport est insuffisant pour le texte courant comme pour le grand texte.

Mesurez vos couleurs avec un plugin de contraste dans Figma ou avec le Contrast Checker de WebAIM. Vérifiez aussi ces critères sur la page codée.

À lire

• Attention web designers: You have 50 milliseconds to make a good first impression!, Gitte Lindgaard et son équipe, 2006. L’étude sur les premières impressions visuelles. PDF en anglais.
• Visual Hierarchy in UX: Definition, Nielsen Norman Group, sur la taille, la couleur, le contraste et l’espacement. En anglais.
• F-Shaped Pattern of Reading on the Web, Nielsen Norman Group, sur le parcours en F. En anglais.
• Effet Von Restorff, Laws of UX.
• Critère 3.2 du RGAA, sur le contraste du texte.

Pour la discussion

• Sur votre wireframe de la fiche atelier, qu’est-ce que votre persona doit voir en premier ?
• Quel élément attire l’œil alors qu’il n’est pas important ?
• Une interface très contrastée partout est-elle plus lisible ?

La typographie et les couleurs

Les polices et les couleurs aident à distinguer les titres, les contenus et les actions. Elles donnent aussi un ton à l’interface. Pour la MJC, testez vos choix sur le nom d’un atelier, sa description et le bouton de réservation.

Pour l’atelier, utilisez la police de la charte et les quatre styles ci-dessous. Les familles de polices, les harmonies et le moodboard restent des ressources complémentaires.

Les familles de polices

Ces catégories ne suffisent pas à choisir une police. Une display peut devenir difficile à lire en petit. Pour les paragraphes, testez un texte complet à la taille prévue, avec des caractères accentués.

Associer deux polices

Une seule police suffit souvent, avec plusieurs graisses. Si vous en prenez deux, cherchez un contraste net : une serif ou une display pour les titres, une sans-serif neutre pour le texte.

Testez-les avec du vrai texte. “Menu étudiant à 6,50 €” en titre, suivi d’une phrase de description, en dit plus qu’un mot “Typography” écrit en 60 px.

Ces deux sites montrent l’effet d’un choix de police. Le Dansk Byplanlaboratorium utilise une seule sans-serif, en plusieurs tailles. Daisy associe des titres en serif à un texte en chasse fixe, ce qui distingue les titres des autres textes.

L’échelle typographique

Une échelle typographique, ou type scale, définit les tailles de texte de l’interface. Pour construire une échelle modulaire, on part d’une taille de base et on la multiplie par un même ratio à chaque niveau.

Avec une base de 16 px et un ratio de 1,25, on obtient 16, 20, 25, 31,25 et 39,06 px. Arrondissez et ajustez ces tailles selon la charte, puis testez leur lisibilité avec votre police et vos vrais textes.

Le site Typescale permet de comparer ces échelles. Aucun plugin n’est nécessaire pour l’exercice.

À titre d’exemple, l’échelle de Material Design 3 nomme les styles par rôle (Display, Headline, Title, Label, Body) et propose trois tailles pour chacun (L, M, S), en version standard (baseline) et accentuée (emphasized).

Quatre styles pour la MJC

Utilisez cette proposition si votre projet n’a pas encore de styles validés. Elle reprend quelques tailles de l’échelle, avec Arial normal ou gras.

Dans le code, choisissez les balises h1, h2 et suivantes selon le niveau du titre dans le document, puis appliquez le style. La taille du texte ne détermine pas la balise.

Dans Figma, enregistrez chaque style dans Typography et appliquez-le à plusieurs textes. Changez temporairement sa taille : tous les textes liés doivent suivre. Testez les accents et le libellé “Réserver une séance d’essai” sur un écran étroit. Sur le site codé, vérifiez aussi le zoom et le redimensionnement du texte.

Un texte courant lisible

• Partez de 16 px pour le texte courant, puis vérifiez la lisibilité avec votre police.
• Essayez un interligne de 1,5 fois la taille du texte, soit 24 px pour un texte de 16 px.
• Visez 45 à 75 caractères par ligne lorsque la largeur de l’écran le permet. Des lignes trop longues rendent le retour à la ligne suivante plus difficile.
• Mesurez le contraste avec le fond en vous appuyant sur les seuils de contraste.

Comparez ces deux versions du même texte. La seconde augmente l’interligne, raccourcit les lignes et sépare les paragraphes.

Où trouver des polices

Vérifiez que la licence autorise l’usage prévu sur le web : certaines polices gratuites sont réservées à un usage personnel. Utilisez la même police dans la maquette et dans la page codée.

La roue chromatique

La roue chromatique range les couleurs en cercle. Dans le modèle illustré ici, les trois primaires sont le rouge, le jaune et le bleu. Les secondaires, orange, vert et violet, se placent entre elles. Les tertiaires, comme le bleu-vert, complètent le cercle.

Les harmonies sont des façons de combiner des couleurs d’après leur place sur la roue.

Ces six pages, tirées de Designspiration, montrent chacune une palette réduite : une ou deux couleurs dominantes et un accent.

Avec deux couleurs complémentaires, utilisez l’une sur les grandes surfaces et l’autre en accent. Leur opposition sur la roue ne garantit pas la lisibilité du texte. Mesurez le contraste de chaque paire texte/fond avec les couleurs exactes de votre maquette.

Des couleurs qui ont un rôle

Pour les couleurs de l’interface, choisissez des noms qui décrivent leur rôle. color.action.primary désigne l’action principale, que le bouton soit orange ou bleu.

Le rouge pour l’erreur et le vert pour la confirmation sont des conventions. Accompagnez-les d’un message explicite, pour que l’état reste compréhensible si la personne distingue mal ces couleurs.

Pour extraire une palette d’une image, utilisez Adobe Color ou Coolors. Dans Figma, la pipette (raccourci I) prélève une couleur sur une image.

Le moodboard

Le moodboard, ou planche d’inspiration, rassemble des images, des couleurs et des polices pour choisir une direction visuelle avant de dessiner la maquette.

Pour la MJC, comparez par exemple une piste avec des photos d’activités et une autre avec des illustrations.

Ce qu’on y met :

• Des photos ou des illustrations d’ambiance.
• Des captures de sites ou d’applis au style proche de ce que vous visez.
• Deux ou trois palettes de couleurs.
• Deux ou trois associations de polices.
• Des exemples de composants : boutons, cartes, navigation.
• Des textures, des motifs, des icônes.

Quelques styles visuels à reconnaître :

Dans cet exemple, le moodboard rassemble des photos, des palettes et des captures de sites dans Figma :

Où chercher : Pinterest, Dribbble, Awwwards, Designspiration et Mobbin pour les applis mobiles.

Le moodboard de votre atelier

Cet atelier est facultatif. Le moodboard aide à choisir un style visuel. Le référentiel DWWM RNCP37674 demande de respecter la charte graphique, sans citer le moodboard comme livrable exigé. Référentiel officiel, compétence 2.

Rassemblez 6 à 8 images qui évoquent l’ambiance de votre atelier de la MJC, sur une page “Moodboard” de votre fichier. Tirez-en 3 à 5 couleurs. Testez la police de votre charte avec le nom de votre atelier.

Rendu : le moodboard dans votre fichier de projet. Indiquez ce que vous retenez des références pour choisir les styles : une couleur, un traitement des photos ou une association de polices.

À lire

• Google Fonts Knowledge, des articles courts sur le choix et l’usage des polices. En anglais.
• Typescale, pour calculer et essayer une échelle typographique.
• Adobe Color, une roue chromatique qui construit les harmonies et vérifie le contraste.

Pour la discussion

• Quelle ambiance correspond à votre atelier ? Quelles images la montrent ?
• Votre couleur d’action se voit-elle sans être partout ?
• Votre police reste-t-elle lisible en petit, sur un téléphone ?

Style guide, tokens et composants

Dans Figma, vous allez définir les couleurs, les styles de texte et les espacements du projet, puis créer des boutons et des champs réutilisables. Vous pourrez ainsi les modifier sur plusieurs écrans à la fois.

Le style guide

Le style guide documente les règles visuelles de l’interface : polices, couleurs, espacements et exemples d’utilisation. Il traduit la charte graphique du projet pour les écrans.

Ces règles donnent les mêmes repères d’un écran à l’autre : présentation des boutons, libellés et erreurs. Le focus indique quel élément reçoit les actions du clavier. Vérifiez que vos choix permettent d’accomplir les tâches des user stories et respectent le brief.

Un token peut se retrouver dans une variable Figma et une variable CSS. Les variables peuvent aussi contenir d’autres valeurs, comme les données fictives d’un prototype.

Les design tokens

Un design token est une valeur de design associée à un nom : couleur, espacement ou taille de texte. Par exemple, color.action.primary nomme la couleur de l’action principale. Le nom reste le même quand vous changez la couleur.

Ces valeurs et les quatre styles de texte forment la mini-charte de l’exercice. Si vous avez déjà une charte, conservez-la et vérifiez ses contrastes.

Token primitif, token sémantique et alias

Un token primitif nomme une valeur, par exemple color.orange.700 = #c2410c. Un token sémantique nomme son usage, par exemple color.action.primary. Un alias fait référence à un autre token au lieu de recopier sa valeur.

color.orange.700 = #c2410c
color.action.primary = référence à color.orange.700
color.banner.background = référence à color.orange.700

Si les boutons doivent devenir bleus et la bannière rester orange, changez seulement la référence de color.action.primary. Deux rôles peuvent partager une couleur aujourd’hui et évoluer séparément demain.

Pour cet exercice, donnez directement une valeur à chaque token de rôle. Les alias et les modes clair ou sombre sont facultatifs.

Les variables et les styles dans Figma

Une variable contient une valeur d’un type donné, par exemple une couleur ou un nombre. Un style de texte rassemble plusieurs réglages : police, taille, graisse et interligne. Un style peut lui-même utiliser des variables. L’aide de Figma détaille cette distinction.

Créer et appliquer les variables

1. Ouvrez Variables dans la navigation de gauche. Dans une ancienne interface, désélectionnez les éléments et cherchez Local variables dans le panneau de droite.
2. Créez une collection nommée MJC. Ajoutez les couleurs avec le type Color et les espacements avec le type Number.
3. Dans Figma, utilisez / pour regrouper les noms : color/action/primary, space/m. La notation avec des points dans ce cours désigne le même choix.
4. Sélectionnez le fond du bouton. Dans Fill, ouvrez le sélecteur des styles et variables et choisissez color/action/primary.
5. Dans le padding (espace intérieur) ou le gap (espace entre les éléments) d’un auto layout, utilisez Apply variable pour choisir space/m. Selon le champ, l’option apparaît au survol ou dans son menu contextuel.

Modifier la valeur d’une variable met à jour les propriétés qui lui sont liées. Taper la même couleur hexadécimale à deux endroits ne crée aucun lien. Créer des variables et les appliquer, aide officielle de Figma.

Enregistrer les styles de texte

Sélectionnez un texte, réglez sa police, sa taille, sa graisse et son interligne. Ouvrez le sélecteur de styles de Typography, puis créez un style. Nommez les styles text/page-title, text/section-title, text/body et text/label. Appliquez-les aux textes de votre écran.

Pourquoi réutiliser les styles

Si les libellés de dix champs sont réglés séparément, corriger leur interligne demande dix modifications et peut laisser des écarts entre les écrans. Un style partagé permet de corriger ce réglage pour les textes qui lui restent liés. Les variables jouent le même rôle pour leurs valeurs, comme une couleur ou un espacement.

Un style partagé reproduit aussi ses défauts, comme un contraste insuffisant. Testez-le sur la fiche, le formulaire et la confirmation, puis reportez les corrections dans le code.

Vérifier que le lien fonctionne

Appliquez la variable d’action à deux boutons. Changez-la temporairement de #c2410c à #1d4ed8 : les deux fonds doivent devenir bleus. Un élément qui reste orange utilise peut-être une valeur saisie directement. Retrouvez la propriété concernée, puis rétablissez la valeur prévue par la charte.

Faites le même essai avec space/m, de 16 à 20, puis revenez à 16. Le padding lié doit suivre.

Du style guide au CSS

Dans cet exercice, nous nommons les propriétés personnalisées CSS (souvent appelées variables CSS) en remplaçant les points ou les / par des tirets, avec -- au début.

:root {
  --color-action-primary: #c2410c;
  --color-text-on-action: #ffffff;
  --space-s: 0.5rem;
  --space-m: 1rem;
}

.bouton {
  padding: var(--space-s) var(--space-m);
  color: var(--color-text-on-action);
  background: var(--color-action-primary);
}

Avec une taille racine de 16 px, 0.5rem correspond à 8 px et 1rem à 16 px. Conservez les unités dans la documentation.

Reportez les valeurs de Figma dans le CSS. Leur synchronisation nécessite un outil configuré pour le projet.

Choisir les styles

Travail individuel, après la démonstration.

1. Reprenez la mini-charte fournie, ou votre charte déjà validée. Créez les quatre styles de texte et les variables de couleur et d’espacement.
2. Appliquez-les à une carte d’atelier et à un bouton. Utilisez le vrai nom de l’atelier.
3. Mesurez le contraste du texte sur le fond et du texte sur le bouton. Notez les deux couples de couleurs et leurs rapports.
4. Faites l’essai de modification d’une couleur et d’un espacement sur deux éléments liés, puis rétablissez la charte.

Rendu : votre planche de styles, les variables et une carte qui les utilise, dans la section “8. UI et maquette” de votre fichier personnel.

Les composants

Un composant Figma est un modèle réutilisable. Les exemplaires placés sur les écrans sont ses instances, qui conservent un lien avec le composant principal (main component).

“Réserver” et “Rejoindre la liste d’attente” peuvent utiliser le même composant avec des libellés différents. La logique métier décide quelle action déclencher. Créer un composant Figma ne génère pas cette logique.

Propriétés, variantes et surcharges

Une propriété texte modifie un contenu. Une variante décrit une version prévue du composant, comme l’état désactivé. Une surcharge, ou override, remplace localement une propriété d’une instance.

Une instance dont vous changez le libellé continue de suivre les couleurs du composant principal. Si vous changez aussi sa couleur, elle garde cette valeur locale. Réinitialisez cette propriété pour reprendre la couleur du composant principal.

Évitez de détacher une instance pour changer son texte : elle perdrait alors son lien avec le composant principal.

Créer un composant dans Figma

1. Dessinez un bouton avec un libellé et ajoutez l’auto layout avec Maj + A. Réglez la largeur sur Hug, le padding avec vos variables et le texte avec votre style de libellé.
2. Créez le composant avec Ctrl + Alt + K, ou Cmd + Option + K sur Mac.
3. Dans les propriétés du composant, exposez le libellé comme propriété texte si possible. Vous pouvez aussi modifier le texte à l’intérieur de l’instance.
4. Ajoutez les variantes et nommez leur propriété État : normal, focus, désactivé.
5. Placez deux instances depuis Assets, avec des libellés différents. Modifiez le composant principal et observez les changements sur les deux instances.

Un bouton en Hug s’adapte à son contenu. Fill lui fait occuper la largeur disponible dans son parent en auto layout.

Les états à prévoir

Créer les composants

Démonstration, puis travail individuel.

Créez un bouton et un champ réutilisables, puis placez des instances avec des contenus différents. Préparez les états normal, focus et désactivé du bouton. Si ces éléments fonctionnent, transformez aussi votre carte d’atelier en composant.

Modifiez le padding du composant principal : les deux instances doivent suivre. Vérifiez ensuite qu’un libellé long tient sur un écran étroit.

Le design system

Un design system rassemble les styles visuels, les composants réutilisables et leurs règles d’usage. Il peut inclure une bibliothèque Figma, du code, des exemples et des consignes d’accessibilité.

Avant de créer un élément, vérifiez s’il existe déjà dans le projet. Consultez ses usages, ses états et ses limites, puis réutilisez-le s’il convient.

Le DSFR, système de design de l’État, est un exemple à consulter : il propose du code et une documentation pour l’utiliser et y contribuer. Sa réutilisation dépend de ses conditions d’usage.

Dans cet atelier, vous créez une petite bibliothèque documentée. Pour l’utiliser comme design system sur plusieurs projets, il faudrait aussi du code, des tests et une personne chargée de gérer les changements et de publier les versions.

L’atomic design, pour approfondir

Brad Frost propose de décomposer une interface en atomes, molécules, organismes, templates et pages. Pour cet atelier, aucun classement à mémoriser : expliquez simplement quels éléments vous réutilisez et ce qui change d’un usage à l’autre.

Vérifier votre compréhension

1. Vous changez color/action/primary, mais un bouton garde son ancienne couleur. Quelle propriété vérifiez-vous ?
2. Deux boutons ont des libellés différents. Faut-il deux composants principaux ?
3. Le fichier Figma contient des couleurs et des boutons. Que manque-t-il pour guider leur utilisation dans une application ?

À lire

• Guide des composants dans Figma.
• Design tokens, Figma, en anglais.
• Atomic Design Methodology, Brad Frost, en anglais.

La maquette et le test

Transformez vos wireframes en maquettes, puis reliez les écrans pour créer un prototype. Faites tester la réservation et corrigez les difficultés observées. Chaque personne conçoit, corrige et rend son propre fichier.

De la maquette au prototype

La maquette, ou mockup, ajoute aux wireframes les styles et les composants choisis. Ajustez la mise en page si un titre déborde ou si une information passe inaperçue.

Le prototype relie les écrans pour essayer le parcours : choisir une séance, remplir le formulaire et voir la confirmation. Il peut utiliser des wireframes en gris ou, comme ici, des maquettes avec leurs styles.

Précisez à la personne qui teste que la réservation est simulée : aucune place n’est enregistrée et aucun e-mail n’est envoyé.

Pour relier les écrans dans Figma :

1. Ouvrez l’onglet Prototype, dans le panneau de droite.
2. Sélectionnez le bouton, puis tirez la flèche vers l’écran qui doit s’afficher.
3. Gardez le déclencheur “On click” et l’action “Navigate to”.
4. Lancez le prototype avec le bouton de présentation, en haut à droite.

Penpot a un mode Prototype qui fonctionne de la même façon.

Une page en mobile et en desktop

Créez le parcours mobile dans une frame de 390 px de large. Adaptez ensuite la fiche atelier à une frame de 1280 px pour l’ordinateur. Si vous avez le temps, essayez-la aussi à 320 px. Ces largeurs servent à tester la mise en page. Dans le code, les breakpoints sont les largeurs auxquelles la disposition change. Choisissez-les selon l’espace nécessaire au contenu.

Vérifiez les titres longs, les boutons, les messages d’erreur et l’ordre des informations. Sur grand écran, limitez la largeur du texte. Sur petit écran, empilez les éléments et laissez le texte passer à la ligne.

Notez deux règles pour le code, par exemple : “les cartes passent en une colonne quand elles ne tiennent plus” et “le bouton occupe la largeur disponible sur téléphone”. Adaptez la disposition au lieu de réduire une capture. Vous vérifierez ces règles dans le navigateur une fois la page codée.

Les informations utiles pour coder

Près de votre maquette, indiquez :

• Les styles, les tokens et les composants utilisés.
• Ce qui varie dans chaque composant : texte, disponibilité, sélection, erreur.
• Les réactions attendues au clavier et les messages à annoncer.
• Le schéma d’enchaînement et les règles d’adaptation aux largeurs.

Décrivez aussi un composant en deux phrases simples en anglais. Exemple : “The button label describes the action. Keyboard focus is shown with a visible outline.” Vous vous entraînez ainsi à expliquer votre travail en anglais.

Données, sécurité et éco-conception

Utilisez des données fictives et les champs du brief. Justifiez tout champ ajouté. Prévoyez près du formulaire une explication sur l’usage des données et un lien vers les informations de confidentialité. Pour un vrai service, il faut préciser qui est responsable, pourquoi les données sont collectées, sur quelle base légale, combien de temps elles sont conservées et comment exercer ses droits. N’inventez pas ces informations pour la MJC fictive. Informer les personnes, CNIL.

Notez les contrôles à faire côté serveur : saisies, âges autorisés et places disponibles. Les contrôles dans Figma ou le navigateur ne suffisent pas. Prévoyez des messages distincts pour une réservation confirmée, une demande en attente et un échec d’envoi.

Expliquez un choix d’éco-conception : utiliser une police système, réduire la taille des images ou éviter les vidéos automatiques pour limiter les téléchargements. Vous mesurerez le poids des pages et le nombre de requêtes sur le site codé. Référentiel général d’écoconception des services numériques.

Avant de faire tester

Comparez chaque règle du brief MJC avec un contenu ou un état de votre maquette. Cette vérification relie les critères d’acceptation des stories aux écrans à développer.

Le prototype simule ces résultats. Le code devra ensuite appliquer et tester les règles, notamment les âges autorisés et le nombre de places.

• Les écrans affichent les noms d’ateliers, les libellés et les messages prévus pour le site.
• Les cas d’erreur, de confirmation, de séance complète et d’accord parental ont chacun un écran ou un message.
• Le parcours permet de vérifier les critères de votre story de réservation.
• Le texte courant atteint le contraste minimal de 4,5:1.
• Un titre d’atelier long tient dans sa carte.

Assembler la maquette

Après la démonstration, travaillez dans votre fichier de projet.

1. Gardez une copie de vos trois wireframes en gris.
2. Choisissez les contenus à partir du brief et de la frame “1–2. Préparer la réservation”.
3. Appliquez vos styles et composants, puis reliez les écrans.
4. Vérifiez les points de la liste “Avant de faire tester”.

Rendez le prototype avec ses trois écrans, les états du brief et le schéma d’enchaînement. Joignez la fiche atelier en mobile et en desktop, les règles pour le code et une note sur les données et l’éco-conception.

Si vous manquez de temps, terminez d’abord la fiche dans les deux formats, le formulaire et la confirmation. La liste peut rester en wireframe. Dessinez les messages d’erreur et de liste d’attente. Signalez les interactions manquantes : elles restent à terminer et à tester.

Le test d’utilisabilité

Un test d’utilisabilité consiste à observer une personne qui essaie d’accomplir une tâche avec le prototype.

En cas de blocage, notez ce que la personne cherchait et ce que l’écran affichait. Cherchez ce qui peut être amélioré dans l’interface.

La consigne “Réserve une séance” permet de vérifier si la personne trouve comment faire. “Clique sur Réserver” lui indique déjà où agir.

Un seul essai peut révéler une difficulté, mais ne suffit pas à repérer tous les problèmes.

Tester l’inscription

Faites tester votre prototype par une personne qui n’a pas participé à sa conception. Donnez cette tâche, puis observez sans guider :

Tu veux essayer une activité à la MJC des Tilleuls. Choisis un atelier qui correspond à ton âge et à tes disponibilités, puis réserve une séance d’essai. À la fin, dis ce que tu as réservé et ce qu’il te reste à faire avant de venir.

Corrigez le principal problème, puis faites réessayer. Vérifiez aussi que les messages de séance complète et d’accord parental sont compréhensibles.

Notez dans votre rendu la tâche donnée, une action ou une hésitation observée, votre correction et le résultat du nouvel essai. Si vous n’avez pas pu refaire l’essai, indiquez “à retester” et le résultat attendu. Sans test, indiquez “non testé” et préparez la tâche à donner. N’inventez pas de retour utilisateur.

Ce test porte sur la compréhension des écrans et du parcours. Vérifiez ensuite la navigation au clavier et le fonctionnement réel du formulaire sur la page codée.

Vérifier votre rendu individuel

Ouvrez votre fichier et vérifiez qu’il contient :

• Une variable appliquée et sa correspondance CSS.
• Un composant, deux instances et leurs états.
• Le parcours cliquable et son schéma.
• La fiche atelier en mobile et en desktop, avec un contraste mesuré.
• Votre observation de test, la correction et ce qui reste à vérifier.

Ce rendu permet d’évaluer votre travail de maquettage. Le dossier du titre DWWM demandera aussi des réalisations codées, sécurisées et testées.

À lire

• Guide de prototypage dans Figma, aide de Figma.
• Thinking Aloud: The #1 Usability Tool, Nielsen Norman Group, sur le test où la personne pense à voix haute. En anglais.

Pour la discussion

• Quel choix UI aide votre persona à décider de s’inscrire ?
• Quel état manquait dans vos wireframes ?
• Qu’avez-vous changé après avoir vu quelqu’un utiliser la maquette ?

Accessibilité, HTML et ARIA

Pour la MJC, un parcours accessible permet de choisir une séance, de remplir le formulaire, de corriger une erreur et de comprendre le résultat. Vérifiez ces actions au clavier et avec un lecteur d’écran (screen reader), en plus de l’affichage.

Votre objectif

Repérer ce qui empêche une personne d’utiliser la page, choisir le HTML adapté et tester la correction. Vous vérifierez aussi les informations reçues par les technologies d’assistance (assistive technologies), comme les lecteurs d’écran.

Reconnaître une barrière

Un élément a le focus lorsqu’il reçoit les actions du clavier. Son contour visible permet de le repérer. Un contacteur (switch) est un dispositif qui permet de commander l’interface avec un geste adapté.

Ces situations peuvent se combiner. Un simulateur montre un effet visuel, sans reproduire l’expérience complète d’une personne. Lors d’un test utilisateur, observez les obstacles du produit sans demander aux participants de révéler un handicap. Exemples d’usages, W3C.

“Je passe parfois 1 heure à remplir un questionnaire et, arrivée à la fin, je ne peux pas cocher la case de consentement qui n’est pas accessible au clavier.”

Virginie, 49 ans, comédienne, malvoyante de naissance. Baromètre de l’accessibilité numérique 2023, page 22.

Une seule case que Tab n’atteint pas suffit à bloquer toute la démarche.

Le RGAA

Le RGAA, Référentiel général d’amélioration de l’accessibilité, est le référentiel officiel français. Sa version 4.1.2 comprend 106 critères répartis en 13 thématiques, des images à la consultation. Chaque critère se vérifie par des tests, avec une méthodologie et des cas particuliers. Dans ce cours, chaque exigence renvoie à un critère RGAA, par exemple critère 3.2 pour le contraste du texte.

Le RGAA transpose les niveaux A et AA des WCAG 2.1, les recommandations internationales du W3C. Un score Lighthouse ne mesure pas la conformité au RGAA. Au 1er octobre 2026, le site officiel annonce RGAA 5 pour fin 2026. Référentiel officiel.

“No ARIA is better than Bad ARIA.”

« Mieux vaut ne pas utiliser ARIA que de l’utiliser incorrectement. »

Avant d’utiliser ARIA, lisez W3C, Read Me First (en anglais). La page MDN « ARIA » (en français) reprend ce principe et fournit la formulation française citée ici.

Commencer par le HTML

<!-- Une destination -->
<a href="ateliers.html">Voir les ateliers</a>

<!-- Une action -->
<button type="submit">Réserver ma séance</button>

<!-- Un champ nommé -->
<label for="email">Adresse e-mail (obligatoire)</label>
<input id="email" name="email" type="email" required>

Pour choisir entre lien et bouton, demandez-vous si l’on va quelque part. Un lien mène à une page ou à un fichier. Un bouton déclenche une action : envoyer, ouvrir une aide, supprimer. Un <a href="#" onclick="supprimer()"> est annoncé “lien” et ne réagit pas à Espace. Un bouton qui change de page avec location.href ne s’ouvre pas dans un nouvel onglet.

Un div onclick="..." ne fournit pas le comportement clavier d’un bouton. Ajouter role="button" décrit un rôle, mais ne programme ni l’activation ni le focus. Un tabindex="0" le rend atteignable, mais ne suffit toujours pas. Utilisez le bouton natif.

Structurez la page avec des titres h1 à h6, des listes et des régions (landmarks) comme main et nav. Agrandir un paragraphe p ne le transforme pas en titre pour un lecteur d’écran. Pour notre page, gardez un seul h1. C’est une convention de l’exercice, pas une obligation universelle du RGAA.

Un lien s’active avec Entrée. Un bouton natif s’active avec Entrée ou Espace. Tab parcourt les éléments interactifs, pas tous les textes. Évitez les tabindex positifs, qui modifient artificiellement l’ordre de tabulation (tab order). Comportement des boutons, W3C.

<p class="grand-titre">Réserver un atelier</p>
<div role="button" tabindex="0" onclick="reserver()">Réserver</div>

<h1>Réserver un atelier</h1>
<button type="submit">Réserver</button>

Nom, rôle, état

Pour utiliser un contrôle, une personne doit pouvoir connaître son nom (accessible name), son rôle et les états utiles. Pour un composant piloté par JavaScript, le RGAA le vérifie avec le critère 7.1 : le test 7.1.1 demande que le nom, le rôle, la valeur et les changements d’état soient transmis aux technologies d’assistance. Sa méthodologie cite justement le bouton qui affiche ou masque une zone de contenu. Avec <button aria-expanded="false">Afficher l’aide</button>, le lecteur d’écran peut annoncer “Afficher l’aide, bouton, réduit”. Les mots et leur ordre varient selon le lecteur d’écran et ses réglages.

• Le nom “Afficher l’aide” vient du texte visible.
• Le rôle “bouton” vient de la balise button.
• L’état fermé vient de aria-expanded="false".

Une description ajoute une précision, comme le format attendu ou une erreur. Le navigateur regroupe ces informations dans son arbre d’accessibilité (accessibility tree), une représentation de la page destinée aux technologies d’assistance. Inspectez cet arbre, puis testez ce que le lecteur d’écran annonce.

<label for="courriel">Adresse e-mail</label>
<input id="courriel" type="email" aria-describedby="aide-email">
<p id="aide-email">Exemple : prenom@exemple.fr</p>

Ici, le nom est “Adresse e-mail”. Le format est une description. aria-describedby ne remplace pas un label.

Quand utiliser aria-label

Privilégiez le texte visible et les associations HTML natives. Un bouton textuel clair n’a généralement pas besoin d’ARIA. Un bouton composé uniquement d’une icône peut avoir un aria-label qui décrit son action.

<button type="button" aria-label="Fermer l’aide">
  <span aria-hidden="true">×</span>
</button>

Le rôle bouton est déjà fourni par HTML. Il est inutile d’écrire “bouton Fermer l’aide”. Une icône ambiguë peut aussi nécessiter un texte visible pour aider les personnes qui voient l’écran.

Si une image est le seul contenu du bouton et qu’aucun attribut ARIA ne remplace son nom, son alt fournit le nom du bouton. Écrivez l’action, alt="Rechercher", pas le dessin, alt="Loupe". RGAA, critère 11.9.

Le piège à repérer

<button aria-label="Supprimer">Recommencer</button>

<button type="button">Recommencer</button>

<h2 id="titre-contact">Contacter la MJC</h2>
<form aria-labelledby="titre-contact">
  <!-- Champs avec leurs propres labels -->
</form>

Un état qui change

ARIA décrit l’état. Votre JavaScript doit le mettre à jour à chaque clic.

<button type="button" aria-expanded="false"
  aria-controls="aide">
  Aide sur l’adresse e-mail
</button>
<p id="aide" hidden>Exemple : prenom@exemple.fr</p>

bouton.addEventListener('click', () => {
  const ouvert = bouton.getAttribute('aria-expanded') === 'true';
  bouton.setAttribute('aria-expanded', String(!ouvert));
  aide.hidden = ouvert;
});

aria-expanded doit toujours correspondre à ce qui est affiché. aria-controls pointe vers l’identifiant du panneau. hidden cache le panneau à tout le monde. Sans JavaScript, <details> et <summary> gèrent cet état à votre place.

Gardez un intitulé neutre, comme “Aide sur l’adresse e-mail”. Changer aussi le texte du bouton n’est pas une non-conformité, mais le lecteur d’écran peut annoncer “Masquer l’aide, développé”, ce qui est redondant. Access42, afficher et masquer une zone, RGAA, critère 7.1, motif disclosure, W3C.

Images, couleurs et zoom

Le texte alternatif (alt text), porté par l’attribut alt, dépend du rôle de l’image dans la page :

• Une image informative demande un texte qui transmet l’information utile.
• Une décoration utilise alt="" pour être ignorée par les lecteurs d’écran.
• Une image seule dans un lien ou un bouton doit en décrire la destination ou l’action.
• Un graphique demande souvent une description détaillée ou un tableau en complément.

La même photo peut être informative dans une page et décorative dans une autre. Vérifiez le sens de son alternative, pas seulement sa présence. Le RGAA vérifie l’alternative d’une image porteuse d’information (1.1), l’image décorative ignorée (1.2), la pertinence de l’alternative (1.3) et la description détaillée (1.6). Pour une image seule dans un lien, voyez le test 6.1.2. RGAA, thématique Images.

Mesurez le contraste du texte (critère 3.2) : au moins 4,5:1 pour le texte courant et 3:1 pour le grand texte, soit au moins 24 px, ou 18,5 px en gras. Les composants d’interface et les éléments graphiques porteurs d’information demandent au moins 3:1 (critère 3.3). L’information ne doit pas être donnée uniquement par la couleur (critère 3.1). Les cas particuliers se lisent dans chaque critère. RGAA, thématique Couleurs.

Faites deux tests : agrandissez le texte à 200 % (critère 10.4), puis réduisez la largeur de la fenêtre à 320 px CSS (critère 10.11). Le contenu doit se réorganiser sans perte d’information ni défilement horizontal. Les tableaux de données, les images et les graphiques font partie des cas particuliers qui peuvent défiler dans les deux directions.

Cette réorganisation s’appelle le reflow. Un zoom navigateur à 400 % sur une fenêtre de 1280 px donne la même largeur de 320 px. RGAA, critère 10.11.

44 × 44 px est un objectif de confort pour nos boutons. RGAA 4.1.2 ne fixe pas de taille minimale pour les cibles cliquables.

<!-- Illustration décorative, information déjà présente dans le texte -->
<img src="illustration.webp" alt="">

<!-- L’image est le seul contenu du lien -->
<a href="/ateliers/photo/">
  <img src="photo.webp" alt="Découvrir l’atelier photo">
</a>

Formulaires et messages

Gardez des libellés visibles, des consignes avant la saisie et des erreurs écrites qui expliquent la correction. Le placeholder ne remplace pas le label : il disparaît dès qu’on tape et il est souvent trop pâle. Il peut seulement ajouter un exemple.

Un contour rouge seul ne suffit pas. Associez l’erreur au champ, signalez l’état invalide quand il existe et retirez cet état après correction.

<label for="email">Adresse e-mail</label>
<input id="email" type="email" autocomplete="email"
  aria-invalid="true" aria-describedby="email-err">
<p id="email-err">Il manque le @. Exemple : prenom@exemple.fr</p>

En arrivant sur le champ, vérifiez que le lecteur d’écran restitue “Adresse e-mail”, l’état invalide et le message. L’ordre et les mots employés peuvent varier selon l’outil. RGAA, critères 11.1, 11.10 et 11.11. autocomplete="email" permet le remplissage automatique, demandé par le critère 11.13 pour les champs qui concernent l’utilisateur.

Pour une confirmation ajoutée sans recharger la page, prévoyez une zone role="status" avant d’y insérer le message. C’est une région live (live region) : ses mises à jour peuvent être annoncées sans déplacer le focus. Avec ce rôle, l’annonce attend généralement que le lecteur d’écran ait fini de parler (polite).

Pour un message qui signale une erreur ou propose une suggestion sans déplacer le focus, le RGAA demande role="alert". Son annonce peut interrompre la lecture (assertive). Évitez une annonce à chaque frappe. aria-live="off" désactive ce mode d’annonce automatique, sans masquer le contenu au lecteur d’écran. RGAA, critère 7.5.

Pour un disclosure, un bouton qui affiche et masque un contenu, commencez par <details><summary>…</summary>…</details>. Pour une boîte de dialogue (dialog, ou modale), étudiez <dialog> avant de réinventer un composant. ARIA renseigne la sémantique, il ne crée pas les interactions. Principes ARIA.

<fieldset>
  <legend>Votre séance</legend>
  <label><input type="radio" name="seance" value="mercredi"> Mercredi à 14 h</label>
  <label><input type="radio" name="seance" value="samedi"> Samedi à 10 h</label>
</fieldset>

<details>
  <summary>Que faut-il apporter à l’atelier photo ?</summary>
  <p>Votre téléphone suffit. La MJC prête le reste du matériel.</p>
</details>

Médias, mouvement et compréhension

Une vidéo de cours doit pouvoir être comprise sans entendre sa bande-son. Les sous-titres (captions) restituent la parole et les sons utiles. Une transcription (transcript) permet de relire le contenu. Si une information nécessaire n’existe qu’à l’image, décrivez-la à l’oral ou prévoyez l’alternative adaptée au média. Les exigences précises dépendent du type de média et des cas particuliers. Le RGAA demande par exemple des sous-titres synchronisés (critère 4.3) et une transcription textuelle ou une audiodescription (critère 4.1). RGAA, thématique Multimédia.

Évitez les animations automatiques qui concurrencent la lecture. Quand un contenu bouge ou clignote, vérifiez que l’utilisateur peut l’arrêter, selon le critère 13.8 du RGAA. Respecter prefers-reduced-motion est utile, mais ne suffit pas à vérifier tous les critères liés au mouvement.

Pour réduire l’effort de compréhension, donnez une consigne par étape, utilisez des libellés stables et écrivez des erreurs qui indiquent quoi corriger. Gardez les consignes indispensables visibles. Réservez les disclosures aux explications complémentaires.

Tester et documenter l’accessibilité

Un constat d’accessibilité doit permettre à quelqu’un de reproduire le problème et de le corriger. Indiquez la page, les étapes du test, la difficulté rencontrée et le résultat attendu.

Comparer des exemples

Une déclaration qui annonce une conformité totale s’appuie sur un audit daté et un périmètre précis. Lisez les pages et les environnements testés. Le résultat ne couvre pas tous les usages possibles et peut évoluer avec le site.

Lire les chiffres d’un audit

Le baromètre Contentsquare Foundation 2023 étudie 50 sites français, sur trois pages par site et une sélection de 11 critères RGAA parmi les plus bloquants. Les audits manuels ont été réalisés par Numérik-ea et Temesis.

52 % des sites étudiés sont sous 50 %, et 64 % ne publient pas leur taux. Les sites publics, soumis à une obligation depuis 2005, arrivent en tête. Le graphique suivant détaille quatre familles de critères. Il sert à comparer les obstacles étudiés, pas à décrire l’état de tous les sites en 2026.

Tester en cinq étapes

Avant de commencer, fixez le périmètre : une tâche, les pages concernées et les états à tester. Pour l’exercice local, la page fournie suffit. Notez les URL, la date, le navigateur et les outils. Suivez ensuite ces étapes dans l’ordre.

1. Réalisez la tâche au clavier. Tab avance et Maj+Tab revient entre les éléments interactifs. Entrée active un lien ou un bouton. Espace active un bouton ou une case à cocher. Vérifiez l’ordre de tabulation (tab order), le focus visible et les menus. Repérez les pièges au clavier (keyboard trap, souvent appelé focus trap), où le focus reste bloqué. Dans une boîte de dialogue ouverte, garder le focus à l’intérieur est voulu, tant qu’Échap ou un bouton permet d’en sortir. Tab ne parcourt pas les paragraphes.
2. Testez avec un lecteur d’écran (screen reader). Repérez un titre, un champ et un bouton. Vérifiez les noms, les rôles, les états et les messages annoncés. Inspectez aussi le HTML et l’arbre d’accessibilité (accessibility tree) : titres, noms des liens, libellés, langue et alternatives des images.
3. Vérifiez l’affichage et les médias. Agrandissez le texte à 200 %, essayez une largeur de 320 px et mesurez les contrastes. Dans les DevTools de Chromium, ouvrez Rendering puis “Emulate vision deficiencies” pour examiner les couleurs. Vérifiez qu’une information reste compréhensible sans distinguer le rouge du vert. Coupez le son d’une vidéo et vérifiez que les sous-titres (captions) restituent la parole et les sons utiles.
4. Lancez une analyse automatique avec axe, WAVE ou Lighthouse. Examinez au moins un résultat dans la page. Les alertes “à vérifier” demandent votre analyse. Un score de 100 ne certifie pas le site.
5. Documentez et retestez. Notez le constat, sa preuve et la correction proposée. Après modification, refaites les mêmes manipulations.

Les outils ne jugent pas la pertinence de tous les textes et ne vérifient pas qu’une personne peut terminer le parcours. La part des problèmes détectés dépend de l’outil et de la page. Évaluer l’accessibilité, W3C.

Essayer un lecteur d’écran

Avant de déclarer un défaut clavier sur Mac, vérifiez que la navigation clavier de macOS et du navigateur permet d’atteindre tous les contrôles. Safari et Helium peuvent avoir des réglages différents. Notez le système, le navigateur et le lecteur d’écran utilisés. Ce premier essai ne couvre pas toutes les combinaisons à vérifier pour un audit.

Testez sur une page locale, avec des données fictives. Notez ce qui est réellement annoncé. L’arbre d’accessibilité aide à diagnostiquer, mais ne remplace pas la restitution du lecteur d’écran. Si le lecteur ne fonctionne pas, indiquez “non testé” et notez le blocage. Consultez le guide correspondant ci-dessus pour vérifier son activation et ses réglages, puis refaites l’essai. Vous pouvez poursuivre les autres tests en conservant cette limite dans vos notes.

Lire un critère RGAA

Ouvrez les critères et tests. Pour une action impossible au clavier, cherchez 7.3, puis son test 7.3.1. Lisez les conditions du test et les cas particuliers, puis appliquez-le à la page. Expliquez ce que vous avez vérifié et le résultat observé.

Utilisez ces repères pour trouver le critère, puis lisez son test avant de conclure.

Un constat utile

Sur la page locale a-corriger.html, après le champ e-mail, Tab passe directement à Recommencer. L’action Recevoir les informations est un div cliquable absent du parcours clavier. Une personne utilisant uniquement le clavier ne peut pas déclencher cette demande. Je propose un bouton submit et un gestionnaire submit sur le formulaire. Je retesterai avec Tab puis Entrée, y compris avec une saisie invalide.

Une capture montre l’affichage à un instant donné. Pour expliquer le parcours du focus, ajoutez les touches utilisées et le résultat observé. Distinguez les corrections proposées sur un site externe de celles réalisées dans votre code.

Notez vos constats dans votre dossier. Vous pouvez copier le modèle de diagnostic pour structurer vos notes. Ce diagnostic limité ne produit pas de taux de conformité. Un audit RGAA complet exige un échantillon et l’ensemble des critères applicables, avec la méthode prévue. Méthode officielle.

Atelier : tester et corriger une page

Vous testez une page qui pose des problèmes d’accessibilité, vous la corrigez, puis vous testez un site existant. Conservez vos observations et vos corrections dans un dossier de travail.

Pour cet atelier, préparez un navigateur, un éditeur de code et un lecteur d’écran. Les pages HTML et ARIA et méthode de test expliquent les notions et les manipulations utilisées. La page à corriger est fournie : vous pouvez suivre l’atelier sans avoir réalisé le projet MJC.

Ce que vos notes doivent permettre de vérifier

“Voici ce qui bloque, voici qui est gêné, voici ma correction et le test qui le prouve.”

Décrivez les manipulations et leurs résultats pour pouvoir reproduire chaque test.

1. Tester la page

Téléchargez la page à corriger avec “Enregistrer la page sous”. Ouvrez-la dans votre navigateur et dans votre éditeur.

Faites les cinq étapes du test : clavier, lecteur d’écran, affichage, outil automatique, notes. Faites ce premier test sans IA.

Pour chaque problème, notez dans votre dossier :

• où il se trouve et comment le reproduire,
• qui est gêné et ce que cela empêche de faire,
• comment le corriger.

Exemple : “Le bouton Recevoir les informations est un div. Tab le saute. Une personne au clavier ne peut pas envoyer sa demande. Il faut un <button>.”

Comparez vos observations avec la liste ci-dessous après votre premier passage. Pour chaque problème que vous n’aviez pas repéré, revenez à la page et essayez de le reproduire.

2. Corriger la page

Faites une copie nommée corrige.html. Corrigez un problème à la fois, puis refaites le même test. Commencez par ce qui bloque : le bouton d’envoi, le champ sans label, le message d’erreur.

Le bouton ”?” affiche et masque une aide : c’est un disclosure. Donnez-lui un nom clair, puis faites changer aria-expanded à chaque clic. La section Un état qui change montre le code.

Pour trois corrections, notez dans votre dossier le test avant et après.

3. Tester un vrai site

Choisissez une page d’un site existant, par exemple celui de votre audit UX, ou la démonstration du W3C. Faites les cinq étapes. Notez un ou deux problèmes dans votre dossier, avec la personne gênée et la correction que vous proposez.

Ne remplissez aucun formulaire réel.

L’IA

Vous pouvez utiliser l’IA pour proposer une correction. Vérifiez chaque proposition dans votre page avec les mêmes tests qu’avant la modification. Gardez uniquement le code dont vous comprenez le rôle et dont vous avez vérifié le résultat.

Vérifier votre travail

Votre dossier doit contenir une section Accessibilité avec :

1. Les problèmes trouvés sur a-corriger.html et sur le site testé.
2. Trois corrections, avec le test avant et après.
3. Votre fichier corrige.html.

Pour chacune des trois corrections, vérifiez que vos notes indiquent les manipulations, le résultat avant modification et le résultat après. Signalez les points non testés ou encore à corriger. Le modèle de diagnostic peut vous servir de support.

Vérifier votre compréhension

Répondez sans consulter le cours ni utiliser l’IA, puis comparez avec les réponses.

1. Pourquoi role="button" ne suffit-il pas à rendre un div utilisable au clavier ?
2. Un bouton affiche “Recommencer” mais porte aria-label="Supprimer". Quel problème cela pose-t-il et comment le corriger ?
3. Une erreur de saisie est signalée uniquement en rouge. Que faut-il ajouter ?
4. Un score de 100 à un outil automatique prouve-t-il que le parcours est accessible ?

Pour prolonger l’exercice, appliquez une correction à votre propre page MJC ou à une autre page dont vous pouvez modifier le code. Documentez le test avant et après.

Sources et crédits des illustrations.

Atelier en équipe : le site de la MJC Tilleul

En équipe, reprenez votre travail précédent et réalisez un parcours d’inscription en HTML, CSS et JavaScript. Utilisez des données fictives : l’inscription est une simulation.

La démonstration collective commence à 13 h. L’après-midi sera consacré au SEO, le référencement dans les moteurs de recherche.

Le parcours à réaliser

Choisissez une US (user story) de votre travail précédent : une phrase qui décrit le besoin d’un utilisateur.

Exemple : « En tant que parent, je souhaite inscrire mon enfant à une activité adaptée à son âge. »

Notez deux ou trois critères d’acceptation : des points à vérifier pour valider votre travail. Par exemple : « La fiche indique l’âge requis, les horaires et le tarif » et « Une adresse e-mail invalide affiche un message qui aide à la corriger ».

Reliez ces cinq pages :

1. Accueil (index.html).
2. Liste des activités.
3. Détail d’une activité.
4. Formulaire d’inscription.
5. Confirmation de l’inscription simulée.

Quelques activités fictives suffisent, avec une seule fiche détaillée. Si le formulaire est mal rempli, affichez une erreur qui explique comment corriger la saisie. Une fois le formulaire correctement rempli, affichez la confirmation.

Les composants au choix

Ajoutez un ou plusieurs composants accessibles, là où ils aident l’utilisateur :

• Une modale : une fenêtre au-dessus de la page, par exemple une aide.
• Un accordéon : des sections que l’on ouvre et ferme, par exemple des questions fréquentes.
• Des onglets : plusieurs panneaux de contenu, dont un seul est affiché à la fois.

Les vérifications avant 13 h

Gardez les 30 à 40 dernières minutes de la matinée pour tester et corriger le parcours complet.

• Faites le parcours sans souris : Tab et Maj+Tab pour vous déplacer, Entrée pour activer un lien, Entrée ou Espace pour un bouton. Le focus indique quel élément reçoit les actions du clavier : il doit avoir un repère visible. Testez aussi Échap pour fermer une modale ou les flèches pour changer d’onglet.
• Testez une erreur de formulaire, puis corrigez-la. Chaque champ doit avoir un libellé clair et l’erreur doit expliquer quoi corriger.
• Vérifiez les contrastes, le zoom à 200 % et l’affichage à 320 px de large. Tout doit rester lisible et utilisable.
• Avec un lecteur d’écran, comme VoiceOver ou NVDA, écoutez un champ, un bouton et le résultat du formulaire. Vérifiez les textes alternatifs des images utiles.
• Visez 100/100 en Accessibilité dans Lighthouse sur les cinq pages. Utilisez un serveur local, comme Live Server. Ce score ne remplace pas les tests manuels.

Si vous n’avez pas terminé, indiquez ce qui fonctionne, ce qui reste à faire et les tests que vous n’avez pas pu effectuer.

La démonstration à 13 h

Présentez votre US, le parcours au clavier, une erreur de formulaire et sa correction. Montrez le ou les composants choisis et expliquez vos tests et les difficultés restantes.

Chaque membre de l’équipe explique au moins un choix ou une correction qu’il a réalisé.

La grille d’appréciation individuelle

Pour chaque équipe présentée, remplissez cette grille individuellement.

**Votre prénom : …

Équipe observée : …

Pour chaque ligne, choisissez un avis et ajoutez un exemple court :

• Satisfaisant : ce qui a été montré fonctionne et se comprend.
• À améliorer : vous avez observé une difficulté. Précisez laquelle.
• Non observé : le point n’a pas été montré ou testé.

Terminez par :

• Un point réussi, avec un exemple.
• Une amélioration prioritaire, son intérêt pour l’utilisateur et une proposition concrète.**

Exemple : « Les horaires et les tarifs sont faciles à trouver sur la fiche. Le bouton d’inscription est difficile à repérer. Augmenter son contraste aiderait les visiteurs à poursuivre leur inscription. »