Claude Skills for UI and UX: Design Review Templates

Claude skills for UI and UX are saved instruction sets that give every design review the same structure. One skill handles interface critique: layout, hierarchy, spacing and visual consistency. Another focuses on usability: whether interactions are clear, errors are preventable and the flow makes sense for the intended user. A third checks accessibility against published guidelines. Tools like fenbs keep the accepted design decisions alongside follow-up tasks, so each review session picks up where the last one stopped.

Design reviews without a structure tend to produce feedback that focuses on whatever the reviewer notices first, which is often a visual preference rather than a usability problem. A skill shifts the session toward the questions that matter most for the product and the people using it. The skill does not replace a qualified designer, but it makes Claude a more useful review partner when one is not in the room.

What to put in a UI review skill

A UI review skill should cover the concerns specific to your product and platform, not just general design principles. If your product runs on small screens, the skill should check tap target sizes and content density. If it is primarily a desktop web app, it should check keyboard navigation and focus states. Build from the guidelines that govern your platform: the Web Content Accessibility Guidelines (WCAG) for web products, or platform-specific conventions for native apps.

Keep the skill focused on observable issues rather than subjective preferences. "The button label is vague" is actionable. "The design feels off" is not. Frame each check as a question the reviewer can answer with a yes or a specific observation. That framing makes it easier to turn the review output directly into follow-up tasks.

A useful test for any check you add to a skill: can the reviewer answer it with a yes, a no, or a specific observation? If the answer requires a subjective judgment -- "does this feel right?" -- the check is not actionable enough. Replace it with something observable: "Do button labels describe the resulting action rather than the element itself?" or "Is the default choice the safest one for the user?" Questions with observable answers produce feedback the designer can act on without further interpretation.

See claude skills examples for patterns across other review contexts. The claude skills marketplace and claude skills files cover storing and sharing skills across a team.

Skill 1: interface critique

Use this skill when reviewing a screen, component or flow for visual clarity and layout consistency. Describe or share the design after activating the skill. The skill works best when you include the context: what the screen is for and who the primary user is.

Review the interface I describe or share below. Focus on clarity and layout, not subjective style preferences.

Check:
1. Visual hierarchy: whether the most important information or action is the most prominent.
2. Consistency: whether spacing, type sizes, colors and interactive element styles match the established pattern.
3. Labels: whether button labels, headings and field labels tell the user what will happen or what to enter.
4. Density: whether the screen contains the right amount of information for the context -- not too sparse, not cluttered.
5. Empty and error states: what the screen looks like with no content or after an error, and whether those states communicate clearly.

For each issue, name the element, describe the problem, and suggest a change.

You can describe the interface in plain language, paste a screenshot description or share a design file link. The more specific you are about what the screen contains and what the user is expected to do with it, the more relevant the review.

Skill 2: usability check

Use this skill to check whether a flow or interaction is clear for the intended user. It focuses on the cognitive load and the clarity of the path through the interface, rather than visual presentation.

Review the user flow or interaction I describe below from the perspective of usability.

Check:
1. Task clarity: whether a user encountering this flow for the first time can understand what they need to do.
2. Error prevention: whether the design makes it easy to avoid common mistakes before they happen.
3. Recovery: if a user makes a mistake or gets confused, whether the interface helps them understand what went wrong and how to continue.
4. Progress: whether the user can tell where they are in a multi-step process and how much remains.
5. Confirmation: whether actions with significant consequences are confirmed before they happen.

Describe each usability problem, why it would affect users, and what a clearer approach would be.

Walk through the flow step by step in your description. Include what the user wants to accomplish, any decisions they have to make along the way, and any points where the flow might be unclear. A brief description of the target user helps Claude apply the right level of assumed knowledge.

Skill 3: accessibility review

Use this skill to check a screen or component against accessibility fundamentals before testing with assistive technology. It does not replace testing, but it catches the issues most likely to be present before a build is complete.

Review the interface I describe below for accessibility fundamentals.

Check:
1. Color contrast: whether text and interactive elements have sufficient contrast against their backgrounds for users with low vision.
2. Text alternatives: whether images, icons and non-text content have descriptive labels or alt text.
3. Keyboard and focus: whether all interactive elements can be reached and activated without a mouse, and whether focus is visible.
4. Form labels: whether every input has an associated label that is visible and programmatically connected.
5. Motion and animation: whether any motion can be reduced or disabled for users who are sensitive to it.

Note each issue, the WCAG criterion it relates to, and what to change. Link to the [WCAG guidelines](https://www.w3.org/WAI/WCAG22/quickref/) for any criterion that needs more detail.

Describe the interface, or paste relevant HTML and CSS if you want Claude to check specific markup. For a complete accessibility audit, test with a screen reader and keyboard after using this skill to catch the structural issues.

How to do this with fenbs

Connect these review skills to the decisions and tasks they produce, so each review builds on the last.

1. Create a free account and add a project for the product or feature you are designing.
2. Add the design requirements as tasks: what the screen or flow needs to do, who will use it, and what counts as done.
3. Save the review skills in fenbs Skills and prompts with clear names so any connected assistant can activate the right one.
4. When a review reveals a decision -- a chosen interaction pattern, a color contrast standard, an agreed exception -- record it in Decisions and rules with the reason. This prevents the same discussion from happening again.
5. Turn the specific issues from each review into tasks on the board. Track them to completion rather than letting review feedback accumulate in chat history.

When to skip a skill and prompt directly

A one-off prompt is the right tool when the design question is specific to this screen and will not recur. Reusable skills pay off for review types you run regularly, especially when more than one person runs them. See claude projects vs skills vs artifacts to help decide which format fits the work.

Design reviews done consistently over time also build a useful record. When a pattern of issues repeats across multiple reviews -- the same component type consistently missing focus states, or the same flow type consistently presenting too many options at once -- that pattern is a signal worth investigating. It may point to a convention to establish, a shared component to fix at the source, or a recurring user need the product is underserving. Tracking review tasks in fenbs alongside the design decisions lets you find those patterns across sessions instead of treating each review in isolation.

Keep in mind that a skill checks against the criteria you include in it, not every possible design principle. A skill written for mobile screens will not check for desktop keyboard accessibility unless you add that check. Review the skill whenever the product expands to a new platform, new screen size or new user group to make sure the checklist still covers the full scope of review you need.