Create a comprehensive design-token system as the foundation of a design system, implemented as CSS custom properties — and, if using Tailwind, surfaced through the theme config so utility classes consume the SAME tokens (one source of truth, no duplication). Define: a color system with neutral and brand scales from 50–950 plus semantic tokens (success/warning/error/info, and intent tokens like text, background, surface, border, ring) so components reference ROLES, not raw hues; a type scale (families, a modular size scale in rem, weights, line-heights, letter-spacing); a 4px-based spacing scale; radii (sm–xl, full); elevation/shadows with distinct light- and dark-theme values; motion tokens (durations and easing curves); and breakpoints plus z-index layers. Provide a dark-theme override that remaps ONLY the semantic tokens so every component re-themes automatically. Name tokens by role and tier (e.g. --color-surface, --color-surface-raised) rather than by appearance, document each token's intended use, and verify color pairings against WCAG AA. Done when components can be built referencing only semantic tokens, switching themes remaps a single layer with zero component changes, the tokens are consumed by both raw CSS and Tailwind without being duplicated, and every semantic text/background pairing passes AA contrast.
#45UI/UX
Component Style Guide Page
Build a living style guide page (React 19 + TypeScript + Tailwind) that documents the design system and STAYS IN SYNC with the real components — import the actual components, never re-implement them for display. Organize sections for typography (h1–h6, body, caption, code), color (swatches showing the token name, the value, and a contrast badge against common backgrounds), buttons (all variants, sizes, and states), form controls (input, textarea, select, checkbox, radio, toggle — each in default/focus/error/disabled), cards, badges and tags, alert and notification banners, loading states (spinner, skeleton, progress), and spacing/layout examples. For each component show a live, interactive example with the exact JSX/markup beside it (a code block that genuinely reflects what's rendered), plus a short note on when to use it and its accessibility contract. Make the guide itself accessible and responsive, with a sticky in-page nav and an anchor link per section. Done when every documented component is the REAL one rendered live, the shown code matches what's on screen, the contrast badges flag any failing color pair, and the page is fully navigable by keyboard and responsive.
#46UI/UX
Responsive Navigation System
Build a responsive navigation system (React 19 + TypeScript + Tailwind) that adapts across breakpoints from ONE source of truth for the nav items. Desktop (>1024px): a horizontal bar with logo, primary links, a search input, and a user dropdown menu. Tablet (768–1024px): logo plus a hamburger that opens a slide-out menu containing the links and search. Mobile (<768px): a sticky bottom tab bar with five icon+label primary destinations and a hamburger for secondary items; the bottom bar hides on scroll-down and reappears on scroll-up. Nail the accessibility that navigation menus usually get wrong: the dropdown and slide-out are real disclosure widgets with correct aria-expanded/aria-controls, focus moves into an opened menu and is trapped there, Escape and an outside click both close it and return focus to the trigger, and the current page is marked with aria-current. Every interaction works by keyboard, and all motion respects prefers-reduced-motion. Done when navigation is fully operable by keyboard and screen reader at every breakpoint, focus is correctly trapped and then restored around the mobile menu, the active route is indicated, and the bottom bar's scroll behavior never traps or permanently hides content.
#47UI/UX
Skeleton Loading System
Build a skeleton-loading system (React 19 + TypeScript + Tailwind) that PREVENTS layout shift while content loads. Create composable primitives — a text line (configurable width), an avatar (circle), and an image (aspect-ratio box) — plus composed skeletons for a card (image + title + description lines), a table row, and a list item (avatar + lines). The critical requirement: each skeleton must occupy the EXACT dimensions of the real component it replaces so swapping to real content causes zero CLS — share sizing tokens between the skeleton and the component rather than eyeballing values. Add a shimmer animation (a single GPU-friendly CSS gradient sweep, paused under prefers-reduced-motion) and make it accessible: mark skeleton regions aria-hidden / aria-busy so screen readers announce "loading" instead of reading out placeholder boxes, and don't trap focus on them. Provide a wrapper (e.g. <Loadable loading={...} skeleton={...}>) that swaps between skeleton and content, and avoid flashing the skeleton for ultra-fast loads (a small delay before showing it). Done when toggling the loading state causes no measurable layout shift, the skeleton matches the real component's footprint, the shimmer respects reduced-motion, and assistive tech announces a loading state rather than garbage.
#48UI/UX
Toast Notification System
Build a toast notification system (React 19 + TypeScript + Tailwind) callable from anywhere via a tiny imperative API: toast.success('Saved!'), toast.error('Failed', { action: { label: 'Retry', onClick } }), plus warning and info, returning an id so a toast can be programmatically dismissed or updated (e.g. a promise toast that goes loading → resolved). Support four types each with a distinct icon and color, an optional action button, and a configurable auto-dismiss (default 5s). Stack toasts in a corner with smooth enter/exit animations. Get the ACCESSIBILITY right, because toasts are notorious for failing it: render them in an aria-live region (polite for info/success, assertive for errors) so they're announced WITHOUT stealing focus, pause the dismiss timer on hover and on keyboard focus, allow Escape to dismiss the focused toast, and make sure the action button is reachable before the toast disappears. Limit to five visible toasts and queue the rest; respect prefers-reduced-motion. Don't tie toast state to any single component's lifecycle — use a portal plus an external store so toasts survive route changes. Done when toasts can be fired from outside React's render tree, are announced to screen readers without grabbing focus, pause on hover/focus, never exceed the visible cap, and their action buttons are operable by keyboard.
#49UI/UX
Accessibility Audit Checklist
Act as an accessibility specialist and audit this code against WCAG 2.1 AA: [paste code]. Go through it systematically and report CONCRETE, located findings — for each issue give the offending element, the WCAG criterion it violates, why it matters and to which users, and the corrected code. Check: heading hierarchy (an h1 is present, no skipped levels, headings aren't used purely for styling); images (meaningful alt text, empty alt for decorative, no "image of…"); form controls (every input has a programmatic label via for/id or wrapping, errors associated via aria-describedby, required state conveyed non-visually); ARIA usage (roles and states correct and not redundant with native semantics — prefer native elements); keyboard support (all interactive elements focusable and operable, logical tab order, no traps, a visible focus-visible indicator); color contrast (4.5:1 body text, 3:1 large text and UI components, and never color as the only signal); target size (at least 24×24, ideally 44×44); motion (prefers-reduced-motion honored); and dynamic updates announced via live regions. Note what still needs manual screen-reader verification. Done when every finding names the element, the criterion, and a specific fix, and the highest-impact blockers — keyboard traps, unlabeled controls, contrast failures — are called out first.
#50UI/UX
Empty State & Error Page Designs
Design five empty-state / error layouts (React 19 + TypeScript + Tailwind) with the illustrations drawn in PURE CSS — no image assets: "no results found" (a magnifier over a blank page), "inbox zero" (an open envelope with a check), "404 not found" (a broken link/chain), "connection error" (an unplugged plug), and "under construction" (a striped traffic cone). Build each illustration from CSS shapes, gradients, and pseudo-elements, kept on a shared scale and palette so the set feels cohesive and reads well on a dark theme. Each layout pairs the illustration with a clear heading, a helpful one-line subtitle that says what happened and what to do next, and a primary action (plus a secondary where it helps — e.g. retry vs go home). Treat these as real UX, not decoration: clearly DISTINGUISH an empty state (no data yet — encourage the first action) from an error state (something failed — offer recovery), make the action buttons keyboard-accessible, mark the decorative illustration aria-hidden, and keep the copy human and specific rather than generic filler. Done when all five render crisply from CSS alone, look right on a dark background, clearly differentiate empty vs error intent, and each offers an obvious, accessible next action.