Prompts for UI and UX Design: Flows, Screens, and Critiques

The most useful AI prompts for UI and UX design start from the user's goal, not the screen itself. When you give an assistant the problem a user is trying to solve, the constraints the design must respect, and the decisions already approved, it can give you specific, usable feedback rather than generic suggestions. Tools like fenbs keep the design decisions and accepted feedback in one place, so each session starts from agreed ground.

The templates below cover four stages of UI and UX work: mapping user flows, writing interface requirements, running an accessibility review, and critiquing a finished design. Each includes the context to fill in and notes on what to look for in the response.

What every UI and UX prompt needs

A design prompt without user context produces interface suggestions, not UX thinking. Before you send any design prompt, check that it includes the following. The more specific these are, the more actionable the response.

• The user's goal: what they are trying to do, not what the screen is supposed to show.
• The user's starting point: what they already know and what they might be worried about.
• The product context: the screen's place in a larger flow, and what comes before and after.
• Constraints: platform (mobile or desktop), accessibility requirements, design system rules.
• What has been decided: approved patterns, rejected approaches, and standing feedback from stakeholders.

Prompts for user flow mapping

User flow prompts help you plan the steps between a user's entry point and their goal before you design any screens. Use them to find missing steps, decision points, and error states that are easy to overlook when working directly in a design tool.

Map the user flow for [task the user is trying to complete] in [product or app name].

User starting point: [where they begin and what they know]
User goal: [what a successful outcome looks like]
Platform: [mobile / desktop / both]
Constraints: [any restrictions on the flow]

For each step:
- What the user sees
- What they need to do or decide
- What happens if they make an error

List the three steps most likely to cause a user to abandon the flow.
Note any decision point where the approved design does not yet have a solution.

Prompts for interface requirements

Interface requirements translate a user flow into the specific elements a screen needs. A requirements prompt is useful before you move a design into high fidelity, and useful again when you hand a screen to a developer. It surfaces missing states, edge cases, and content decisions before they become bugs.

Write interface requirements for the [screen name] screen in [product name].

User goal on this screen: [what the user is trying to do]
User flow position: [what comes before and after this screen]
Platform: [mobile / desktop]
Design system: [any relevant component rules]

For each UI element on the screen list:
- Purpose and behavior
- All states it must handle (default, loading, error, empty, success)
- Content requirements (label copy, character limits, placeholder text)

Flag any state where the current design does not have an approved solution.

Prompts for accessibility review

Accessibility reviews are easier when the prompt focuses on a specific standard and a specific screen rather than asking for a general check. This template uses WCAG 2.1 AA as the baseline, which is the standard required for most US commercial and government work.

Review the accessibility of the [screen name] screen against WCAG 2.1 AA.

[Describe the screen: its purpose, main elements, and interactive components.]

Check for:
- Color contrast on text and interactive elements
- Keyboard navigation order and focus indicators
- Alternative text for images and icons
- Form field labels and error messages
- Touch target sizes on mobile

For each issue:
- Describe what the problem is
- Cite the relevant WCAG criterion
- Suggest a concrete fix

Note any area where you cannot assess the design from a description alone.

For broader design work, Claude design covers how to prompt AI tools for visual and interface work. For the website-level view that feeds into individual screens, see prompts for website design.

Prompts for design critique

A critique prompt that references the original user goal and any known constraints produces more useful feedback than one that asks for general opinions. Include the project brief and any stakeholder decisions so the assistant can distinguish a real problem from a personal preference.

Critique this design for the [screen name] screen.

User goal: [what the user is trying to do on this screen]
Constraints: [platform, accessibility requirements, design system rules]
Approved decisions: [any choices already confirmed by stakeholders]

[Describe or paste the design.]

For each issue:
- Is it a usability problem, a consistency issue, or a stakeholder decision that needs review?
- How significant is it for the user's goal?
- What change would you suggest?

Prioritize problems that affect the user's ability to complete their goal.

Keeping feedback and decisions between design sessions

UI and UX projects generate a lot of feedback: stakeholder comments, usability findings, accessibility notes, and approved direction changes. When this feedback only lives in a presentation or a chat thread, the next design session starts from a vague memory rather than a clear record. Important decisions get re-litigated, and feedback from one session contradicts the direction set in another.

After each design session, write the accepted feedback and direction changes into a shared record before the session closes. Separate decisions that are now fixed from questions that are still open. The next critique prompt can then reference the known state of the design rather than asking the assistant to guess. System prompt examples shows how to structure the context you pass to an assistant to produce consistent results.

Stakeholder reviews are another important source of decisions that need recording. When a product manager, a client, or a legal reviewer asks for a specific change during a design review, recording that request and its rationale means the next designer does not have to justify the same decision again. An accessibility change requested by a legal team, a brand constraint from a marketing director, or a usability finding from a user test are all decisions that belong in the design record. When those decisions are visible to a connected assistant before a design session, the critique and requirements prompts above can reference them without you having to reconstruct the history from scratch.

How to do this with fenbs

1. Create a free account and add your product or design project.
2. Write the approved design decisions into Decisions and rules: platform constraints, accessibility baseline, rejected directions, and standing stakeholder preferences.
3. Save your most-used critique and review templates in Skills and prompts.
4. Connect your assistant over MCP from Integrations, so it reads the project decisions before each session.
5. After each review, add new decisions and update any that changed.

fenbs does not import designs from Figma or Sketch, and it does not run automated accessibility tests. It keeps the decisions and instructions your design process depends on, including stakeholder approvals, accepted feedback, and standing brand or accessibility rules, so the next design session or critique prompt has the right context before it starts each time.