Production-ready UI component patterns with complete code examples in React/TypeScript, SwiftUI, and modern CSS. Covers component state matrices, accessibility patterns, design token integration, and responsive behavior.
From ux-ui-masterynpx claudepluginhub phazurlabs/ux-ui-mastery --plugin ux-ui-masteryThis skill uses the workspace's default tool permissions.
references/css-modern-patterns.mdreferences/react-component-cookbook.mdreferences/swiftui-component-cookbook.mdDesigns and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
"A component is not a visual artifact. It is a state machine with a visual output." Every button, input, modal, and card exists in a matrix of states that must be designed, implemented, and tested. Developers and designers who treat components as static visual elements inevitably ship incomplete interfaces that break under real-world conditions — when the network is slow, when the user tabs instead of clicks, when the content is unexpectedly long, when the screen is 320px wide.
Production-quality component engineering demands three disciplines simultaneously: visual fidelity (the component looks correct across every state), behavioral completeness (the component responds correctly to every interaction), and semantic correctness (the component communicates its purpose and state to all users, including those using assistive technology).
Every component exists in far more states than the typical design file represents. The State Matrix is a systematic enumeration of every possible visual and behavioral state a component can occupy. Before writing a single line of code, enumerate the full matrix.
These states apply to virtually every interactive component:
States combine. A text input can be simultaneously focused and in an error state. A button can be loading and disabled. A table row can be selected and hovered. Your component API must handle compound states gracefully without combinatorial explosion. The recommended pattern is to model each state dimension independently:
This dimensional model yields a manageable API surface rather than an unwieldy union of every possible combination.
Before any component ships:
Organizing components into functional categories creates a shared vocabulary for the team and ensures coverage. The taxonomy below covers the foundational set that virtually every product needs.
Components that trigger operations. The user clicks, taps, or activates them to cause something to happen.
Components that accept user data.
Components that communicate status, results, or system state to the user.
Components that move the user between views, sections, or pages.
Components that present or contain information.
Components optimized for displaying structured datasets.
Every component must consume design tokens rather than hardcoded values. Tokens are the contract between design and code. They ensure that when the design system changes a color, spacing value, or font, every component updates automatically.
--color-primary, --color-surface, --color-on-surface, --color-error, --color-border--space-xs, --space-sm, --space-md, --space-lg, --space-xl--font-family-body, --font-size-sm, --line-height-normal, --font-weight-medium--radius-sm, --radius-md, --radius-lg, --radius-full--shadow-sm, --shadow-md, --shadow-lg--duration-fast, --duration-normal, --easing-standard, --easing-decelerate--size-touch-target (44px minimum), --size-icon-sm, --size-icon-md--button-bg: var(--color-primary).--button-bg-hover: var(--color-primary-hover).Accessibility is not an enhancement. It is a baseline requirement. Components built with accessibility from the start are cheaper to maintain, more robust, and usable by everyone.
tabindex or DOM order reflects the intended sequence.<button>, <input>, <dialog>, <nav>). ARIA is a supplement, not a replacement.aria-expanded, aria-selected, aria-checked, aria-busy, aria-invalid, aria-disabled.aria-live="polite" or aria-live="assertive") announce dynamic content changes (toast notifications, form validation messages, loading completions).aria-label. Every image requires alt text or aria-hidden="true" if decorative.role="status" or aria-live="polite" so screen readers announce them without interrupting the current task.aria-describedby.aria-busy="true" on the loading region.Media queries respond to the viewport. Container queries respond to the component's container. Since components are reused in different layout contexts (sidebar, main content, modal), container queries produce correct results where media queries fail.
.card-container {
container-type: inline-size;
container-name: card;
}
@container card (min-width: 400px) {
.card { flex-direction: row; }
}
@container card (max-width: 399px) {
.card { flex-direction: column; }
}
Use clamp() for typography and spacing that scales smoothly between breakpoints without abrupt jumps:
font-size: clamp(1rem, 0.5rem + 1.5vw, 1.5rem);
padding: clamp(0.75rem, 2vw, 2rem);
Per WCAG 2.5.8 (Target Size), interactive elements must be at least 24x24 CSS pixels, with a recommendation of 44x44 pixels. Apple HIG specifies 44pt minimum. Material Design specifies 48dp. Always err on the side of larger targets on touch devices.
This is directly informed by Fitts's Law (see cognitive-psychology-ux): the time to reach a target is a function of distance and target size. Smaller targets increase error rates and frustration, especially under mobile conditions (one-handed use, walking, glare).
cognitive-psychology-ux covers Fitts's Law (touch target sizing), Hick's Law (reducing choice overload in selects and menus), Miller's Law (chunking in data tables and forms), and the gestalt principles that inform component grouping and layout.accessibility-inclusive-design provides the full WCAG 2.2 checklist, assistive technology testing procedures, and inclusive design patterns that component code must satisfy.ui-visual-design-system details the token naming conventions, scale generation, and semantic mapping that components consume.interaction-motion-design covers easing curves, duration scales, reduced-motion handling, and spring physics that component transitions use.figma-design-tool-workflows describes how component designs in Figma translate to code, including auto-layout to flexbox mapping, variant properties to component props, and design token export.design-systems-architecture explains how components are documented, versioned, tested, and distributed across teams.