Help me design or improve a UI for [PRODUCT OR FEATURE]. The primary user is [PRIMARY USER], who needs to complete [CORE TASK] in the context of [USER CONTEXT]. The current problem or constraint is [CURRENT PROBLEM]. The platform and technical constraints are [PLATFORM AND CONSTRAINTS]. First, state the user goal, the success moment, and the one primary action this screen must make easy. Do not treat every request as equally important. Then produce: 1. A concise screen brief: purpose, entry point, exit or next step, and information the user needs before acting.
2. A content hierarchy from most to least important, including recommended labels, button text, empty-state copy, error messages, and confirmation feedback. Use plain, specific language; avoid vague labels such as “Submit” or “Continue” when the action can be named. 3. A component-level layout description for desktop and mobile, including what appears above the fold and what can be progressively disclosed. 4. Required states: default, loading, empty, validation error, system error, permission-denied if relevant, success, and a long-content or small-screen behavior. 5. Accessibility requirements covering keyboard order, visible focus, semantic control choice, form labels, error association, color contrast, and non-color status cues. 6. Acceptance criteria written as observable “Given / When / Then” checks, plus 5 usability test tasks and the signal each task should reveal. Make assumptions only when they are low-risk and label them. Ask up to 3 clarifying questions only if a required input is missing. Before answering, check that every element supports the core task and flag any requirement that conflicts with the stated platform or constraints. Do not invent user research, analytics, legal requirements, or technical capabilities.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT OR FEATURE] | Name the product area or feature you want to design or improve. | Self-serve invoice payment screen for a small-business accounting app |
| [PRIMARY USER] | Describe the main user and any relevant experience level or role. | A freelance designer who sends 5 to 15 invoices a month and is not an accounting specialist |
| [CORE TASK] | State the outcome the user needs to achieve in this UI. | Confirm a client payment and reconcile it to the correct invoice |
| [USER CONTEXT] | Explain when, where, and under what pressure or conditions the user performs the task. | Usually on a laptop after receiving a bank notification, often while handling several client tasks |
| [CURRENT PROBLEM] | Describe the current UI issue, known friction, or business constraint. | Users cannot tell whether a payment has already been matched and accidentally create duplicate records |
| [PLATFORM AND CONSTRAINTS] | List the device, existing design system, technical limits, and non-negotiable requirements. | Responsive web app, existing table and form components, WCAG AA target, no bank-data changes allowed |
How to use
- Replace each bracketed input with details from the ticket, user notes, and existing product.
- Paste the full prompt into your AI tool and keep the output as a working UI brief, not a finished visual design.
- Check that every required state has a user action or clear recovery path, especially errors and empty states.
- Follow up with: “Turn the acceptance criteria into a prioritized backlog with dependencies and open questions.”
Variations
UI critique
Use this when you already have a screen and need a structured redesign review.
Review this UI for [USER TYPE] trying to [TASK]: [SCREEN DESCRIPTION OR SCREENSHOT NOTES]. The context is [CONTEXT], and the known complaint is [COMPLAINT]. Identify the three highest-impact usability problems using task flow, hierarchy, wording, feedback, accessibility, and error recovery. For each, give evidence from the screen, a concrete change, and a way to test it. Separate critical blockers from polish. Do not infer research findings that I have not supplied. Ask up to 3 questions only if a missing detail changes the recommendation.
Design handoff
Use this when a designer needs a clear build specification for engineering.
Create an engineering-ready UI handoff for [FEATURE] on [PLATFORM]. The user must [PRIMARY TASK], and these components already exist: [DESIGN SYSTEM COMPONENTS]. Describe layout regions, component variants, interaction rules, validation, loading, empty, error, success, responsive behavior, keyboard behavior, and analytics events. Write acceptance criteria in Given/When/Then form. Flag anything that needs design or product decisions rather than inventing it. Ask up to 3 clarifying questions only when a required input is absent.
Usability test plan
Use this when you need to validate a UI concept before development.
Create a moderated usability test plan for [PROTOTYPE OR FEATURE] with [PARTICIPANT TYPE]. We need to learn whether people can [KEY OUTCOME] in [CONTEXT]. Provide a 30-minute agenda, neutral facilitator script, 5 realistic tasks, follow-up probes, success criteria, and a note-taking table. Include one task for an error or edge case. Avoid leading participants or claiming that a result proves causation. Ask up to 3 clarifying questions only if missing inputs prevent credible tasks.
Tips
- Start with one screen’s primary task; a page that tries to serve five goals usually produces vague hierarchy.
- Include the entry point and the next step because screen quality depends on what users know before arriving and what happens after acting.
- Specify failure states early; validation, unavailable data, and permission problems often expose missing product decisions.
- Use test tasks based on real situations, not feature names, so participants must interpret the interface rather than follow instructions.
FAQ
Can this prompt generate a polished UI mockup?
It produces a design brief and requirements first. Use that output as the source for a visual-generation or prototyping prompt.
What should I provide if I only have a rough idea?
Give the user, their goal, the context, and the platform. The AI can label low-risk assumptions and identify the decisions still needed.
Should I include accessibility in an early UI prompt?
Yes. Semantic controls, focus order, form errors, and responsive behavior affect the structure of the screen, not just final polish.