ui-design
Design and polish user interfaces — layout, typography, spacing, colour/theme tokens, states, responsiveness, accessibility — and verify the result visually in the browser. USE WHEN the user asks to "
SKILL.mdskills/ui-design/SKILL.md
GitHubUI design
Goal: an interface that looks intentional on every screen size, is usable with keyboard and screen reader, and is verified with a real render — not just CSS that "should" work.
1. Understand the system you're styling
- For chat / copilot / agent surfaces, or when the user wants a calm "Claude-like" feel, load the
claude-ui-uxskill as well — it carries that visual language and the assistant-specific UX patterns. - Find the existing design language: global styles, CSS variables/tokens, Tailwind/theme config, component library (shadcn, MUI, Chakra, Vuetify…), fonts, icon set.
grep_searchfor--color,theme,tailwind.config,tokens. Reuse these — never introduce a second palette or spacing scale. - Look at one well-made screen in the app (or the framework docs) and match it.
- If a screenshot was attached, list the concrete problems you see (alignment, contrast, crowding, truncation, inconsistent sizes) before changing anything.
2. Principles to apply
- Hierarchy: one primary action per view; size/weight/colour express importance; the eye should land on the title, then the key data, then actions.
- Spacing scale: stick to a 4/8 px scale; consistent gaps inside groups (tight) vs between groups (loose). Align to a grid; align text baselines and icon centres.
- Typography: ≤ 2 families, 3–5 sizes, line-height 1.4–1.6 for body, ~1.2 for headings, max ~70 characters per line; tabular numbers for data.
- Colour: neutrals for structure, one brand accent for primary actions/focus, semantic colours only for meaning (success/warn/error). Contrast ≥ 4.5:1 for text, ≥ 3:1 for UI. Support light and dark via tokens, not hard-coded values.
- States: every interactive element has hover, focus-visible, active, disabled and loading states; async views have loading, empty and error states with a next action.
- Motion: short (120–250 ms), ease-out, used to explain change; respect
prefers-reduced-motion. - Responsive: mobile-first; container queries or breakpoints at content-driven widths; no horizontal scroll; touch targets ≥ 44 px.
- Accessibility: semantic elements (
button,nav,main, headings in order), labels for inputs,alttext, visible focus ring, keyboard order = visual order, ARIA only when native semantics don't exist, live regions for async status. - Copy: short, specific labels ("Save changes" not "Submit"); helpful empty states; error text says what to do.
3. Implement
- Change tokens/variables before components; components before pages. Prefer the component library's primitives.
- Keep styles co-located the way the project does (CSS modules, styled, Tailwind classes, global CSS). Remove dead CSS you replace.
4. Verify visually (mandatory)
- Start or reuse the dev server (
run_command, background), thenbrowser_inspectthe page: read the screenshot, console errors, failed requests and layout findings (overflow, tiny tap targets, contrast). Repeat withmobile: true. - Walk the states: use
actionsinbrowser_inspectto hover/click/type and capture hover, focus, error and empty states. - Check both themes if the app supports them. Fix, re-inspect, then
open_browserto show the user.
5. Report
- Before/after description of what changed and why (hierarchy, spacing, contrast…), the screens/viewports verified, and any follow-ups (e.g. a component that still lacks a focus style).