Elevate Your Design Process with Claude AI

<context> Page/component: [DESCRIBE OR PASTE HTML STRUCTURE] Current WCAG level: [A / AA / AAA / UNKNOWN] Target WCAG level: [AA / AAA] Known issues: [ANY ACCESSIBILITY COMPLAINTS] </context> <task> Perform a WCAG accessibility audit: 1. Color contrast: check all text/background combinations against target level 2. Keyboard navigation: can every interactive element be reached and activated via keyboard? 3. Screen reader: are all images described (alt text), form fields labeled, and headings hierarchical? 4. Focus management: is focus order logical? Are focus indicators visible? 5. Content structure: are headings properly nested? Is content readable without CSS? 6. Interactive elements: are buttons vs links used correctly? Are touch targets 44px minimum? 7. Dynamic content: are live regions, alerts, and modals announced to screen readers? 8. Forms: are errors described, required fields marked, and help text associated? For each issue found: describe the problem, cite the WCAG criterion, rate severity, and provide the specific fix (including code where applicable). </task>

<context> Current color palette: - Primary: [HEX] - Secondary: [HEX] - Background: [HEX] - Text: [HEX] - Accent: [HEX] - Any others: [LIST] Target: [WCAG AA / WCAG AAA] </context> <task> Audit and fix my color palette for accessibility: 1. Test every realistic text-on-background combination in my UI 2. For each combination: calculate the contrast ratio, state the WCAG requirement, and mark pass/fail 3. For every failing combination: suggest the minimum adjustment to the foreground or background color to pass while staying as close to the original brand color as possible 4. Provide a fixed palette with new hex codes 5. Show before/after contrast ratios 6. Generate a color usage matrix showing which colors can be safely combined Preserve the brand feel as much as possible — I want accessible colors, not a different brand. </task>

<context> Component: [DESCRIBE — modal, dropdown, tab panel, accordion, carousel, tooltip, etc.] Framework: [REACT / VUE / VANILLA HTML / etc.] Current implementation: [PASTE CODE OR DESCRIBE] </context> <task> Create a complete ARIA implementation guide for this component: 1. Required ARIA roles, states, and properties 2. Keyboard interaction pattern (which keys do what) 3. Focus management (where focus goes on open, close, navigation) 4. Screen reader announcements (what is read at each interaction) 5. Code example with all ARIA attributes in place 6. Testing checklist: how to verify it works with NVDA, VoiceOver, and JAWS 7. Common mistakes that break screen reader support for this pattern Reference the WAI-ARIA Authoring Practices for the canonical implementation pattern. </task>

<context> Product: [DESCRIBE] User demographics: [DESCRIBE — age range, tech savviness, known disabilities in user base, global audience, etc.] Platforms: [WEB / iOS / ANDROID] </context> <task> Review this product through an inclusive design lens: 1. Visual accessibility: color blindness (protanopia, deuteranopia, tritanopia), low vision, photosensitivity 2. Motor accessibility: can users with limited dexterity navigate? Touch target sizes, gesture alternatives 3. Cognitive accessibility: is content clear? Reading level? Cognitive load? Information chunking? 4. Hearing accessibility: are audio/video elements captioned? Are notifications visual as well as audible? 5. Situational impairments: bright sunlight, one-handed use, distracted attention, slow connections 6. Cultural inclusivity: language, date/number formats, imagery representation, color meaning across cultures 7. Age inclusivity: does the design work for both young digital natives and older users? For each area, provide: current status assessment, issues found, and specific improvements. </task>

