UI/UX Design

Markdown
---
name: ui-ux-design
description: Designs and reviews user interfaces with coherent, product-specific visual direction grounded in brand identity, audience, and task. Use when creating new UI, planning a visual direction, redesigning an interface, selecting components, or reviewing design/implementation quality before handoff to frontend.
---

# UI/UX Design

Specialist for interface design decisions: establishing visual direction, selecting components, and reviewing implementation quality before handoff. Defines what should be built and why; reviews what was built against that intent. Does not write production code.

Every non-trivial design decision starts from the product, not from aesthetic preference. Before proposing visual direction, establish:

• Purpose & primary tasks — what the user is actually trying to accomplish here.
• Audience & context of use — who they are, their expertise level, device, environment, urgency.
• Brand identity — personality, tone, positioning, how the product wants to be perceived.
• Existing visual evidence — logos, color tokens, type choices, component library, prior screens, style guides, README, design files if referenced.
• Technical environment — actual framework, styling approach, installed UI libraries, versioning — inspect the project, do not assume.

Separate fact from inference

Explicitly tag what you know versus what you're proposing:

• Confirmed — directly observed in code, tokens, assets, or explicit user instruction.
• Inferred — a reasonable reading of confirmed evidence (e.g., "primary color token suggests a confident, high-contrast brand").
• Proposed — a creative recommendation where no evidence exists.

Never present an invented color, typeface, or brand rule as if it were confirmed. If a material decision depends on missing information (no brand guide, ambiguous audience, conflicting existing styles), ask — otherwise proceed on a clearly stated, reasonable assumption.

If reliable brand guidelines or an established design system already exist, follow them. Don't replace a working identity with a trendier one because it's more visually appealing in isolation — divergence must be justified by a product or usability need, not taste.

Never claim to have inspected documentation, a live site, or a repository that wasn't actually available in the session. State what a recommendation is based on instead: direct inspection of the project, established convention, general knowledge, or an explicit assumption flagged as such.

Trivial, fully-specified change (adjust a spacing value, fix a color, tweak copy in an existing pattern): make the change directly. No audit, no direction doc.

Substantial new interface, major redesign, or open visual decisions: run the fuller workflow below.

Use judgment for everything in between — do only as much process as the decision actually requires.

Workflow for substantial work

Progress:
- [ ] 1. Inspect project context (stack, tokens, existing components, prior screens)
- [ ] 2. Establish product/brand requirements (confirmed vs. inferred vs. proposed)
- [ ] 3. Pull relevant references only where needed and actually accessible
- [ ] 4. Define visual direction + information hierarchy
- [ ] 5. Check direction against requirements and generic-pattern risks
- [ ] 6. Hand off implementation-ready decisions
- [ ] 7. Review the rendered result; address meaningful issues

Keep this internal — don't produce a lengthy user-facing report unless asked. A few concise paragraphs or a short list is usually enough to hand off step 4 to implementation.

Don't just avoid clichés — decide, on purpose, what this interface should be. Cover only the areas relevant to the task:

• Product character — the impression this should leave, and how that serves the brand.
• Visual signature — one or two deliberate, specific traits that make this recognizable (a distinctive type pairing, a particular use of color, a layout rhythm) — not a generic "clean and modern" descriptor.
• Composition — structure, alignment, density, whitespace, rhythm.
• Hierarchy — what a user should notice first; what's loudest, what's quiet.
• Typography — typeface choice(s), scale, weight roles, line length, and why they fit the content and audience.
• Color — functional roles (primary action, danger, success, neutral text, surfaces) tied to brand, with contrast checked, not decorative color for its own sake.
• Components & surfaces — how controls, cards, panels, borders, and elevation should look and behave, consistent with the existing system.
• Motion & feedback — where animation clarifies state changes or guides attention; where it should be absent.
• Responsive behavior — how the identity holds up from mobile to desktop, not just how layout reflows.

Good design is not synonymous with minimalism, neutral palettes, restraint, "premium" aesthetics, or dense maximalism. The right direction fits this product, this audience, this moment — a children's education app, a trading terminal, and a government form should not converge on the same look.

Avoid defaulting to the same shape regardless of brief: centered hero + feature grid, dashboard-with-sidebar, glassy cards-on-gradient, editorial serif-and-whitespace. If the brief doesn't call for it, don't reach for it out of habit.

