UI
Define the user outcome, interaction states, design constraints, and accessibility requirements.
Purpose
Define the user outcome, interaction states, design constraints, and accessibility requirements.
Recommended
- Cover loading, empty, error, success, responsive, keyboard, and focus states.
- Reuse the established design system and interaction patterns.
- Validate both visual presentation and interaction behavior.
Avoid
- Treating the happy-path screenshot as complete UI behavior.
- Deferring accessibility checks until after implementation.
Prompt skeleton
Prompt skeleton — deterministic, no model call
User outcome [Describe the experience and primary flow.] States [Cover loading, empty, error, success, and responsive states.] Accessibility and design constraints [Include keyboard, contrast, labels, and existing-system requirements.] Validation [Name visual and interaction checks.]
From templates/ui.md. Placeholders describe what to fill in; nothing here invents project facts.
Evidence
official
- officialAccessibility should be addressed throughout planning, implementation, and evaluation rather than deferred until the end.
Planning and Policies Overview ↗