<context> Product: [DESCRIBE] Development stage: [DESIGN / DEVELOPMENT / PRE-LAUNCH / LIVE] Team accessibility experience: [NONE / SOME / DEDICATED A11Y TEAM] Budget for tools: [FREE ONLY / MODERATE / ENTERPRISE] </context> <task> Create a practical accessibility testing plan: 1. Automated testing: which tools to use (axe, Lighthouse, WAVE), what they catch and what they miss 2. Manual testing checklist: keyboard navigation test, zoom test (200%), screen reader test, color contrast check 3. Screen reader testing matrix: which screen reader + browser combinations to test 4. User testing: how to recruit testers with disabilities, what to test, how to structure sessions 5. CI/CD integration: how to add automated accessibility checks to the build pipeline 6. Reporting template: how to log, prioritize, and track accessibility issues 7. Training: minimum accessibility knowledge every team member should have Prioritize for a team with [THEIR EXPERIENCE LEVEL] — start with the highest-impact, lowest-effort tests first. </task>

<context> Design tool: [FIGMA / SKETCH / TOKENS STUDIO] Dev framework: [REACT / VUE / ANGULAR / TAILWIND] Multi-brand: [YES — list brands / NO] Dark mode required: [YES / NO] </context> <task> Architect a design token system: 1. Token categories: color, typography, spacing, sizing, border-radius, shadow, motion, breakpoints 2. Token hierarchy: global primitives → semantic aliases → component-specific tokens 3. Naming convention: define the taxonomy (e.g., category-property-variant-state) 4. For each category, provide 10-20 token definitions with names and values 5. Dark mode strategy: how tokens remap for dark theme 6. Multi-brand strategy (if applicable): how tokens swap for different brands 7. Tool chain: how tokens flow from design tool → code → documentation 8. Migration guide: how to adopt tokens in an existing codebase incrementally Provide example JSON token files for both light and dark themes. </task>

<context> Product: [DESCRIBE] Framework: [REACT / VUE / WEB COMPONENTS] Existing components: [LIST ANY YOU HAVE] Design maturity: [STARTING FRESH / CLEANING UP AD-HOC COMPONENTS] </context> <task> Spec out a component library from foundational to complex: Tier 1 — Primitives (build first): For each primitive (Button, Input, Text, Icon, Badge, Avatar): define variants, sizes, states, and props Tier 2 — Composed components: For each (Card, Modal, Dropdown, Toast, Tooltip, Tabs): define structure, behavior, and which primitives they use Tier 3 — Patterns: For each (Form, Data Table, Navigation, Search, Pagination): define the compound component structure For every component at every tier: - Visual spec (sizes, spacing, colors via tokens) - Interaction spec (states, animations, keyboard behavior) - Accessibility spec (ARIA roles, focus management) - API spec (props, events, slots) Prioritize the build order based on frequency of use in your product. </task>

<context> Base unit: [4px / 8px / other] Grid system: [12-COLUMN / FLEXIBLE / DESCRIBE] Content density preference: [COMPACT / COMFORTABLE / SPACIOUS] </context> <task> Define a complete spacing and layout system: 1. Spacing scale: 8-12 spacing values from the base unit (e.g., 4, 8, 12, 16, 24, 32, 48, 64, 96, 128px) 2. Usage rules: which spacing values apply to which use cases (margin between components, padding inside components, gap between text blocks, section spacing) 3. Grid system: column widths, gutters, margins at each breakpoint 4. Container max-widths for content types (reading, dashboard, full-bleed) 5. Vertical rhythm: how line-height and spacing create consistent vertical flow 6. Component spacing patterns: card padding, form field spacing, list item gaps, button groups 7. A "spacing decision tree" — when unsure, follow this logic to choose the right value Provide CSS custom properties for the entire system. </task>

<context> Product type: [WEB APP / MOBILE APP / MARKETING SITE] Visual style: [OUTLINE / FILLED / DUOTONE / FLAT] Icon sizes needed: [LIST — 16px, 20px, 24px, 32px, etc.] Existing icon library: [USING HEROICONS / LUCIDE / CUSTOM / NONE] </context> <task> Design an icon system specification: 1. Icon grid: pixel grid size, padding zones, key shapes (circle, square, landscape, portrait) 2. Stroke weight and corner radius standards (consistent across all icons) 3. Required icon categories with a list of essential icons per category: - Navigation (home, back, menu, search, close...) - Actions (edit, delete, share, download, copy...) - Status (success, warning, error, info, loading...) - Content (file, image, video, link, text...) - Commerce (cart, payment, shipping, return...) 4. Color application rules: when icons inherit text color vs use a fixed color 5. Size and spacing rules: minimum size for legibility, touch targets, alignment with text 6. Animation guidelines: which icons animate and how (loading, success confirmation, transitions) 7. Naming convention: a systematic naming approach for scalability </task>

