UI et produits numériques · Guide pratique
Documenter une revue de composants entre Figma et Storybook
Sélectionnez les composants du parcours concerné et donnez à chacun une ligne de revue.
Préparer les pièces et leurs relations
Notez la référence de maquette, le nom de la story, les paramètres d’état et le contexte du build observé. Capturez des données fictives stables. Une story montrant un état ne représente pas nécessairement tous les comportements du composant utilisé dans l’application.
Effectuer le contrôle ciblé
Comparez géométrie, contenu, états et interactions visibles sur un même environnement. Relevez les différences comme des observations localisées : espace, libellé ou transition. Faites distinguer un défaut accepté provisoirement d’une décision de design modifiée. Après correction, rattachez le nouveau résultat au build concerné et gardez le point initial afin de comprendre pourquoi la référence a changé.
Donner un contexte vérifiable à la revue
Délimitez les écrans et composants concernés par la remise, puis indiquez les contenus et environnements de comparaison. Gardez les décisions acceptées séparées des questions ouvertes. Une référence de design reste utile lorsqu’elle permet à l’équipe de reproduire un contrôle précis ; elle devient ambiguë si les données, les états ou le contexte changent sans être notés. Consignez ce périmètre dans la fiche jointe.
La revue est manuelle dans cette méthode. Elle ne crée aucune comparaison automatique entre outils ni audit complet de l’application. Les tests et l’accessibilité du composant nécessitent leurs contrôles propres.
| Pièce ou zone fictive | Rôle dans le dossier | Contrôle à effectuer |
|---|---|---|
| Button/Primary | Story fictive état repos | Maquette UI-r09 |
| Field/Error | Story fictive erreur | Message et contour |
| Card/Selected | Story fictive sélection | Données de démonstration |
EXEMPLE FICTIF
Cas fictif : Button/Primary
L’équipe fictive Luma voit un message d’erreur différent dans la maquette et dans Storybook. Elle fait arbitrer le libellé, note le build corrigé et recapture la story avec le même contenu fictif.
- Créer une fiche de contrôle pour Button/Primary en conservant l’état de référence.
- Examiner Field/Error selon le contrôle indiqué, puis noter l’écart et la prochaine action.
- Rattacher Card/Selected à l’inventaire retenu et demander le retour précis du destinataire.
Avant de poursuivre
- Identifier Button/Primary et sa version sans écraser la référence précédente.
- Contrôler Field/Error selon la consigne notée dans le registre.
- Relier Card/Selected à l’usage et au destinataire prévus.
- Marquer les points ouverts et la personne chargée de les résoudre.
- Conserver le résultat observé et les limites du contrôle effectué.
Les questions utiles
Une capture Storybook remplace-t-elle une recette ?
Elle documente le contexte observé. Vérifiez aussi les interactions et l’utilisation dans le produit ; une story isolée ne couvre pas tout le parcours.