ist-h-i/ui-ux-design

UI/UX Design Harness

Objectif

Contraindre la conception, l'implémentation et la revue de l'interface utilisateur autour de l'objectif réel de l'utilisateur, de la hiérarchie visuelle et de la finition, de l'utilisabilité des tâches, de la sémantique d'interaction, de la conscience des conséquences et de l'état récupérable. Il s'agit d'un supplément d'exécution, et non d'un remplacement de cycle de vie ou d'un système de design visuel.

Utilisez le sous-ensemble applicable le plus petit. N'inventez pas de personas, de priorités métier, d'hypothèses sur les appareils, de garanties de récupération ou de comportement d'interaction que la tâche ne prouve pas.

Quand l'utiliser

Utilisez cette compétence uniquement après que le workflow de livraison générique a été sélectionné et que la tâche modifie ou révise une interface visible par l'utilisateur avec un ou plusieurs de ces signaux :

• un écran, un formulaire, un flux de navigation, une sélection ou une action principale ;
• les états focus, sélectionné, désactivé, chargement, succès, erreur, terminé, ou tout autre état d'interaction ;
• des actions utilisateur conséquentes ou réversibles ;
• un échec partiel de données/rendu, des données obsolètes ou manquantes, une tentative de reprise, ou un comportement de récupération ;
• un langage d'interface dont le libellé affecte l'achèvement de la tâche ou la récupération d'erreur.

Ne l'utilisez pas pour un travail non lié à l'interface, pour une sortie purement machine, ou comme prétexte pour charger toutes les préoccupations UX. La marque, les utilisateurs, la terminologie, les flux critiques et les règles métier spécifiques au projet restent du contexte de projet.

Processus

1. Ancrer aux preuves. Identifiez l'objectif connu de l'utilisateur, le contexte d'utilisation, la première information à remarquer, les priorités d'action, l'achèvement/l'action suivante et les contraintes. Choisissez la densité et la composition adaptées à cet objectif : un espace de travail comparatif et une introduction produit nécessitent des traitements différents. Les contrats existants sont des entrées, pas un plafond de qualité ; revisitez les faiblesses observées dans le périmètre. Arrêtez uniquement les décisions qui dépendent de faits manquants conséquents, sans inventer de persona ou de workflow.
2. Sélectionner les principes et schémas applicables. Lisez uniquement les sections pertinentes de references/principles.md, references/decision-patterns.md et references/anti-patterns.md. Notez pourquoi elles s'appliquent. Traitez les exemples comme des invites à prouver, pas comme des interdictions globales.
3. Rendre la composition concrète. Connectez le regroupement, l'ordre, la hiérarchie et le retour à la ligne du texte, les ancres d'alignement, l'espacement, l'imagerie et les relations entre contrôles à la tâche. Préférez une structure/état clair avant d'ajouter des explications ; conservez le sens requis et les étiquettes accessibles. Pour le japonais, évaluez les étiquettes, le libellé cible/résultat et les retours dans leur position et état affichés, pas seulement la grammaire ; utilisez une capacité japanese-expression disponible selon les règles de découverte ci-dessous.
4. Spécifier le comportement. Définissez les affordances/signifiants applicables, la sémantique des états, les retours immédiats, les transitions, le focus/l'état courant, la continuation et les chemins d'interaction équivalents. Marquez explicitement les préoccupations non applicables ; ne fabriquez pas de comportement de survol, de glissement, de geste ou de mouvement.
5. Séparer les classes de conséquences. Distinguez l'annulation avant engagement, l'annulation après un changement réversible effectué, et l'action compensatoire après un changement engagé. Pour les actions irréversibles ou matériellement conséquentes, montrez la cible, le périmètre, la conséquence et la limite de récupération avant l'engagement. N'ajoutez pas de confirmation systématique aux actions réversibles à faible risque.
6. Délimiter les échecs. Gardez les régions saines, autorisées, sémantiquement valides et les saisies utilisateur utilisables lorsqu'une région indépendante échoue. Gardez l'échec non résolu visible dans la région affectée, limitez la tentative de reprise et vérifiez son résultat. Distinguez les états de chargement, vide légitime, manquant, obsolète, partiel et complet. Ne remplissez pas par zéro les données manquantes et n'exposez pas d'actions dérivées dont la vérité préalable est incomplète. Élargissez le bloc uniquement lorsque l'autorisation, la sécurité, la cohérence ou la sémantique de dépendance l'exigent.
7. Affiner et vérifier le rendu réel. Pendant l'implémentation, inspectez un écran représentatif complet avant de peaufiner les contrôles, puis affinez les détails pertinents des composants, les mises en page étroites et les états avant une revue indépendante. Jugez la finition visuelle, l'utilisabilité de la tâche et le comportement fonctionnel séparément ; des clics fonctionnels, des valeurs CSS égales et l'absence de débordement ne constituent pas une finition. Testez les transitions applicables, le clavier/focus, l'annulation réelle, l'annulation pré-engagement, la saisie conservée et la tentative de reprise ciblée. Une capture d'écran appuie l'apparence statique, pas la récupération ou la restauration d'état. Utilisez les règles d'observation et de transfert dans references/ui-capability-contract.md.
8. Connecter les capacités UI disponibles. Suivez references/ui-capability-contract.md pour les requêtes contrat-uniquement, construction-sur-contrat-existant ou UI directe. Gardez la propriété des principes ici, résolvez les propriétaires de capacités externes à partir de l'environnement actif, et conservez les liens contrat-implémentation-preuve. Les lacunes de capacité ou d'exécution arrêtent uniquement le travail dépendant affecté et ne comptent jamais comme une revue terminée.
9. Restituer les contraintes au workflow sélectionné. requirement-grill, grill-design, controlled-implementation, test-first-verification, les portes de revue et les portes de fusion finale conservent leurs responsabilités. Ce supplément affine les décisions UI ; il n'autorise pas l'implémentation ou l'approbation par lui-même.

