Act as a senior UX designer helping me define a solution for [PRODUCT AND FEATURE]. The primary user is [PRIMARY USER], who is trying to [USER GOAL] in this context: [USER CONTEXT AND RESEARCH]. The product constraints are [CONSTRAINTS AND EXISTING SYSTEM]. Do not begin with visual style. First identify the user’s job to be done, success criteria, current pain points, assumptions, and unknowns. Distinguish direct research evidence from assumptions. Then recommend one primary flow and, only where needed, an alternate flow. Produce a UX design specification with these sections: 1. Problem statement and non-goals.
2. Primary user story and 3 to 5 acceptance criteria written so a product and engineering team can test them. 3. A step-by-step user flow from entry point through success, including decisions, system feedback, and exit points. 4. A screen inventory. For each screen, list purpose, essential content, primary action, secondary action, empty state, loading state, error state, and accessibility considerations. 5. Content guidance for labels, helper text, validation, confirmation, and irreversible actions. 6. Edge cases, including permission issues, interrupted work, duplicates, no results, and mobile or keyboard use where relevant. 7. A lightweight usability-test plan with 5 tasks, success signals, and questions that avoid leading participants. Keep recommendations proportional to the evidence and constraints. Do not invent research findings, legal requirements, or technical capabilities. Before answering, check that every step supports the user goal and that every acceptance criterion is observable. Flag assumptions that need validation. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT AND FEATURE] | Describe the product and the feature or journey you need to design. | A web-based expense tool needs a flow for a department manager to approve or return employee reimbursement requests. |
| [PRIMARY USER] | Describe the main user, their role, skill level, and relevant needs. | Department managers who approve expenses weekly, often on a laptop between meetings, and are not finance specialists. |
| [USER GOAL] | State the concrete outcome the user needs to achieve. | Review a request quickly, understand policy issues, and approve or return it with a clear record. |
| [USER CONTEXT AND RESEARCH] | Paste research findings, support issues, analytics, or contextual details you have. | Support tickets show managers cannot tell why requests are flagged. Interviews with six managers found receipt images and policy explanations are hard to compare. |
| [CONSTRAINTS AND EXISTING SYSTEM] | List platform, technical, business, brand, privacy, and existing-flow constraints. | The existing web app has a request list and receipt viewer. Finance requires an audit trail. Managers can approve only their own department’s requests. |
How to use
- Paste the evidence you have, including negative findings and system limitations.
- Check the flow against a real user’s starting point instead of assuming they enter through a new feature.
- Turn acceptance criteria into prototype review notes or engineering tickets.
- Follow up with: “Create a low-fidelity wireframe content outline for screen [SCREEN], including every state named in the specification.”
Variations
Usability test script
Use when you have a prototype ready to test.
Write a moderated usability-test script for [PROTOTYPE OR FLOW] with [TARGET PARTICIPANTS]. The product goal is [USER GOAL], and these are the assumptions to test: [ASSUMPTIONS]. Create a 45-minute session plan with introduction, realistic scenario, 4 to 5 task prompts, neutral follow-up questions, and closing questions. For each task, define what observers should record and what would count as success, partial success, or failure. Do not teach participants how the interface works during the task.
Design critique
Use when a screen or prototype needs a structured review.
Critique this interface description or screenshot notes: [INTERFACE]. Evaluate it for [PRIMARY USER] trying to [TASK] under these constraints: [CONTEXT]. Return findings grouped by hierarchy, comprehension, interaction feedback, error prevention, accessibility, and consistency with the stated goal. For each finding, state severity, supporting evidence from the interface, and a specific change. Separate confirmed issues from hypotheses that require testing. Do not recommend visual changes without explaining the user problem they address.
Empty states
Use when a feature has sparse, incomplete, or failed data states.
Design the non-happy-path states for [FEATURE] used by [USER]. The normal success flow is [SUCCESS FLOW], and available system actions are [SYSTEM CAPABILITIES]. Specify empty, first-use, no-results, loading, partial-data, permission-denied, offline if relevant, and error-recovery states. For each, provide a user-facing message, available action, data-retention behavior, and what must not happen. Keep language concrete and avoid blaming users. Flag any state that needs a product-policy decision before design.
Tips
- Write acceptance criteria around what a user can complete and understand, not around a screen being built.
- Treat empty, loading, and error states as part of the core flow; they often expose missing product decisions early.
- Keep evidence and assumptions visibly separate so a plausible design does not become mistaken for validated research.
- Ask usability-test participants to perform a realistic task rather than asking whether they “like” the interface.
FAQ
Can AI create a UX design from a short idea?
It can create a useful first brief, but the quality depends on knowing the user, context, and constraints. Mark untested assumptions for research rather than treating them as facts.
What should I give AI besides a feature request?
Share user research, current flow details, analytics, support patterns, platform constraints, and examples of decisions the system can actually make.
Is a user flow enough for engineering?
Usually not. Add observable acceptance criteria, system states, permissions, error handling, and content rules so the team can build and test the intended experience.