Figer un état des composants d’une interface

Définir la frontière de l’instantané

Décidez si vous figez une bibliothèque entière ou seulement les composants nécessaires à une livraison. Indiquez les écrans concernés et le niveau de maturité attendu. Une liste courte et complète pour un parcours vaut mieux qu’un périmètre implicite.

Attribuez un identifiant à chaque composant et à ses variantes utiles. Utilisez des termes compréhensibles par l’équipe : bouton principal, champ en erreur, carte sélectionnée. Documentez les conventions locales sans les présenter comme une norme universelle.

Capturer des états comparables

Présentez les états dans un contexte stable avec les libellés utilisés au moment du choix. Indiquez les dimensions ou les conditions de présentation nécessaires à la comparaison, en distinguant les valeurs confirmées des valeurs simplement illustratives.

Ajoutez les comportements qui ne se lisent pas sur une image : déclencheur, retour attendu, passage à un autre état. Signalez les interactions non définies. Un aperçu visuel seul ne décrit pas le fonctionnement complet d’un composant.

Relier règles et décisions

Rassemblez les notes qui expliquent les choix de contenu, d’espacement et de hiérarchie. Si une règle commune change, listez les composants concernés. Cela permettra de retrouver l’état antérieur sans supposer qu’il est encore recommandé pour les nouvelles pages.

Associez les commentaires de revue à la référence de l’instantané. Classez les points acceptés, à corriger ou à arbitrer. Une capture conservée ne vaut pas validation globale de l’interface ni vérification de son accessibilité en situation réelle.

Préserver la reprise du travail

Gardez une copie des fichiers exportés et, selon votre organisation, les sources nécessaires à leur compréhension. N’écrasez pas cet état lorsque vous poursuivez la bibliothèque. Créez un nouvel indice pour la prochaine sélection de référence.

Au moment du handoff, joignez une courte note des écarts entre l’instantané et le travail courant. Le développeur peut ainsi poser ses questions sur une base connue au lieu d’essayer de déduire les changements dans un document mouvant.

Exemple fictif : instantané Aster r05

Exemple fictif à adapter à votre projet.

Composant Aster	État inclus	Décision de revue
Bouton principal	Repos et indisponible	Libellés acceptés
Champ adresse	Vide et erreur	Message à préciser
Carte produit	Standard et sélectionnée	Parcours concerné identifié

Cas fictif : les décisions décrivent une revue de conception, pas un contrôle technique automatisé.

Avant de transmettre

• Délimiter les composants inclus.
• Nommer leurs états et variantes.
• Décrire les interactions invisibles.
• Relier les décisions à l’instantané.
• Conserver les écarts après la capture.

Questions pratiques

Une capture d’écran suffit-elle ?

Elle décrit un aspect visible. Ajoutez les états manquants, les règles et les interactions nécessaires pour comprendre ce que le composant doit faire.

Comment traiter un composant encore discuté ?

Incluez-le avec un statut explicite et la question à trancher, ou excluez-le en le signalant. Évitez qu’une présence dans l’instantané soit comprise comme une validation.

Pour poursuivre

Préparer la remise d’interface

Relier les retours à une référence

Conserver les états successifs

Cette méthode aide à identifier et conserver les pièces du projet. Elle ne remplace pas sa validation technique ni l’examen des droits et engagements applicables.