Review a product interface and propose improvements grounded in the user’s job, task flow, and evidence. Do not invent user research, accessibility compliance, technical constraints, analytics results, or business goals. Avoid subjective advice such as “make it cleaner” unless you tie it to a concrete usability problem. Product, user, and primary job to be done: [PRODUCT AND USER] Screen, flow, or component to improve: [CURRENT UI OR DESCRIPTION] Task, success definition, and known friction: [TASK AND FRICTION] Available evidence: [RESEARCH ANALYTICS OR FEEDBACK] Design system, platform, technical, and accessibility constraints: [CONSTRAINTS] Ask up to 3 clarifying questions only if a required input is missing. Then produce a UI improvement brief with: 1. A concise problem statement that separates known evidence from assumptions. 2. A task-flow analysis from entry point to completion, identifying decision points, cognitive load, error opportunities, feedback gaps, and recovery paths. 3. A prioritized list of 5–8 changes. For each, include the UI change, user rationale, affected state or edge case, expected outcome, implementation note, and measurable acceptance criteria. 4. At least one keyboard, screen-reader, focus, contrast, touch-target, error-message, or responsive consideration relevant to the supplied interface; label it as a recommendation unless verified against standards. 5. A lightweight validation plan with a test task, target participants or data source, success signals, and what result would change the recommendation. Prefer fewer, higher-confidence changes over a redesign. Self-check before answering: ensure each recommendation maps to the user task or evidence; flag assumptions and missing states such as loading, empty, error, permissions, and mobile where relevant.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT AND USER] | Describe the product, target user, and the user’s practical job to be done. | B2B invoicing app for small-business bookkeepers who need to send recurring invoices quickly. |
| [CURRENT UI OR DESCRIPTION] | Paste a screenshot description, linkable component details, or a step-by-step description of the current interface. | Recurring invoice setup is a three-step desktop modal: customer, schedule, line items; the Save button is disabled until all fields validate. |
| [TASK AND FRICTION] | State the user task, how success is measured, and the observed pain points or drop-off. | Create a monthly invoice in under 3 minutes; users abandon on step two when they cannot tell why Save is disabled. |
| [RESEARCH ANALYTICS OR FEEDBACK] | Provide relevant usability notes, support tickets, session patterns, analytics, or stakeholder feedback. | Six support tickets mention unclear schedule errors; 31% of started setups do not reach confirmation. |
| [CONSTRAINTS] | List the design system, supported devices, engineering limits, deadlines, and accessibility requirements. | Existing React design system, desktop and tablet, WCAG 2.2 AA target, one sprint for implementation. |
How to use
- Describe one screen or workflow and one primary task rather than asking for a whole-product redesign.
- Paste actual user feedback or analytics with enough context to distinguish observation from opinion.
- Check acceptance criteria against existing platform and design-system constraints before creating tickets.
- Follow up with: “Convert the top three recommendations into user stories with edge cases and QA scenarios for our React team.”
Variations
UX audit
Use this to assess a bounded flow before planning a redesign.
Audit the [FLOW OR SCREEN] for [USER TYPE] trying to [TASK]. Use [EVIDENCE] and respect [CONSTRAINTS]. Return a severity-ranked table of usability issues with observed evidence, heuristic or principle involved, user impact, recommendation, affected states, and validation method. Cover navigation, hierarchy, forms, errors, status feedback, responsive behavior, and relevant accessibility considerations. Do not claim WCAG conformance or invent findings. Flag uncertainty and ask up to 3 questions only if essential input is missing.
Design critique
Use this for structured feedback on a proposed design direction.
Critique this proposed UI, [DESIGN DESCRIPTION], for [USER AND TASK] against [SUCCESS CRITERIA]. Give feedback in four sections: what supports task completion, risks or ambiguity, missing interaction states, and prioritized changes. Tie every comment to a user action, content need, or stated constraint. Include keyboard, focus, error, loading, empty, and mobile considerations when relevant. Do not substitute personal taste for a reasoned critique or invent research results. Ask up to 3 questions only when required.
Usability test plan
Use this when you need evidence before committing engineering time.
Create a usability-test plan for [PRODUCT OR PROTOTYPE] focused on [TASK]. Participants are [TARGET USERS], and the decision we need to make is [DECISION]. Provide a moderator introduction, 5–7 neutral task prompts, observation fields, follow-up questions, success measures, stopping criteria, and a synthesis template. Do not lead participants toward the intended design or treat small-sample findings as statistically representative. Ask up to 3 questions only if essential details are missing.
Tips
- Write the primary task as an observable action with a success condition, such as “schedule a recurring invoice without support,” before changing the interface.
- For each proposed control, define its empty, loading, validation-error, permission-denied, and completed states as applicable.
- Do not treat a conversion drop-off as proof of a UI cause; pair it with session evidence, support themes, or a test.
- Make acceptance criteria behavioral, such as “the user can identify the invalid field before submitting again,” rather than visual preference.
FAQ
Can AI improve UI from a screenshot alone?
It can identify likely issues, but it cannot see user intent, interaction behavior, or technical constraints from a screenshot. Add task context and evidence for better recommendations.
Will this produce a visual redesign?
It produces a reasoned improvement brief. You can then ask for wireframe annotations, component requirements, or implementation tickets.
How should I handle accessibility recommendations?
Use them as a design and QA checklist, then validate against your organization’s standards and relevant technical testing tools.