Exploration de Conception UI
Produisez une direction de conception utilisable pour la tâche indiquée. Inspectez les écrans, composants, tokens, densité, contenu et conventions d'interaction existants avant de générer des alternatives. Préservez l'identité du produit sauf si une refonte est demandée.
Utiliser des preuves de référence
Lorsque des références externes éclairent la tâche, utilisez design-reference-research si disponible ou inspectez directement les sources fournies/par défaut pertinentes. Considérez sa couverture de source, capturez les identifiants, observations et incertitudes. Ne refaites pas une recherche déjà effectuée et ne traitez pas un mood board non inspecté comme une preuve. La disponibilité d'une référence ne rend pas la recherche obligatoire pour une petite tâche déjà ancrée dans le produit.
Traduisez les principes utiles en alternatives originales en utilisant l'identité existante du produit. Expliquez comment chaque choix conséquent suit la tâche utilisateur et les preuves. Résolvez les schémas conflictuels par plateforme, tâche et contraintes ; ne mélangez pas des systèmes de navigation incompatibles et ne copiez pas la marque d'un autre produit. Faites avancer les états d'interaction inconnus comme des questions à vérifier, plutôt que d'inventer silencieusement un comportement observé.
Cadrer les alternatives
Clarifiez uniquement les choix qui modifient matériellement le résultat. Identifiez la tâche utilisateur, la hiérarchie du contenu, les états applicables, les contraintes d'accessibilité et les surfaces cibles. Faites en sorte que les alternatives diffèrent par une structure ou une interaction conséquente, et pas seulement par la couleur. Utilisez un nombre proportionné à la demande ; ne générez pas toujours trois alternatives et n'exigez pas d'agents parallèles.
Gardez les artefacts d'exploration séparés du code de production, sauf si l'implémentation est déjà demandée. Utilisez des données réalistes, des libellés longs, des états vides/erreur et des mises en page réactives là où ils changent le choix. Montrez ce que chaque alternative améliore et ce qu'elle coûte. Une seule capture d'écran ne spécifie pas le focus, la navigation ou la persistance.
Utiliser les capacités de conception disponibles
Utilisez les composants natifs du dépôt et les outils de prévisualisation/conception disponibles. Un livrable utilisable peut être du HTML local, un canevas de conception existant ou un visuel annoté ; il ne doit pas dépendre d'un fournisseur hébergé. N'affirmez pas qu'une conception a été rendue ou testée sans cette preuve.
Pour une intégration Superdesign explicitement configurée, lisez hosted-design.md. Le flux de travail doit toujours fonctionner lorsque ce service est indisponible. Ne téléchargez pas la dernière CLI, ne créez pas de compte et ne téléchargez pas de source comme condition préalable implicite au travail de conception.
Remettre une direction
Comparez les alternatives par rapport à la tâche et aux contraintes. Si l'utilisateur demande une sélection, présentez les alternatives réelles pour cette décision. S'il vous autorise à choisir, recommandez et procédez avec des raisons plutôt que d'introduire une autre étape d'approbation.
Fournissez l'artefact sélectionné, les tokens/composants réutilisés, les règles de mise en page, les modifications réactives, le comportement d'interaction/focus, les états significatifs, les actifs et les décisions non résolues. Liez les critères d'acceptation et les écarts intentionnels aux identifiants de preuve de référence si disponibles ; une alternative non sélectionnée n'est pas une exigence d'implémentation. Distinguez une conception sélectionnée d'une implémentation fonctionnelle. Acheminez l'implémentation autorisée vers frontend-ui-engineering et la critique vers plan-design-review si disponibles, sans exiger que l'un ou l'autre soit installé.
Lisez provenance.md pour la source du flux de travail en amont et l'avis.