<context> Brand personality: [DESCRIBE — quick and snappy, elegant and smooth, playful and bouncy, etc.] Performance budget: [STANDARD / LIGHTWEIGHT / NO ANIMATIONS ON LOW-END DEVICES] Reduces motion preference: [MUST RESPECT prefers-reduced-motion] </context> <task> Define a motion design system: 1. Motion principles: 3-5 principles that guide all animation decisions (e.g., "purposeful — every animation communicates meaning") 2. Duration scale: 5-7 duration tokens from micro to macro interactions (e.g., 100ms, 200ms, 300ms, 500ms, 800ms) 3. Easing curves: 4-6 named curves with cubic-bezier values and when to use each 4. Enter/exit patterns: how elements appear and disappear (fade, slide, scale, etc.) 5. State transitions: how interactive elements move between states 6. Page transitions: how views/pages change 7. Loading and progress: skeleton screens, spinners, progress bars 8. Reduced motion fallbacks: what every animation becomes when prefers-reduced-motion is active Provide CSS custom properties for all duration and easing values. </task>

<context> Page type: [HOMEPAGE / PRODUCT PAGE / DASHBOARD / SETTINGS / ONBOARDING] Target user: [DESCRIBE] Primary goal of page: [WHAT SHOULD THE USER DO HERE] Content available: [LIST THE CONTENT/DATA THIS PAGE NEEDS TO DISPLAY] </context> <task> Describe a low-fidelity wireframe in enough detail that a designer can sketch it in 30 minutes: 1. Page structure: number of sections, approximate heights, scroll depth 2. For each section: - Content blocks with placeholder text indicators ([H1], [Body text], [CTA button]) - Layout: single column, two-column, grid, sidebar - Visual weight: what is largest/most prominent 3. Navigation: where it sits, what it contains, mobile behavior 4. CTAs: placement, size relative to page, primary vs secondary 5. Empty states: what does this page look like with no data yet? 6. Content priority order (mobile): if everything stacks, what comes first? Use ASCII box layout for the main structure if helpful. </task>

<context> Product: [DESCRIBE] User types: [LIST DIFFERENT USER TYPES IF ANY] Minimum setup needed: [WHAT MUST HAPPEN BEFORE THE USER CAN GET VALUE] Current onboarding: [DESCRIBE OR "none — users land on an empty dashboard"] </context> <task> Design a complete onboarding flow: 1. First impression (first 10 seconds): what the user sees immediately after signup — welcome, orientation, or direct into setup? 2. Setup wizard: step-by-step screens for essential configuration - For each step: what information to collect, why it matters, how to make it feel lightweight - Progress indicator design - Skip options and consequences 3. First value moment: what is the fastest path to the user experiencing the product's core value? 4. Empty states: for every screen that starts empty, design a state that educates and motivates 5. Guidance system: tooltips, checklists, or interactive tours — recommend which and why 6. Success milestone: what tells the user "you are set up, now you are a real user" 7. Re-engagement: what happens if the user drops off mid-onboarding Map the entire flow as a numbered sequence with branching paths. </task>

