Create a UI/UX design specification for [PRODUCT OR FEATURE]. The primary user is [PRIMARY USER], trying to complete [CORE JOB] in the context described by [CONTEXT AND CONSTRAINTS]. The platform, brand constraints, and existing patterns are [PLATFORM AND DESIGN SYSTEM]. Success will be measured by [SUCCESS METRICS]. Ask up to 3 clarifying questions only if a required input is missing. Do not invent research findings, accessibility compliance, legal requirements, integrations, or technical capabilities. Mark assumptions clearly. Return a design brief with these sections: 1. User and job: primary user, triggering moment, desired outcome, current friction, and one non-goal. 2. Task flow: a numbered happy path from entry to completion, plus the decision points where the user can fail, abandon, or need help. 3. Screen-by-screen specification for the minimum viable flow. For each screen, name the hierarchy, required content, primary action, secondary action, validation, loading, empty, error, and success states. Specify what changes after each action. 4. Content design: labels, button text, helper copy, confirmation text, and error messages. Use familiar terms the stated user would recognize; errors must say what happened and how to recover. 5. Accessibility and interaction requirements: keyboard path, visible focus, semantic control type, contrast or non-color cue needs, touch target considerations, and reduced-motion behavior where relevant. 6. Test plan: five usability-test tasks and the observable evidence that would show the design works. Prioritize the user’s next decision over visual decoration. Avoid ambiguous controls, placeholder-only labels, destructive actions without confirmation, and a success state that leaves the user unsure what happens next. Before answering, self-check that every screen advances the core job and that every form field has a purpose, format rule, and recovery path.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT OR FEATURE] | Describe the product area or feature you need designed. | A self-service appointment rescheduling flow for a dental practice portal. |
| [PRIMARY USER] | Describe the main user, their experience level, and relevant needs. | Existing patients using a phone, often in a hurry and unfamiliar with the portal. |
| [CORE JOB] | State the concrete task the user is trying to complete. | Move an appointment without calling the office and receive a clear confirmation. |
| [CONTEXT AND CONSTRAINTS] | Provide user context, business constraints, edge cases, and known research or requirements. | Appointments can be moved only within 60 days; some procedures require staff approval; office hours and provider availability are known. |
| [PLATFORM AND DESIGN SYSTEM] | State the platform and any existing components, visual rules, or technical limits. | Responsive web app using the existing button, form, alert, and calendar components. |
| [SUCCESS METRICS] | List measurable outcomes such as completion rate, time to complete, or error rate. | At least 80% completion without support and fewer than 5% invalid-slot errors. |
How to use
- Fill in the user, task, constraints, platform, and measurable outcome before pasting the prompt.
- Turn the screen specification into a flow diagram or wireframes, including the error and empty states.
- Test the five tasks with representative users and record where they hesitate or misread a label.
- Follow up with: “Create a mobile wireframe outline for each screen using only our existing components.”
Variations
UX audit
Use this when an existing flow has poor completion or support volume.
Audit the [EXISTING FLOW] for [PRIMARY USER] trying to [CORE TASK]. Use [EVIDENCE] such as recordings, support tickets, analytics, or screenshots. Produce a prioritized issue list with severity, user impact, likely cause, evidence, and a specific design change. Include accessibility and error-recovery findings. Do not infer user behavior beyond the evidence; mark hypotheses. Ask up to 3 questions only if necessary, then propose five validation tasks for the highest-risk changes.
Design handoff
Use this when wireframes need precise implementation requirements.
Convert these [WIREFRAMES OR SCREEN NOTES] into a product and engineering handoff for [PLATFORM]. Include each screen’s components, content, interaction rules, field validation, empty/loading/error/success states, responsive behavior, analytics events, and accessibility acceptance criteria. Use [DESIGN SYSTEM RULES] and [TECHNICAL CONSTRAINTS]. Do not invent APIs or component capabilities. Ask up to 3 questions for missing inputs, and flag unresolved product decisions separately.
Usability test plan
Use this before testing a prototype with target users.
Create a usability-test plan for [PROTOTYPE OR FLOW] with [PRIMARY USER] and the goal of evaluating [RESEARCH QUESTIONS]. Use [CONTEXT] to write a neutral facilitator script, 5 realistic task scenarios, follow-up questions, observation fields, and clear success criteria. Avoid leading questions and do not claim statistical validity from a small sample. Ask up to 3 questions only if a required input is missing; flag assumptions about user behavior.
Tips
- Design the empty, loading, validation, and recovery states before polishing the happy path; they are where users most often lose confidence.
- A button label should name the result, such as “Confirm new appointment,” not a vague action such as “Continue.”
- Separate a user need from a business preference: “make an appointment” is a task, while “increase portal adoption” is a business outcome.
- Test the smallest realistic flow with users who match the stated context, including device and accessibility needs.
FAQ
Can AI create a complete UI design?
It can produce a strong brief, flow, copy, and state inventory. You still need product evidence, visual design decisions, and usability testing.
What should I provide if I have no user research?
State what you know, label it as an assumption, and ask for a research plan rather than pretending the assumptions are findings.
Why include error states in the prompt?
A flow that only specifies success leaves teams to improvise when data is missing, a slot disappears, or a request fails.