freedzhost.cloud

Web design module 3 : responsive, tokens et systèmes

Niveau DébutantTemps estimé 14 hÀ lire avant Web design module 2 : les outils et les règlesUn mot inconnu ? Lexique

Quatorze séances pour faire vivre la maquette : elle s'adapte aux écrans (responsive), au mode sombre, et elle devient un système — tokens, composants documentés, micro-interactions, prototype cliquable. C'est le module où le dessin devient un livrable qu'un développeur peut réaliser sans deviner.

Jour 29 — Responsive 1/3 : les unités relatives

Objectif : savoir quand mesurer en px, en rem, en % ou en vw.

Théorie 1/2 : le pixel qui n'en est pas un

Le « pixel CSS » (px) n'est pas un pixel d'écran : c'est une unité de référence, agrandie par le zoom et par les écrans denses. Quatre unités font le responsive : le px, pour ce qui ne doit pas bouger (bordures de 1-2px, rayons) ; le rem, qui vaut la taille de police racine du document (16px par défaut, mais l'utilisateur peut l'avoir augmentée dans ses réglages — tailles de texte et espacements en rem respectent ce choix, en px ils l'ignorent) ; le %, relatif au parent (largeurs de colonnes) ; et le vw/vh, pourcentages de la fenêtre, utiles avec parcimonie (un titre en vw grandit avec l'écran mais peut devenir immense ou minuscule : on le borne). Règle du parcours : textes et espacements en rem, largeurs en % ou colonnes de grille, px pour les traits.

Exercice généré à l'infini (JavaScript requis) : convertir des px en rem (racine à 16px).

Théorie 2/2 : pourquoi le rem est une question d'accessibilité

Le critère WCAG 1.4.4 exige que le texte puisse être agrandi à 200 % sans perte de contenu ni de fonction. Un texte dimensionné en rem suit le réglage de taille de police du navigateur ; un texte en px ne le suit pas (le zoom page compense, mais il dégrade la mise en page : colonnes qui débordent, scroll horizontal). La même logique touche les espacements : une marge en rem respire quand le texte grandit. Le rem n'a qu'un piège : il ne faut pas changer la taille racine soi-même sans raison — toute la chaîne de conversion mentale (16px = 1rem) repose sur le défaut.

Pourquoi dimensionner les textes en rem plutôt qu'en px ?

  1. c'est plus rapide à charger
  2. pour respecter le réglage de taille de police de l'utilisateur (WCAG 1.4.4)
  3. parce que le px est déprécié
Réponse

Le rem suit la préférence de l'utilisateur ; le px l'ignore. Le px reste correct pour ce qui ne doit pas changer : bordures, rayons.

Pratique (30 min)

  1. Dans les devtools, réglez la taille de police racine à 24px (onglet Settings/Préférences, ou préférence « taille de police » du navigateur) et visitez deux sites connus : lesquels suivent ? Lesquels restent figés ? Notez-le.
  2. Analyse : sur un site qui suit, inspectez les tailles de texte : sont-elles en rem ? Notez trois valeurs.
  3. Micro-exercice : convertissez votre échelle typographique du jour 4 en rem (base 16) : 12, 16, 20, 25, 31, 39 → ? Écrivez les deux colonnes au carnet.

Critère de réussite : deux sites testés au réglage 24px avec le verdict noté, et votre échelle convertie en rem sans erreur.

Tips agent : « Convertis cette échelle en rem (base 16px) : 12, 16, 20, 25, 31, 39. Donne un tableau px/rem, et signale les valeurs qui ne tombent pas juste. » Piège : 31px = 1,9375rem, il arrondira peut-être en silence. Exigez la valeur exacte. Preuve : divisez deux des valeurs à la main.

Synthèse (10 min)

Trois lignes : les quatre unités et leurs rôles, ce que mesure 1.4.4, le piège du rem. Puis refaites la conversion de l'échelle sans notes.

Jour 30 — Responsive 2/3 : mobile-first et points de rupture

Objectif : concevoir d'abord pour l'écran le plus contraignant et choisir des points de rupture par le contenu.

Théorie 1/2 : mobile-first

Concevoir mobile-first — commencer par l'écran étroit, enrichir en élargissant — n'est pas une mode mais une discipline : sur 375px de large, chaque élément doit justifier sa présence et son ordre. La décision difficile (qu'est-ce qui est essentiel ?) est prise là où la place manque, pas à la fin quand tout doit rentrer. L'inverse, « desktop d'abord », produit des pages riches qu'on découpe ensuite en supprimant — et le mobile hérite des restes. Le trafic mobile représente plus de la moitié du web mondial depuis 2016-2017 ; sur beaucoup de services grand public, il est majoritaire. La contrainte étroite n'est pas une punition : c'est un filtre à priorités.

L'argument principal du mobile-first est…

  1. la contrainte de place force à décider des priorités de contenu
  2. les mobiles sont plus rapides
  3. les écrans de bureau disparaissent
Réponse

C'est une discipline de priorisation : ce qui tient en 375px tient partout, et l'élargissement ajoute au lieu de supprimer.

Théorie 2/2 : les points de rupture

Un point de rupture (breakpoint) est la largeur à laquelle la mise en page change : une colonne devient trois, le menu devient hamburger. Deux écoles : suivre les appareils (360-428px mobiles, 768px tablette, 1024-1440px desktop — repères courants, pas normes) ou suivre le contenu : élargir la fenêtre jusqu'à ce que la mise en page casse, et poser le rupteur là. La bonne pratique mélange les deux : on conçoit aux largeurs courantes, on vérifie aux largeurs intermédiaires. Trois ruptures suffisent à la plupart des sites (mobile, tablette, desktop) ; chaque rupture ajoutée est une mise en page de plus à maintenir.

Un point de rupture bien choisi se pose…

  1. à la largeur exacte de l'iPhone le plus récent
  2. au hasard, on les ajoute au besoin
  3. là où la mise en page cesse de fonctionner, en partant des largeurs courantes
Réponse

Le contenu décide : on part des largeurs usuelles (375, 768, 1280) et on ajuste là où la mise en page casse réellement.

Pratique (30 min)

  1. Dans les devtools, ouvrez le mode appareil (Ctrl+Maj+M dans Chrome/Firefox) sur un site que vous aimez. Faites glisser la largeur de 360 à 1440px lentement : notez chaque largeur où la mise en page change.
  2. Pour chaque rupture observée, notez ce qui change : nombre de colonnes, menu, tailles ?
  3. Micro-exercice : au carnet, listez pour votre maquette du jour 19 ce qui changera à chaque rupture : « 375px : 1 colonne, hamburger ; 768px : 2 colonnes ; 1280px : 3 colonnes, barre complète ».

Critère de réussite : les ruptures d'un site réel relevées avec ce qui change à chacun, et le plan de ruptures de votre maquette écrit.

Tips agent : « Voici les blocs de ma page et leur ordre : [liste]. Propose un plan de ruptures (375/768/1280) : à chaque largeur, disposition et ce qui change. » Piège : il appliquera des recettes sans regarder votre contenu. Preuve : chaque changement proposé répond à un problème visible quand vous redimensionnez.

Synthèse (10 min)

Trois lignes : ce que mobile-first force à décider, comment on pose un rupteur, pourquoi trois suffisent. Puis récitez votre plan de ruptures sans notes.

Jour 31 — Responsive 3/3 : décliner un écran

Objectif : décliner proprement une maquette desktop en mobile.

Théorie 1/2 : les patrons de passage

Quatre patrons couvrent la plupart des déclinaisons desktop → mobile : l'empilement (les colonnes deviennent des lignes, dans l'ordre d'importance — jour 20), le repli (le menu devient hamburger, les filtres deviennent un panneau), la redimension (le visuel passe de moitié d'écran à pleine largeur, les tailles de titres descendent d'un cran ou deux de l'échelle) et la substitution (un tableau trop large devient une liste de cartes — le contenu est le même, la forme change). Le mobile n'est pas un desktop rétréci : les cibles passent au doigt (44px de confort, jour 24), le texte reste à 16px minimum pour éviter le zoom forcé des champs sur iOS, et le scroll vertical remplace la densité horizontale.

Un tableau à huit colonnes sur mobile devient de préférence…

  1. le même tableau, plus petit
  2. une liste de cartes empilées, même contenu, autre forme
  3. une image du tableau
Réponse

La substitution : huit colonnes en 375px sont illisibles ; une carte par ligne garde le contenu lisible. Rétrécir n'est pas adapter.

Théorie 2/2 : les erreurs classiques du passage

Trois fautes reviennent dans les déclinaisons de débutant : réduire le corps du texte « pour que ça tienne » (le mobile mérite le même 16px, pas moins), serrer les espacements (au contraire, l'empilement a besoin d'air vertical constant — vos 16-24-48 du jour 9), et cacher du contenu sans raison (le mobile est une réorganisation, pas une amputation — on replie ce qui est secondaire, on ne le supprime pas). Test de vérité : parcourez la version mobile avec le pouce : les actions principales sont-elles atteignables, les cibles assez grandes, le texte lisible sans zoom ?

Sur mobile, le corps du texte courant doit…

  1. rester à 16px minimum
  2. descendre à 12-13px pour gagner de la place
  3. passer à 20px
Réponse

16px : en dessous, la lecture fatigue et iOS zoome les champs de formulaire. La place se gagne par l'empilement, pas par le rapetissement.

Pratique (30 min)

  1. Dans Penpot, déclinez la maquette desktop du jour 20 en board mobile 375px : empilez les colonnes dans l'ordre d'importance, repliez le menu en hamburger, remettez les tailles de titres un à deux crans plus bas.
  2. Vérifiez les trois fautes classiques : corps à 16px, espacements verticaux de l'échelle, aucun contenu supprimé (replié, oui ; amputé, non).
  3. Test du pouce : imprimez mentalement la zone basse de l'écran : votre action principale y est-elle, ou au moins est-elle atteignable sans contorsion ?

Critère de réussite : une version mobile complète, sans contenu perdu, corps 16px, cibles tactiles respectées, hiérarchie identique au desktop.

Tips agent : « Voici la structure desktop de ma page : [blocs]. Propose la déclinaison mobile (ordre d'empilement, ce qui se replie, ce qui se substitue) et signale tout contenu qui serait supprimé — il ne doit y en avoir aucun. » Piège : il proposera de « masquer » allègrement. Preuve : inventaire avant/après, chaque bloc desktop a une adresse mobile.

Synthèse (10 min)

Trois lignes : les quatre patrons, les trois fautes classiques, le test du pouce. Puis redonnez les quatre patrons sans notes.

Jour 32 — Tester sans matériel

Objectif : vérifier un design aux conditions réelles avec les seuls devtools.

Théorie 1/2 : la panoplie d'évaluation du navigateur

Le mode appareil des devtools (Ctrl+Maj+M) simule largeurs, densités de pixels et écran tactile ; le panneau « Rendering » de Chrome émule prefers-color-scheme (mode sombre), prefers-reduced-motion et des déficiences visuelles (protanopie, deutéranopie, vision floue) ; le zoom à 200 % (Ctrl+molette) reproduit l'agrandissement exigé par WCAG 1.4.4 ; et le clavier seul (Tab, Maj+Tab, Entrée, Échap) teste l'opérabilité. Ajoutez la limitation de débit (throttling) pour voir la page charger lentement. Aucun de ces tests ne remplace un vrai appareil entre de vraies mains, mais ensemble ils attrapent l'essentiel des fautes avant que personne ne les subisse.

Pour vérifier qu'un design survit à l'agrandissement de texte WCAG, on…

  1. réduit la fenêtre
  2. change la résolution de l'écran
  3. zoome la page à 200 % ou augmente la taille de police racine
Réponse

Zoom 200 % (ou police racine doublée) : le critère 1.4.4 exige que tout reste lisible et utilisable.

Théorie 2/2 : le protocole de test en dix minutes

Un protocole écrit évite les « ça a l'air bien ». Le nôtre, dix étapes pour toute page : (1) lecture normale desktop ; (2) largeur 375px ; (3) largeur intermédiaire 700px ; (4) zoom 200 % ; (5) clavier seul, du haut en bas ; (6) émulation deutéranopie ; (7) mode sombre si prévu ; (8) contraste des couples principaux mesuré ; (9) lecture des textes à voix haute ; (10) scroll complet à la recherche de débordements horizontaux. Chaque étape produit une ligne au carnet : OK ou problème + règle + correction. Dix minutes, dix lignes : c'est la version minimale de ce qu'une équipe appelle une revue de design.

Le débordement horizontal (scroll latéral) sur mobile est en général causé par…

  1. un texte trop long
  2. un élément à largeur fixe qui dépasse la fenêtre
  3. le mode sombre
Réponse

Une largeur fixe (un tableau, une image, un bloc en px) qui dépasse les 375px. Le test 10 le repère immédiatement.

Pratique (30 min)

  1. Appliquez le protocole en dix étapes à une page réelle de votre choix. Carnet ouvert : une ligne par étape.
  2. Relevez au moins un problème réel (il y en a presque toujours un) et rédigez-le au format problème + règle + correction.
  3. Appliquez les étapes 2, 4 et 5 à votre maquette Penpot des jours 19-31 (exportez en PNG pour le zoom, simulez le clavier en décrivant l'ordre de tabulation attendu).

Critère de réussite : le protocole appliqué à une page réelle avec dix lignes au carnet et un problème rédigé au format complet.

Tips agent : un agent avec navigateur pilotable peut exécuter les étapes 2 à 8 seul : « Charge cette page à 375px, zoome à 200 %, liste les débordements et les contrastes sous 4,5:1, avec capture à l'appui. » Piège : ses mesures de contraste restent à vérifier (jour 23). Preuve : exigez les captures et re-mesurez un couple à la main.

Synthèse (10 min)

Trois lignes : les outils d'évaluation des devtools, les dix étapes, le format de chaque ligne. Puis récitez le protocole sans notes.

Jour 33 — Mode sombre 1/2 : les principes

Objectif : dériver une palette sombre qui respecte la hiérarchie et le contraste.

Théorie 1/2 : le sombre n'est pas l'inversé

Inverser mécaniquement une palette claire échoue : le noir pur (#000) en fond crée une fatigue (le texte blanc pur y « vibre » par halation) et les ombres deviennent invisibles. Les design systems éprouvés (Material de Google, HIG d'Apple) convergent : fonds en gris très foncé plutôt qu'en noir (Material recommande #121212), texte en blanc cassé (87 % d'opacité chez Material, soit environ #FFF à 87 %), et l'élévation se lit en éclaircissant : plus une surface est « au-dessus » (carte, menu, modale), plus son gris est clair — là où le mode clair utilise l'ombre. L'accent, lui, se désature et s'éclaircit légèrement : un bleu vif saturé sur fond sombre bave visuellement et perd en contraste mesuré.

En mode sombre, la carte posée sur la page se distingue par…

  1. une ombre plus forte
  2. un gris légèrement plus clair que le fond
  3. une bordure blanche
Réponse

En sombre, l'élévation s'exprime par la luminosité : plus la surface est haute, plus elle est claire. L'ombre y est quasi invisible.

Théorie 2/2 : les seuils ne changent pas

Bonne nouvelle : les seuils WCAG sont identiques en sombre — 4,5:1 texte courant, 3:1 grand texte et composants. Mauvaise nouvelle : il faut tout re-mesurer, car la relation s'inverse (un texte gris moyen qui passait sur blanc peut échouer sur gris foncé, et réciproquement). Deux pièges spécifiques : les couleurs sémantiques (un rouge erreur pensé pour le clair est souvent trop sombre sur fond noir — on l'éclaircit) et les images avec fond blanc « plaqué » (prévoyez leur variante ou leur cadre). Le mode sombre se choisit par la préférence système (prefers-color-scheme) et se laisse toujours forcer à la main : un utilisateur peut préférer le clair même la nuit.

Le contraste du texte en mode sombre doit atteindre…

  1. les mêmes seuils WCAG qu'en clair : 4,5:1 pour le texte courant
  2. la moitié, car le sombre fatigue moins
  3. 7:1 obligatoirement
Réponse

Les seuils ne changent pas avec le thème : 4,5:1 et 3:1, re-mesurés couple par couple.

Pratique (30 min)

  1. Au carnet, dérivez votre palette du jour 23 en version sombre : fond (~#121212), surface carte (un cran plus clair), texte principal (blanc à ~87 %), texte secondaire, accent éclairci et désaturé, erreur éclaircie.
  2. Mesurez chaque couple texte/fond dans WebAIM : tous doivent passer leurs seuils. Corrigez par la luminosité sinon.
  3. Analyse du jour : activez le mode sombre d'un site qui le propose (les devtools : Rendering → emulate prefers-color-scheme: dark). Relevez son fond, sa surface et son texte : vérifiez la règle d'élévation.

Critère de réussite : une palette sombre complète, chaque couple mesuré AA, et la règle d'élévation vérifiée sur un site réel.

Tips agent : « Dérive ma palette claire [hex] en palette sombre selon les règles Material (#121212, élévation par éclaircissement, accent désaturé), avec les ratios AA de chaque couple. » Piège : il inventera les ratios. Preuve : chaque couple re-mesuré dans WebAIM avant d'entrer dans la bibliothèque.

Synthèse (10 min)

Trois lignes : pourquoi pas de noir pur, l'élévation par la clarté, ce qui se re-mesure. Puis redérivez la palette sombre sans notes.

Jour 34 — Mode sombre 2/2 : la mise au point

Objectif : dessiner un écran complet en mode sombre et corriger ce qui y casse.

Théorie 1/2 : les composants en sombre

Chaque composant a son adaptation : les champs gardent une bordure visible à 3:1 (sur fond foncé, une bordure gris moyen disparaît — éclaircissez-la) ; le focus reste contrasté dans les deux thèmes (testez le contour clair sur fond foncé) ; les ombres disparaissent au profit de l'élévation claire et éventuellement d'un liseré de bordure à 5-10 % d'opacité ; les images et logos : un logo noir sur transparent disparaît — prévoyez la version claire ou un cartouche. Les couleurs d'état (erreur, succès, avertissement) se redéfinissent pour le sombre dans la bibliothèque : ce sont les mêmes rôles, d'autres valeurs — la première application concrète du nommage sémantique du jour 16.

Un logo noir sur fond transparent, en mode sombre…

  1. reste tel quel
  2. prend une ombre blanche
  3. est remplacé par sa variante claire ou posé sur un cartouche
Réponse

Il disparaît sur fond foncé : variante claire ou cartouche. C'est le cas classique qui impose de penser les assets en deux thèmes.

Théorie 2/2 : organiser les deux thèmes

Deux thèmes dans un fichier, c'est une dette si on les gère à la main : chaque écran existe en double et diverge. L'organisation saine : un seul dessin, des couleurs référencées par rôle, et deux jeux de valeurs (clair/sombre) pour les mêmes rôles — c'est exactement la structure des design tokens avec thèmes, que Penpot gère nativement (onglet Tokens, jeux et thèmes) et qu'on appliquera au jour 36. En attendant, la discipline minimale : les deux versions d'un écran côte à côte, les mêmes composants, seules les références de couleur changent. Si vous vous surprenez à redessiner un composant pour le sombre, c'est que le rôle n'était pas nommé.

La bonne structure pour gérer deux thèmes est…

  1. deux fichiers séparés
  2. un seul dessin, des couleurs nommées par rôle, deux jeux de valeurs
  3. redessiner chaque écran en sombre
Réponse

Les rôles sont stables, les valeurs changent : un dessin, deux jeux. Toute duplication dessinée divergera.

Pratique (30 min)

  1. Dans Penpot, dupliquez la maquette du jour 19 et passez la copie en sombre avec la palette du jour 33 : fonds, textes, accent, états.
  2. Corrigez les quatre points sensibles : bordures de champs à 3:1, focus contrasté, ombres remplacées par l'élévation, tout logo ou image sombre traité.
  3. Test croisé : mesurez le contraste du bouton et du texte secondaire dans les deux thèmes (WebAIM), notez les quatre ratios.
  4. Test gris des deux thèmes (jour 24) : rien d'important ne disparaît.

Critère de réussite : l'écran existe en clair et en sombre, mêmes composants, tous les couples mesurés AA dans les deux thèmes.

Tips agent : « Compare mes deux thèmes [listes de couples hex] : détecte les rôles qui n'ont pas de valeur sombre et les couples sous AA. » Piège : il signalera des « problèmes de goût » au lieu de mesures manquantes. Preuve : sa sortie est une liste de rôles et de ratios, pas d'opinions — chaque ratio revérifié dans WebAIM.

Synthèse (10 min)

Trois lignes : les quatre adaptations des composants, l'organisation rôles + jeux de valeurs, le test croisé. Puis refaites la liste des points sensibles sans notes.

Jour 35 — Design tokens 1/2 : nommer les décisions

Objectif : comprendre ce qu'est un design token et nommer les vôtres en trois niveaux.

Théorie 1/2 : une décision, un nom, une valeur

Un design token est une décision de design stockée sous forme de nom et de valeur : color.accent = #3B82F6, space.md = 16, font.body = 1rem/1.5 Inter. La bibliothèque Penpot du jour 16 en était l'ébauche ; le token ajoute l'idée force : ce nom est le contrat entre le design et le code — le développeur n'écrit pas #3B82F6 mais accent, et changer la valeur change le produit entier. Le W3C abrite un groupe de travail (Design Tokens Community Group) qui standardise un format JSON d'échange entre outils. Les tokens couvrent couleurs, espacements, tailles de texte, rayons, ombres, durées d'animation : toute valeur qui se répète mérite un nom.

Un design token est…

  1. une décision de design nommée, partagée entre le design et le code
  2. une police de caractères
  3. un mot de passe d'API
Réponse

Nom + valeur + rôle : le contrat qui empêche les valeurs isolées de diverger entre la maquette et le produit.

Théorie 2/2 : les trois niveaux

Les tokens s'organisent en trois couches. Les primitifs : la matière brute, nommée par ce qu'elle est — blue.500, gray.100, space.4 (= 16px). Les sémantiques : le rôle, qui référence un primitif — color.text.primary = gray.900, color.accent = blue.500, surface.raised = white. Les composants, optionnels : button.background = color.accent. L'intérêt apparaît au changement : le mode sombre ne redéfinit que les sémantiques (surface.raised passe de white à gray.800), et une refonte d'identité ne touche que les primitifs. La règle de nommage reste celle du jour 16 : le nom dit le rôle, jamais l'aspect — color.error, pas color.red.

button.background = color.accent est un token de niveau…

  1. primitif
  2. sémantique
  3. composant
Réponse

Composant : il nomme une propriété d'un composant précis et référence un sémantique, qui référence un primitif. Trois couches, trois raisons de changer.

Pratique (30 min)

  1. Inventoriez au carnet toutes les valeurs de votre maquette qui se répètent : couleurs, espacements, tailles de texte, rayons, ombre, durées.
  2. Écrivez-les en tokens sur trois niveaux : primitifs (blue.500, gray.50…, space.1 à space.16), sémantiques (fond, surface, texte.principal, texte.secondaire, accent, erreur, bordure), composants (bouton.fond, carte.surface, champ.bordure).
  3. Vérifiez la couverture : chaque valeur de la maquette a un token ; chaque token sert quelque part. Supprimez les orphelins.

Critère de réussite : une liste de tokens à trois niveaux qui couvre toute la maquette, sans orphelin, nommée par rôle.

Tips agent : « Voici mes valeurs de design : [liste]. Structure-les en tokens sur trois niveaux (primitif/sémantique/composant) au format du W3C Design Tokens, et signale toute valeur qui ne se répète pas — elle ne mérite peut-être pas un token. » Piège : il créera des couches inutiles. Preuve : chaque token cité apparaît dans votre maquette.

Synthèse (10 min)

Trois lignes : ce qu'est un token, les trois niveaux et ce qui change à chacun, la règle de nommage. Puis réécrivez vos dix premiers tokens sans notes.

Jour 36 — Design tokens 2/2 : la feuille de tokens

Objectif : matérialiser vos tokens dans Penpot et en exporter la référence.

Théorie 1/2 : les tokens dans l'outil

Penpot gère les tokens nativement : l'onglet Tokens du panneau de gauche permet de créer des jeux (sets) de tokens — couleurs, dimensions, rayons — et de les organiser en thèmes, par exemple « clair » et « sombre », qui donnent deux valeurs au même nom de rôle : c'est l'organisation du jour 34, outillée. Un token appliqué à un objet se met à jour quand le thème change : c'est la fin des écrans dupliqués. L'export (JSON) produit la feuille de référence qu'un développeur transforme en variables CSS (--color-accent: #3B82F6) — le design et le code partagent enfin le même vocabulaire, et la maquette devient une spécification exécutable plutôt qu'une image à interpréter.

Les « thèmes » de tokens servent à…

  1. changer la police du document
  2. donner deux jeux de valeurs (clair/sombre) aux mêmes rôles, et basculer tout le fichier
  3. exporter des images
Réponse

Le thème est un jeu de valeurs : les rôles sont stables, les valeurs changent, tout le fichier bascule d'un coup.

Théorie 2/2 : les échelles en tokens

Vos échelles des jours 4 et 8 deviennent des familles de tokens : space.1 = 4px à space.16 = 64px (l'indice dit le nombre de pas de 4, la valeur se devine), font.size.100 = 0.75rem à font.size.600 = 3rem. Écrire l'échelle en tokens a deux vertus : elle interdit les valeurs intermédiaires improvisées (il n'existe pas de space.7,5), et elle rend les revues lisibles — « ici c'est space.6 au lieu de space.4 » est une remarque précise. Une ombre devient aussi un token (shadow.card), de même que la durée des transitions du jour 39 (motion.fast = 150ms). Tout ce qui se répète deux fois mérite un nom ; tout ce qui ne sert qu'une fois n'en mérite pas.

space.6 dans une échelle de pas de 4px vaut…

  1. 24px
  2. 6px
  3. 32px
Réponse

6 × 4 = 24px. L'indice compte les pas : la valeur se reconstitue sans documentation.

Pratique (30 min)

  1. Dans Penpot, onglet Tokens : créez vos jeux — couleurs sémantiques, espacements, tailles de texte, rayon, ombre.
  2. Créez deux thèmes (clair, sombre) avec les valeurs des jours 23 et 33 ; appliquez les tokens aux objets de la maquette du jour 34 à la place des couleurs de la bibliothèque.
  3. Basculez le thème : tout l'écran doit passer en sombre sans retouche.
  4. Exportez les tokens en JSON et collez-les au carnet : c'est la spécification de votre design.

Critère de réussite : la maquette ne contient plus de valeur isolée, la bascule de thème fonctionne sans retouche, et le JSON exporté est au carnet.

Tips agent : « Transforme ce JSON de tokens en variables CSS (:root, thème sombre en [data-theme="sombre"]). Un nom de variable par token, aucune valeur modifiée. » Piège : il « corrigera » des valeurs au passage. Exigez : « ne change aucune valeur ». Preuve : diff entre son CSS et votre JSON — seuls les noms changent de format.

Synthèse (10 min)

Trois lignes : jeux, thèmes, export ; l'échelle en tokens ; la règle « deux fois = un nom ». Puis réécrivez votre échelle d'espacement en tokens sans notes.

Jour 37 — Design system 1/2 : atomes et molécules

Objectif : découper une interface en système de composants réutilisables.

Théorie 1/2 : l'atomic design

Brad Frost a publié en 2013 la métaphore restée canonique : une interface se compose comme la matière. Les atomes : bouton, label, champ, icône — indivisibles. Les molécules : un champ + son label + son message d'erreur = un « champ de formulaire » complet. Les organismes : l'en-tête, la carte produit, le formulaire entier. Puis les gabarits (templates, la page sans son contenu réel) et les pages. La métaphore n'est pas un dogme — beaucoup d'équipes s'arrêtent à trois niveaux — mais elle impose la bonne question : à quel niveau de réutilisation se situe ce que je dessine ? Un design system est ce découpage, appliqué et documenté : les tokens (jour 35), les composants (jour 17) et leurs règles d'emploi.

Un « champ de recherche » (label + champ + bouton) est…

  1. un atome
  2. une molécule
  3. une page
Réponse

Une molécule : plusieurs atomes assemblés en une unité fonctionnelle. Le bouton seul est un atome ; la page de résultats, un organisme ou plus.

Théorie 2/2 : pourquoi systématiser

Le design system résout trois maux : l'incohérence (le jour 12 — même comportement, même aspect), la lenteur (on assemble au lieu de redessiner) et la divergence design/code (le composant porte le même nom des deux côtés). Les systèmes publics — DSFR, GOV.UK, Carbon d'IBM, Polaris de Shopify — montrent la structure cible : pour chaque composant, un nom, un usage (« quand l'utiliser / ne pas l'utiliser »), ses variantes, ses états, ses règles d'accessibilité. À votre échelle, le système tient sur une page Penpot : les tokens, les atomes et les molécules du projet, posés et nommés. Le piège symétrique : systématiser trop tôt. On ne factorise qu'après deux usages réels — un système écrit avant le besoin fige de mauvaises hypothèses.

On transforme un dessin en composant du système…

  1. dès qu'il est joli
  2. avant de commencer les écrans
  3. quand il a servi deux fois
Réponse

Après deux usages réels : avant, on ne sait pas encore ce qui varie. Factoriser trop tôt fige de mauvaises hypothèses.

Pratique (30 min)

  1. Listez tous les éléments de vos maquettes des modules 2-3 et classez-les : atome, molécule, organisme.
  2. Ne retenez comme composants que ceux utilisés (ou prévus) deux fois. Les autres restent des dessins.
  3. Dans Penpot, créez la page « Système » : tokens rappelés en haut, puis les composants posés en grille, nommés par rôle.
  4. Pour chaque composant, notez au carnet : nom, usage (« sert à…, ne sert pas à… »), états.

Critère de réussite : la page Système contient vos composants factorisés (rien d'orphan), chacun nommé avec usage et états au carnet.

Tips agent : « Voici les écrans de mon projet [décrire]. Liste les composants récurrents, classe-les en atomes/molécules/organismes, et propose un nom de rôle pour chacun. » Piège : il factorisera tout, même l'unique. Exigez : « ne liste que ce qui apparaît deux fois ». Preuve : chaque composant de sa liste cite les deux endroits où il sert.

Synthèse (10 min)

Trois lignes : les cinq niveaux, les trois maux résolus, la règle des deux usages. Puis redessinez la classification de vos composants sans notes.

Jour 38 — Design system 2/2 : documenter un composant

Objectif : rédiger la fiche complète d'un composant, celle qu'un développeur peut suivre seul.

Théorie 1/2 : la fiche minimale

Un composant non documenté est un composant qui sera mal utilisé. La fiche minimale tient en six rubriques : le nom (le même en design et en code) ; l'usage — quand l'utiliser, et surtout quand ne pas l'utiliser (« bouton secondaire : jamais pour l'action principale de la page ») ; les variantes (primaire/secondaire/danger, tailles) ; les états (repos, survol, focus, actif, désactivé — jour 13) ; les règles d'accessibilité (contraste du couple, taille de cible, libellé obligatoire ou icône avec nom accessible) ; et les tokens utilisés (bouton.fond = color.accent…). Les grandes documentations ajoutent des exemples « à faire / à ne pas faire » : c'est la rubrique la plus lue, écrivez-la tôt.

La rubrique la plus utile d'une fiche de composant est…

  1. quand l'utiliser et quand ne pas l'utiliser
  2. l'historique de ses versions
  3. le nom de son auteur
Réponse

L'usage et ses limites : c'est ce qui empêche le composant d'être détourné. Le reste décrit, celle-là décide.

Théorie 2/2 : documenter pour quelqu'un qui n'était pas là

Le test d'une bonne fiche : quelqu'un qui découvre le projet peut assembler un écran correct sans vous poser de question. Cela impose trois disciplines : tout montrer (chaque variante et chaque état dessiné, pas décrit de mémoire), tout mesurer (les valeurs viennent des tokens, jamais « environ »), et écrire les règles implicites — l'ordre des boutons (primaire à droite en français courant), l'espacement entre boutons (space.2), le comportement quand le libellé est long. Ce qui n'est pas écrit sera improvisé ; ce qui est improvisé divergera. La fiche n'est pas de la bureaucratie : c'est la mémoire du projet, y compris pour vous dans trois mois.

« Le bouton fait environ 40px de haut » est une mauvaise ligne de fiche parce que…

  1. 40px c'est trop
  2. la valeur doit référencer un token exact, pas une approximation
  3. il faut parler en rem uniquement
Réponse

« Environ » invite à l'à-peu-près : la fiche cite le token (size.touch = 2.5rem), qui porte la valeur en un seul endroit.

Pratique (30 min)

  1. Choisissez votre bouton principal. Dans le carnet (ou une page Penpot), rédigez sa fiche complète aux six rubriques.
  2. Dessinez dans la fiche ses variantes et ses cinq états, chacun avec les tokens concernés.
  3. Écrivez la rubrique « à faire / à ne pas faire » : deux exemples de chaque, tirés de vos propres maquettes.
  4. Test du lecteur : relisez la fiche en oubliant que vous l'avez écrite — chaque question qu'elle laisse est une ligne à ajouter.

Critère de réussite : une fiche à six rubriques, variantes et états dessinés, zéro « environ », et la rubrique faire/ne pas faire remplie.

Tips agent : « Relis cette fiche de composant comme un développeur qui n'a jamais vu le projet. Liste les questions qu'elle laisse sans réponse. » C'est un des meilleurs usages du LLM : le lecteur naïf infatigable. Piège : il posera des questions philosophiques. Exigez : « uniquement les questions qui empêchent de coder le composant ». Preuve : chaque question se traduit par une ligne ajoutée à la fiche.

Synthèse (10 min)

Trois lignes : les six rubriques, le test du lecteur, pourquoi les tokens remplacent les « environ ». Puis récitez les six rubriques sans notes.

Jour 39 — Les micro-interactions

Objectif : spécifier les petites animations qui informent, sans jamais décorer au détriment de l'usage.

Théorie 1/2 : quatre temps, trois durées

Dan Saffer a décrit la micro-interaction en quatre parties : le déclencheur (clic, survol, donnée arrivée), les règles (ce qui change), le retour (ce que voit l'utilisateur) et les boucles et modes (ce qui se passe à la répétition). Leur rôle est fonctionnel : confirmer que l'action a été prise (le bouton qui s'enfonce), montrer la relation entre deux états (le menu qui glisse depuis le bord dit d'où il vient), ou adoucir une attente (le squelette de chargement). Dosages éprouvés : 100-200ms pour un retour immédiat (survol, pression), 200-300ms pour un changement d'état (ouverture), au-delà de 500ms l'interface paraît lente ; sortie plus rapide qu'entrée, et accélération naturelle (ease-out pour ce qui entre, ease-in pour ce qui sort).

La bonne durée pour le retour visuel d'un survol de bouton est…

  1. 800ms pour qu'on le remarque
  2. 0ms, toute animation est inutile
  3. 100-200ms
Réponse

100-200ms : perçu comme instantané mais lisible. Au-delà de 300-500ms, l'interface paraît lente.

Théorie 2/2 : le mouvement n'est pas gratuit

Le mouvement peut gêner sérieusement : troubles vestibulaires (nausées face aux parallaxes et grandes translations), difficultés d'attention, épilepsie photosensible (rien ne doit clignoter plus de trois fois par seconde — critère 2.3.1). La préférence système prefers-reduced-motion permet à l'utilisateur de demander le calme : le design la respecte en prévoyant la version réduite (fondus simples à la place des translations). Deux règles de bon sens complètent : n'animez jamais ce que l'utilisateur doit lire ou viser pendant le mouvement, et toute animation qui se répète (chargement) doit pouvoir s'arrêter ou s'expliquer. La micro-interaction réussie est celle qu'on ne remarque pas — elle se retire quand on la supprime : si rien ne manque, elle était décorative.

prefers-reduced-motion est…

  1. une préférence système que le design doit respecter en remplaçant les translations par des fondus
  2. un réglage de performance du navigateur
  3. une norme de batterie
Réponse

L'utilisateur demande le calme (troubles vestibulaires, attention) : on remplace les grands mouvements par des fondus, on ne supprime pas l'information.

Pratique (30 min)

  1. Analyse du jour : sur un site soigné, repérez trois micro-interactions (survol de bouton, ouverture de menu, chargement). Pour chacune, chronométrez à l'œil : immédiate, rapide, lente ? Que dit-elle ?
  2. Micro-exercice : spécifiez au carnet les trois micro-interactions de votre projet : déclencheur, règle, retour, durée, courbe, version reduced-motion.
  3. Dans Penpot, annotez les composants concernés : « survol : fond accent-foncé, 150ms, ease-out ».

Critère de réussite : trois spécifications complètes (quatre temps + durée + courbe + version réduite), posées en annotation sur la maquette.

Tips agent : « Spécifie la micro-interaction d'ouverture d'un menu mobile : quatre temps de Saffer, durée, courbe, version prefers-reduced-motion. » Piège : il proposera des durées « snappy 300ms » pour tout. Exigez la justification de chaque durée. Preuve : chaque valeur tient dans les fourchettes du cours, sinon elle est justifiée par l'usage.

Synthèse (10 min)

Trois lignes : les quatre temps, les fourchettes de durée, les deux règles de respect. Puis respécifiez une micro-interaction sans notes.

Jour 40 — Le prototype cliquable

Objectif : relier vos écrans en un prototype navigable, partageable par un lien.

Théorie 1/2 : ce qu'un prototype prouve

Le prototype est la maquette mise en mouvement : on clique, on navigue, on découvre ce que les images séparées cachaient — l'écran introuvable, l'action sans retour, l'enchaînement absurde. Dans Penpot, l'onglet Prototype relie les boards : sélectionnez un élément (le bouton), tirez le lien vers le board cible, choisissez le déclencheur (clic) et l'action (naviguer, ouvrir en superposition). Les flows nomment les parcours (inscription, achat) avec chacun son point de départ. Le mode présentation (View mode) joue le prototype, et un lien de partage le rend testable par n'importe qui, sans compte. La règle de fidélité : le prototype prouve les enchaînements et les retours, pas les effets — inutile d'animer tant que le parcours n'est pas bon.

Un prototype sert d'abord à vérifier…

  1. les animations
  2. les enchaînements d'écrans et les retours possibles
  3. les couleurs
Réponse

La navigation : chaque action mène quelque part, chaque écran permet de revenir. Les images fixes ne le montrent pas.

Théorie 2/2 : dessiner les chemins de traverse

Le parcours heureux (happy path) est le tiers du travail. Un prototype complet couvre aussi : le retour (chaque écran secondaire dit comment on en sort), les états vides (la liste sans élément, la recherche sans résultat), les erreurs (le formulaire refusé, la page introuvable) et le début (première visite, sans donnée). Compter les écrans est un bon réflexe : une petite application tient en 4 à 8 boards — au-delà, c'est le périmètre qu'il faut réduire, pas le prototype qu'il faut allonger. Chaque lien du prototype est une promesse : un bouton sans destination est une faute de conception, pas un détail.

Outre le parcours heureux, un prototype complet couvre…

  1. uniquement la page d'accueil
  2. les animations de transition
  3. retours, états vides, erreurs, première visite
Réponse

Les chemins de traverse : c'est là que les utilisateurs se perdent, et que les maquettes statiques sont muettes.

Pratique (30 min)

  1. Dans Penpot, assemblez trois écrans de votre projet (par exemple : liste → détail → formulaire) en boards séparés.
  2. Reliez-les en Prototype : chaque bouton mène quelque part, chaque écran secondaire a son retour. Nommez le flow.
  3. Ajoutez un état vide (la liste sans élément) et reliez-y le chemin qui y mène.
  4. Testez en View mode : parcourez le flow en entier, puis essayez de vous perdre. Créez le lien de partage.

Critère de réussite : un prototype jouable de bout en bout sans impasse, avec un état vide, et un lien de partage généré.

Tips agent : « Voici mes écrans et leurs actions : [liste]. Construis le graphe de navigation et signale toute impasse (écran sans sortie) ou promesse non tenue (bouton sans destination). » Piège : il supposera des liens « évidents ». Exigez : « ne liste que les liens que j'ai déclarés ». Preuve : chaque impasse signalée existe dans le prototype.

Synthèse (10 min)

Trois lignes : ce que le prototype prouve, les chemins de traverse, la règle du bouton-destination. Puis redessinez votre graphe d'écrans sans notes.

Jour 41 — Faire tester son prototype

Objectif : recueillir un avis utile sur votre prototype, sans induire les réponses.

Théorie 1/2 : demander n'est pas tester

« Tu aimes ? » produit de la politesse, pas de l'information. Le test utile met l'utilisateur en situation : donnez une tâche (« retrouve le tarif annuel », « inscris-toi à la lettre »), puis taisez-vous et observez — la méthode dite de la « pensée à voix haute » : la personne commente ce qu'elle fait et cherche. Ne défendez pas votre design, n'expliquez pas : chaque explication donnée est une faute d'interface découverte. Jakob Nielsen a montré que cinq testeurs suffisent à révéler l'essentiel des problèmes d'un parcours simple ; un seul, mené honnêtement, en révèle déjà plus que dix avis de salon. Le test des cinq secondes complète : montrer l'écran cinq secondes, le cacher, demander « que propose cette page ? » — c'est le squint test du jour 10 avec des yeux neufs.

La première règle d'un test utilisateur est…

  1. expliquer le design avant de lancer
  2. donner une tâche, se taire, observer
  3. demander « tu aimes les couleurs ? »
Réponse

On observe un comportement, on ne recueille pas un avis. Toute explication donnée est une faute découverte.

Théorie 2/2 : trier ce qu'on entend

Les retours se trient en trois paniers : le comportement observé (elle n'a pas trouvé le bouton — fait, il pèse lourd), la suggestion de solution (« tu devrais le mettre en rouge » — le problème est réel, la solution est la vôtre à trouver : pourquoi n'a-t-elle pas vu le bouton ?), et le goût (« je préfère le vert » — notez, n'agissez pas). Un problème vu une fois est une piste ; vu deux fois, c'est un chantier. Consignez chaque test au carnet au format du jour 14 : constat, règle, proposition. Et gardez le réflexe inverse : ce que le testeur a réussi sans hésiter est une force à préserver dans l'itération — une refonte qui casse ce qui marchait est une régression, pas un progrès.

Une testeuse dit : « ton bouton devrait être rouge ». Le bon réflexe est…

  1. chercher le problème derrière la suggestion (elle n'a pas vu le bouton ?) et concevoir sa propre solution
  2. le passer en rouge
  3. ignorer le retour
Réponse

La suggestion signale un problème réel (visibilité), mais la solution vous appartient : contraste, place, libellé — pas forcément le rouge.

Pratique (30 min)

  1. Préparez le test : deux tâches écrites, le lien de partage du prototype du jour 40, le carnet ouvert.
  2. Faites tester par une personne réelle (proche, collègue) : consigne minimale, silence, observation. Notez chaque hésitation.
  3. Si personne n'est disponible : test des cinq secondes sur vous-même après une pause, puis relecture du prototype à tête reposée.
  4. Triez les retours en trois paniers et rédigez au moins deux constats au format problème + règle + proposition.

Critère de réussite : un test mené (réel de préférence), retours triés, deux constats actionnables au carnet.

Tips agent : « Joue un utilisateur novice : voici mes écrans décrits […]. Pour la tâche "retrouve le tarif", dis à voix haute où tu cliques et ce qui te fait hésiter. » Piège : un LLM ne se trompe jamais vraiment — il simule la confusion. Preuve : ses hésitations doivent citer un élément précis (libellé, place) que vous pouvez vérifier ; elles préparent le vrai test, elles ne le remplacent pas.

Synthèse (10 min)

Trois lignes : tâche + silence + observation, les trois paniers, ce qu'on préserve. Puis réécrivez vos deux tâches de test sans notes.

Jour 42 — Bilan du module 3 : une petite application

Objectif : assembler tout le module : une mini-application prototypée, en clair et en sombre, documentée.

Théorie 1/2 : le livrable complet d'un designer

Ce que vous produisez aujourd'hui est ce qu'une équipe attend d'un designer produit : les écrans (mobile + desktop), les tokens (nommés, thèmes clair et sombre), les composants (factorisés, fiche pour le principal), le prototype (flows complets, états vides et erreurs) et la preuve (contrastes mesurés, protocole de test du jour 32 passé). Rien de ce qui a été fait depuis le jour 29 n'est jetable : chaque brique du module est une section du livrable. L'ordre de travail est celui du module : structure (responsive), valeurs (tokens et thèmes), pièces (composants), mouvement (prototype), preuve (tests).

Théorie 2/2 : choisir un périmètre tenable

Le sujet du jour : une petite application de liste — les courses, les lectures, les tâches ménagères. Quatre écrans suffisent : la liste (avec son état vide), l'ajout (formulaire du jour 26), le détail ou l'édition, et un réglage simple (bascule de thème, par exemple). Le piège du bilan est l'ambition : chaque écran ajouté doit passer par tous les filtres (deux thèmes, deux largeurs, états). Quatre écrans complets valent mieux que huit écrans esquissés — c'est la règle d'or du parcours appliquée au design : la régularité et la finition priment sur la quantité.

Pour le bilan, le bon périmètre est…

  1. huit écrans esquissés
  2. quatre écrans complets : deux thèmes, deux largeurs, états vides et erreurs
  3. un seul écran parfait
Réponse

Quatre écrans complets : le prototype doit montrer un parcours, et chaque écran passe tous les filtres. L'esquisse ne prouve rien.

Pratique (30 min)

  1. Esquissez les quatre écrans en wireframe rapide (10 minutes maximum — le dessin est déjà acquis).
  2. Construisez les écrans dans Penpot avec vos tokens et composants existants ; créez ce qui manque (la ligne de liste) en composant.
  3. Reliez le tout en prototype : flow d'ajout complet, état vide au départ, retours partout.
  4. Basculez en thème sombre, passez le protocole de test du jour 32 (au moins les étapes 2, 4, 5, 8) et notez le résultat.

Critère de réussite : quatre écrans, deux thèmes, un prototype sans impasse, et le protocole passé avec ses lignes au carnet.

Tips agent : « Voici mon livrable : [inventaire écrans/tokens/composants/flows]. Joue le chef de projet : que manque-t-il pour le donner à un développeur ? » Piège : il réclamera l'exhaustivité (fiches pour tout). Preuve : chaque manque signalé correspond à une vraie question que le développeur se poserait.

Synthèse (10 min)

Trois lignes : les cinq sections du livrable, l'ordre de travail, la règle du périmètre. Puis récitez le livrable sans notes — le module 4 vous le fera produire une seconde fois, en grand.

Utile ? Dites-nous ce qu'il faut mesurer ensuite.

Commentaires

Ni compte ni traceur : un commentaire est lu par un humain avant d'apparaître.