Sortie

Émettez un supplément délimité dans le registre de décision de la tâche en cours. Pour un ajustement local, enregistrez uniquement les décisions modifiées et les preuves affectées ; n'exigez pas un nouveau contrat JSON ou un modèle rempli. Omettez les champs non pertinents ou utilisez not_applicable: <reason> ; ne les remplissez jamais de manière spéculative.

UX supplement:
  user_context:
    user_goal:
    usage_context:
    known_constraints:
    capability_or_environment_considerations:
  task_model:
    page_or_flow_goal:
    primary_action:
    completion_state:
    next_action:
  information_model:
    required_information:
    secondary_information:
    omit:
    language_required_for_clarity:
  interaction_model:
    affordances_and_signifiers:
    state_semantics:
    action_feedback:
    transition_behavior:
    consistency_expectations:
    direct_manipulation:
    equivalent_interaction_paths:
  inclusion_constraints:
    single_cue_dependencies_to_avoid:
    error_prevention:
    recovery_paths:
    input_and_effort_constraints:
  resilience_and_consequences:
    action_reversibility_and_limits:
    pre_commit_consequences:
    failure_boundaries_and_dependencies:
    safe_remaining_content_and_actions:
    partial_failure_and_freshness_feedback:
    scoped_retry_and_recovery_refs:
    blocking_conditions:
  applicable_patterns:
  anti_patterns:
  implementation_constraints:
  verification_scenarios:
  stop_conditions:

Chaque scénario de vérification nomme l'état inspecté et la relation observable. Pour les interactions, ajoutez action/entrée, état visible et sous-jacent attendu, et résultat de récupération/continuation applicable. Gardez les décisions de conception dans le modèle d'information existant et les contraintes d'implémentation plutôt que de créer un autre schéma.

Critères de sortie

• Le supplément est connecté uniquement parce que les preuves actuelles contiennent un signal UI.
• Les hypothèses sur l'utilisateur, le produit, la marque et le métier sont sourcées ou marquées comme inconnues.
• La tâche principale et l'action suivante sont plus claires sans supprimer la sémantique requise.
• Pour les jugements UI rendus, la composition et la finition des composants ont des preuves rendues distinctes des vérifications fonctionnelles ; un travail uniquement sous contrat spécifie des critères d'observation sans revendiquer l'approbation de l'écran réel. Un contrat réussi n'écarte pas les imperfections observées.
• Les affirmations dynamiques ont des exigences de preuve interactives/d'état, pas seulement une preuve par capture d'écran.
• Les comportements réversible, irréversible, d'échec partiel et de blocage fondamental sont distingués lorsqu'ils sont applicables.
• L'état sain et la saisie utilisateur sont préservés à travers un échec indépendant et une tentative de reprise.
• Le workflow générique et l'autorité de validation finale restent inchangés.