<context> Dashboard purpose: [ANALYTICS / PROJECT MANAGEMENT / CRM / ADMIN / MONITORING] User role: [EXECUTIVE / MANAGER / OPERATOR / ANALYST] Key metrics: [LIST THE 5-10 MOST IMPORTANT DATA POINTS] Frequency of use: [DAILY / WEEKLY / MONTHLY] Current pain points: [IF REDESIGNING — WHAT IS WRONG NOW] </context> <task> Design an optimized dashboard layout: 1. Information architecture: group related metrics, define card sizes by importance 2. Layout recommendation: fixed grid vs flexible, sidebar vs top nav, card-based vs table-based 3. Above the fold: what appears without scrolling — the 3-5 most critical metrics 4. Drill-down pattern: how users go from summary → detail without leaving context 5. Filtering and date range: placement and behavior 6. Real-time vs static data: indicate which metrics update live and how to show freshness 7. Alert system: how to surface anomalies or items needing attention 8. Customization: can users rearrange or hide cards? When is this worth the complexity? Specify card dimensions, spacing, and responsive behavior at mobile and desktop. </task>

<context> Form type: [SIGNUP / CHECKOUT / APPLICATION / SURVEY / SETTINGS / LEAD CAPTURE] Fields required: [LIST ALL FIELDS] User context: [WHERE THE USER IS COMING FROM / WHAT THEY EXPECT] Completion rate goal: [CURRENT % → TARGET %] </context> <task> Design the form UX for maximum completion: 1. Field order: optimal sequence based on cognitive load and commitment escalation 2. Field grouping: logical sections with clear labels 3. Input types: for each field, the right input control (text, dropdown, radio, toggle, auto-complete, date picker) 4. Validation strategy: inline vs on-submit, real-time vs on-blur, error message wording 5. Progressive disclosure: which fields to show later or conditionally 6. Smart defaults: which fields can be pre-filled or auto-detected 7. Micro-copy: label text, placeholder text, help text, error text for every field 8. Mobile optimization: field sizes, keyboard types (email keyboard, number pad), auto-capitalize settings 9. Progress and motivation: how to show completion progress on long forms 10. Success state: what happens after submission — confirmation, next steps, delight moment Estimate the friction score (1-10) and suggest which fields to remove if the form must be shortened. </task>

<context> Product: [DESCRIBE] Current error handling: [DESCRIBE — generic modals, inline messages, toast notifications, etc.] Brand tone: [FORMAL / FRIENDLY / TECHNICAL / PLAYFUL] </context> <task> Design a comprehensive error state system: 1. Error categories and handling patterns: - Validation errors (wrong input) → inline + specific guidance - System errors (server down) → full page or modal with retry - Permission errors (unauthorized) → redirect or explanation - Empty states (no data) → guidance to populate - 404 / not found → helpful navigation - Network errors (offline) → graceful degradation 2. For each category: visual design (color, icon, placement), copy tone, user action options 3. Error message formula: [What happened] + [Why it happened] + [What to do next] 4. 10 example error messages rewritten from generic ("An error occurred") to helpful 5. Error prevention: identify 5 places where better design could prevent the error entirely 6. Error recovery: how to help users recover data and progress after an error All error messages should match the brand tone. </task>

<context> Challenge: [DESCRIBE THE DESIGN PROBLEM TO SOLVE] Timeline: [5-DAY SPRINT / 3-DAY / COMPRESSED 1-DAY] Team: [LIST ROLES PARTICIPATING] Constraints: [TECHNICAL, BUSINESS, OR RESOURCE CONSTRAINTS] </context> <task> Create a complete design sprint brief: 1. Sprint goal: one sentence defining what we will answer or validate 2. Day 1 (Understand): activities, questions to answer, data to review, expert interviews to schedule 3. Day 2 (Sketch): ideation exercises, how many concepts to generate, evaluation criteria 4. Day 3 (Decide): decision framework, storyboard structure, what the prototype needs to test 5. Day 4 (Prototype): fidelity level needed, tools to use, who builds what 6. Day 5 (Test): test script, participant profile, number of tests, what constitutes success Include a materials/prep list and a pre-sprint homework assignment for participants. </task>