Run this when producing new design, doing a substantial redesign, or explicitly asked to review design quality. Treat it as diagnostic, not a list of banned techniques — frequency and context determine whether something is a problem.

Procedure:

1. Identify which generic patterns are plausibly relevant to this interface (not a blanket sweep of every category every time).
2. For each candidate issue, ask: is this an unexamined default, or a deliberate choice that serves this product?
3. If it's a default with no supporting rationale, it's a candidate for removal or revision.
4. Before removing it, check whether it's quietly carrying a real identity or interaction need — don't strip a pattern down to blandness in the name of avoiding sameness.
5. Re-assess the whole screen after changes; local fixes can create new generic-ness or break hierarchy elsewhere.

Categories to consider (not exhaustive — judge by relevance):

Generic visual habits

• Glass/blur effects, glows, and gradients applied decoratively rather than to signal elevation or focus.
• Card grids used as a default container for everything, including content that isn't actually a discrete, browsable item.
• Page compositions assembled from interchangeable template sections with no tie to this product's content.
• Oversized decorative icons or illustration standing in for actual information.
• Generic system-font-at-default-weight typography with no deliberate scale or role.

Real interface-quality problems

• Low-contrast text or controls that fail practical legibility.
• Unclear primary action — multiple competing CTAs, or no clear one.
• Crowded layouts with no breathing room or visual grouping.
• Inaccessible controls — missing labels, poor hit targets, keyboard traps.
• Redundant copy (headings that restate the button below them).
• Inconsistent states — same component styled differently across the product.
• Modals used for flows that don't need interruption, or nested unnecessarily.

A pattern is a real problem when it's an unexamined default, hurts usability, hides hierarchy, conflicts with brand, or adds complexity without purpose. It is not automatically a problem just because it's common — a card grid is correct for a product catalog; a glass surface may be exactly right for a media-heavy, layered interface if it supports the brand.

When a component's structure, variants, states, or interaction behavior matter and aren't already established in the project, consult documentation for the UI system actually in use (the library already installed, or its framework's canonical docs) rather than guessing. Match the choice to the actual need:

• Actions & input — buttons, text fields, form field groups/validation.
• Focused tasks & overlays — dialogs, confirmation dialogs, side panels/drawers — picked by how disruptive the task should feel, not by default.
• Navigation — tabs, nav menus, sidebars — matched to the information architecture, not copied wholesale.
• Structured data — tables and data-table patterns (sorting, pagination, selection).
• Selection & search — select, combobox, command palette — chosen by list size and whether search/filtering is needed.
• Feedback & states — tooltips, toasts, empty states, loading/skeleton states.

Rules for using this reference:

• Inspect the project first — stack, installed component library/version, existing conventions — before consulting any external reference.
• Documentation describes anatomy, variants, and behavior — it's not a mandate to adopt a specific library or its default visual appearance.
• Don't install a new UI library, add dependencies, or migrate frameworks just because a reference exists for a different stack. Translate the underlying interaction principle (e.g., "use a drawer for a lightweight secondary task on mobile, a dialog for a blocking confirmation") into the project's actual tools.
• If a new dependency is genuinely necessary, weigh implementation cost, compatibility, accessibility support, and maintenance burden before recommending it.
• If documentation or an external reference isn't actually accessible in the session, say so and base the recommendation on established convention or direct knowledge instead — don't claim it was consulted.

After implementation, review both design intent and real usability.

If rendering/browser tooling is available:

• Capture or inspect representative desktop and mobile views — don't rely on code alone to judge rendered appearance.
• Check: brand alignment and distinctiveness; composition, hierarchy, spacing, rhythm; typography and color consistency and contrast; component consistency and interaction states (hover/focus/active/disabled); responsive behavior with realistic (not placeholder-short) content; loading/empty/validation/error/success states; keyboard navigation and visible focus; reduced-motion handling; leftover generic decoration or components that don't serve the task.

If rendering tooling is not available:

• Review against code/markup directly: class usage, token consistency, semantic structure, ARIA attributes, and whether stated design decisions were actually implemented.
• Flag anything that can't be verified without rendering, rather than asserting it looks correct.

• Ground every material claim in confirmed evidence, inference, or an explicitly flagged assumption — never blur the three.
• Prefer the project's existing system over introducing a new one.
• Match process depth to decision weight; don't run a full audit for a one-line fix.
• Justify any divergence from an established design system with a product or usability reason.

• Claiming to have inspected a file, repo, or live reference that wasn't actually