<context> Proposed design change: [DESCRIBE THE CHANGE] Current metrics: [CONVERSION RATE / BOUNCE RATE / TASK COMPLETION / NPS / etc.] Estimated improvement: [YOUR HYPOTHESIS — e.g., "5-15% conversion lift"] Development cost: [ESTIMATED HOURS OR DOLLARS] </context> <task> Build a design ROI case: 1. Impact modeling: calculate the revenue or cost impact of the proposed improvement at conservative, moderate, and optimistic scenarios 2. Cost analysis: design time + development time + testing time + opportunity cost 3. Payback period: how long until the improvement pays for itself at each scenario 4. Risk assessment: what could go wrong, and what is the downside if the change performs neutrally 5. Comparison: cost of doing nothing (compound impact of not fixing the current issue) 6. Recommendation: build the case in executive language — skip the design jargon Present as a one-page business case a non-designer stakeholder would find compelling. </task>

<context> Research goal: [WHAT QUESTION ARE WE TRYING TO ANSWER] Product stage: [PRE-LAUNCH / LIVE / REDESIGN] Budget: [LOW — guerrilla methods / MODERATE / HIGH — agency or lab] Timeline: [WHEN DO WE NEED ANSWERS] </context> <task> Create a UX research plan: 1. Research questions: 3-5 specific questions this study will answer 2. Method recommendation: [usability testing / interviews / surveys / card sorting / A/B test / diary study / analytics review] — justify why this method answers the questions best 3. Participant profile: who to recruit, how many, screening criteria 4. Study design: session structure, tasks, questions, time per session 5. Materials: what to prepare (prototype, discussion guide, survey, tasks) 6. Analysis plan: how to analyze results and what deliverable to produce 7. Timeline: week-by-week schedule from planning to presenting findings 8. Stakeholder communication: how and when to share findings Include a template discussion guide or task list for the chosen method. </task>

<context> Current state: [NO SYSTEM / PARTIAL / FULL BUT OUTDATED] Team size: [DESIGNERS + DEVELOPERS] Product complexity: [SIMPLE SITE / COMPLEX APP / MULTIPLE PRODUCTS] Buy-in level: [EXECUTIVES SUPPORT / TEAM WANTS IT / NOBODY ASKED FOR THIS] </context> <task> Create a design system adoption plan: 1. Audit current state: what components exist, how consistent are they, where is the most debt 2. Phase 1 (Foundation — Month 1-2): tokens, typography, color, spacing — the atoms 3. Phase 2 (Components — Month 3-4): the 10-15 most-used components, fully specified 4. Phase 3 (Patterns — Month 5-6): complex patterns, templates, page-level guidelines 5. Governance: who owns the system, contribution process, deprecation process 6. Documentation: what to document, where to host it, how to keep it updated 7. Adoption metrics: how to measure whether the team is actually using the system 8. Maintenance plan: how to evolve the system without it becoming stale Include a stakeholder pitch explaining the ROI of a design system. </task>

<context> Product to redesign: [DESCRIBE] Reason for redesign: [OUTDATED VISUAL / POOR METRICS / REBRAND / TECH MIGRATION / USER COMPLAINTS] Constraints: [TIMELINE / BUDGET / KEEP EXISTING CONTENT / MUST MAINTAIN X] Current metrics: [CONVERSION / ENGAGEMENT / NPS / etc.] </context> <task> Create a redesign strategy document: 1. Redesign scope: what is changing and what is explicitly NOT changing 2. User research summary: what do we know about current user pain points (or what research to conduct first) 3. Competitive landscape: how competitors have evolved and where we have fallen behind 4. Design principles for the redesign: 3-5 guiding principles for every design decision 5. Phased approach: break the redesign into incremental releases (not a big bang launch) 6. Risk mitigation: how to avoid the classic redesign disaster (users hate it, metrics drop) 7. Success metrics: what numbers must improve and by when to consider this successful 8. Timeline with milestones: realistic phases from kickoff to full launch Address the political dimension: how to get stakeholder alignment and manage feedback. </task>