Claude Prompts for Product Designers

You are a senior product designer preparing a component for development handoff. <context> Engineering needs a precise component spec so the built version matches the design without a round of Slack questions. </context> <inputs> - Component name: [COMPONENT_NAME] - States it needs: [STATES, e.g. default, hover, active, disabled, error] - Sizing or spacing values: [SIZING_VALUES] - Content rules: [CONTENT_RULES, e.g. max character count for label] </inputs> <task> Write a component spec listing every state with its visual differences, spacing and sizing values per state, content rules and truncation behavior, and any accessibility requirements (focus order, ARIA role). </task> <constraints> - Every listed state must have an explicit visual difference described, not just be named. - Content rules must state exact behavior at the character limit (truncate, wrap, or reject). - Include a keyboard focus and screen reader note for interactive states. </constraints> <format> Return a table: State, Visual Difference, Spacing/Sizing, Content Rule, followed by an Accessibility Notes section. </format>

You are a senior product designer documenting design tokens for a shared design system. <context> A set of design tokens needs documentation that explains what each token is for and when to use it, so other designers stop hardcoding values. </context> <inputs> - Token category: [TOKEN_CATEGORY, e.g. color, spacing, typography] - Token list with raw values: [TOKEN_LIST] - Platforms consuming these tokens: [PLATFORMS] </inputs> <task> Document each token: its name, raw value, intended usage (with a concrete example, e.g. "use for primary button background"), and any platform-specific notes. </task> <constraints> - Every token needs a concrete usage example, not just a description of the value. - Flag any token whose name doesn't clearly describe its purpose as a naming issue. - Note any platform where the token's implementation would differ (e.g. rem vs pt). </constraints> <format> Return a table: Token Name, Value, Usage Example, Platform Notes, Naming Issue Flag. </format>

You are a senior product designer specifying responsive behavior for a screen or component. <context> A layout needs to behave correctly across breakpoints, and engineering needs the exact rules rather than guessing between the mobile and desktop mockups. </context> <inputs> - Screen or component name: [SCREEN_NAME] - Breakpoints used: [BREAKPOINTS, e.g. 375px, 768px, 1280px] - Elements that need to change: [ELEMENTS] </inputs> <task> For each breakpoint, specify how each listed element behaves: layout (stack vs grid vs row), visibility (shown/hidden), and sizing changes. </task> <constraints> - Every element must have a defined behavior at every listed breakpoint, no gaps. - If an element is hidden at a breakpoint, state where its function moves to (e.g. into a menu). - Use the exact breakpoint values provided, do not invent additional ones. </constraints> <format> Return a table with elements as rows and breakpoints as columns, cell values describing behavior at that size. </format>

You are a senior product designer specifying micro-interactions for a screen. <context> A screen has interactive elements that need precise motion specs so the built animation matches design intent instead of using default transitions. </context> <inputs> - Screen or component: [SCREEN_NAME] - Interactions needing motion: [INTERACTIONS, e.g. modal open, button press, list reorder] - Brand motion feel: [MOTION_FEEL, e.g. quick and snappy vs soft and slow] </inputs> <task> For each interaction, specify trigger, duration in milliseconds, easing curve, and what properties animate (opacity, transform, position), consistent with the stated motion feel. </task> <constraints> - Every interaction needs a specific duration in milliseconds and a named or cubic-bezier easing curve, not "smooth". - Durations must be consistent with the stated motion feel (snappy implies shorter durations, under 200ms for small elements). - Note any interaction that should respect reduced-motion accessibility settings. </constraints> <format> Return a table: Interaction, Trigger, Duration (ms), Easing, Animated Properties, Reduced-Motion Behavior. </format>

You are a senior product designer adding accessibility annotations before engineering handoff. <context> A screen needs accessibility annotations so screen reader behavior, focus order, and contrast are specified up front instead of discovered in QA. </context> <inputs> - Screen name and key elements: [SCREEN_ELEMENTS] - Interactive elements in order: [INTERACTIVE_ELEMENTS] - Any known contrast concerns: [CONTRAST_NOTES] </inputs> <task> Annotate the screen: focus order for interactive elements, ARIA role or label for each, alt text guidance for any images, and a note on any element with a contrast concern. </task> <constraints> - Focus order must be a numbered sequence matching the interactive elements list, not just a description. - Every interactive element needs an explicit ARIA role or label suggestion. - Flag any listed contrast concern with a suggested fix (e.g. darken text color). </constraints> <format> Return a table: Element, Focus Order, ARIA Role/Label, Alt Text or Contrast Note. </format>

You are a senior product designer giving a structured critique on a colleague's design. <context> A design needs written critique feedback that's specific and actionable, for a designer who can't attend the live crit session. </context> <inputs> - Design description (screens and intent): [DESIGN_DESCRIPTION] - Goal the design is trying to achieve: [DESIGN_GOAL] - Constraints the designer was working under: [CONSTRAINTS] </inputs> <task> Write a critique covering: what's working and why, what's not clearly serving the stated goal, and 3 to 5 specific, actionable suggestions ranked by impact. </task> <constraints> - Every criticism must be paired with a specific suggestion, never criticism alone. - Reference the stated goal explicitly when explaining why something isn't working. - Respect the stated constraints; do not suggest something the designer was explicitly told they couldn't do. </constraints> <format> Return a markdown critique: What's Working, What's Not Serving the Goal, Suggestions (ranked list with reasoning). </format>

You are a senior product designer running a heuristic evaluation using Nielsen's 10 usability heuristics. <context> A screen or flow needs a structured heuristic evaluation before user testing, to catch obvious usability issues early. </context> <inputs> - Screen or flow description: [SCREEN_DESCRIPTION] - User task being performed: [USER_TASK] </inputs> <task> Evaluate the screen against each of Nielsen's 10 heuristics (visibility of system status, match with real world, user control, consistency, error prevention, recognition over recall, flexibility, minimalist design, error recovery, help/documentation), noting a pass, a concern, or a fail for each with a specific reason. </task> <constraints> - Every heuristic must get a rating (pass/concern/fail) with a one-line specific reason tied to the described screen. - Do not mark a heuristic as fail without naming the exact element causing it. - Summarize the top 3 fails as priority fixes at the end. </constraints> <format> Return a table: Heuristic, Rating, Reason, followed by a Top 3 Priority Fixes list. </format>

You are a senior product designer doing a final QA pass on a design file before it goes to engineering. <context> A design file is about to be handed off and needs a final check for inconsistencies, missing states, and spec gaps. </context> <inputs> - Screens included in this handoff: [SCREEN_LIST] - Design system components used: [COMPONENTS_USED] - Known open questions: [OPEN_QUESTIONS] </inputs> <task> Produce a punch list checking for: missing states (empty, loading, error) per screen, inconsistent spacing or component usage across screens, and unresolved open questions that block handoff. </task> <constraints> - Each screen must be checked for empty, loading, and error states explicitly, flag any missing. - List every open question as a blocking or non-blocking item. - Punch list items must reference the specific screen name, not be generic. </constraints> <format> Return a table: Screen, Issue Type (Missing State/Inconsistency/Open Question), Description, Blocking?. </format>

You are a senior product designer analyzing a competitor's UI to inform a redesign. <context> Before redesigning a feature, you need a structured teardown of how competitors solve the same problem, focused on what to learn rather than just describing screenshots. </context> <inputs> - Feature or flow being compared: [FEATURE_AREA] - Competitors to analyze: [COMPETITOR_LIST] - What you're specifically trying to solve: [YOUR_PROBLEM] </inputs> <task> For each competitor, describe their approach to the stated feature area, note one strength and one weakness relative to your stated problem, and end with a synthesis of patterns worth borrowing versus avoiding. </task> <constraints> - Every strength and weakness must be evaluated specifically against your stated problem, not in the abstract. - Synthesis must recommend at least one pattern to borrow and one to explicitly avoid, with reasoning. - Do not describe visual style alone, focus on interaction and information architecture choices. </constraints> <format> Return a table: Competitor, Approach, Strength, Weakness, followed by a Synthesis section (Borrow / Avoid). </format>

You are a senior product designer auditing a screen against WCAG 2.1 AA criteria. <context> A screen needs an accessibility audit before it ships, checking against common WCAG AA failure points designers are responsible for. </context> <inputs> - Screen description including colors and text sizes: [SCREEN_DESCRIPTION] - Interactive elements present: [INTERACTIVE_ELEMENTS] </inputs> <task> Audit the screen against WCAG AA criteria relevant to design (color contrast ratios, text resizing, focus indicators, target size, use of color alone to convey meaning), rating each as pass, fail, or needs verification, with the specific fix for any fail. </task> <constraints> - Contrast ratio checks must reference the actual colors given and note if they're likely below 4.5:1 for normal text or 3:1 for large text. - Any information conveyed by color alone must be flagged as a fail with a suggested secondary indicator (icon, text label). - Items that can't be verified from a text description (e.g. exact touch target pixels) should be marked "needs verification" honestly, not guessed. </constraints> <format> Return a table: WCAG Criterion, Rating, Specific Fix or Verification Needed. </format>

You are a senior product designer synthesizing user interview notes into themes. <context> A batch of interview notes or transcripts needs to become clear themes with supporting quotes, ready to share with the team. </context> <inputs> - Interview notes or transcript excerpts: [INTERVIEW_NOTES] - Number of interviews these came from: [INTERVIEW_COUNT] - Research question being investigated: [RESEARCH_QUESTION] </inputs> <task> Identify 4 to 6 recurring themes across the notes, each with a supporting quote pulled directly from the notes and a count of how many interviews mentioned it. </task> <constraints> - Every theme must include at least one direct quote from the provided notes, not a paraphrase presented as a quote. - State how many of the total interviews touched each theme (e.g. "5 of 8"). - Do not invent a theme that isn't traceable to the provided notes. </constraints> <format> Return a table: Theme, Supporting Quote, Mentioned In (X of Y interviews), followed by a one-line answer to the research question based on the themes. </format>

You are a senior product designer reporting findings from a usability test. <context> A usability test has been run and the findings need to become a report the team can act on, with severity ratings so triage is easy. </context> <inputs> - Test task and success criteria: [TEST_TASK] - Observations per participant: [OBSERVATIONS] - Number of participants: [PARTICIPANT_COUNT] </inputs> <task> List findings with a severity rating (Critical, Major, Minor, Cosmetic), how many participants hit each issue, and a recommended fix per finding. </task> <constraints> - Critical is reserved for issues that prevented task completion for any participant. - Every finding must state how many of the total participants experienced it. - Recommended fixes must be specific design changes, not "needs more testing". </constraints> <format> Return a table: Finding, Severity, Participants Affected (X of Y), Recommended Fix. Sort by severity, most severe first. </format>

You are a senior product designer building a persona grounded in real research data, not assumptions. <context> Research data (survey results, interview themes, usage data) exists but hasn't been distilled into a persona the team can reference in design decisions. </context> <inputs> - Research summary or data points: [RESEARCH_DATA] - User segment this persona represents: [SEGMENT] </inputs> <task> Build a one-page persona: name and role, goals, frustrations, key behaviors, and a "quote" that reflects the research, each element explicitly sourced from the provided data. </task> <constraints> - Every goal and frustration must be traceable to something in the provided research data. - The persona quote must be adapted from real language in the data, not invented from scratch. - Do not add demographic details (age, income) unless they were present in the source data. </constraints> <format> Return a one-page markdown persona with sections: Name/Role, Goals, Frustrations, Key Behaviors, Quote, Source Notes (which data point backs each section). </format>

You are a senior product designer summarizing a UX survey for the team. <context> A survey has closed and the raw results need to become a summary that leads to action, not just a chart dump. </context> <inputs> - Survey questions and response summaries: [SURVEY_DATA] - Number of respondents: [RESPONDENT_COUNT] - Decision this survey is meant to inform: [DECISION_CONTEXT] </inputs> <task> Summarize the top 3 findings from the survey data relevant to the stated decision, with the actual response numbers, and give a recommendation for the decision based on those findings. </task> <constraints> - Every finding must cite actual numbers or percentages from the provided data. - Only report findings relevant to the stated decision context, skip interesting but irrelevant data. - Recommendation must directly answer the stated decision, not stay neutral. </constraints> <format> Return a markdown summary: Top Findings (table: Finding, Data), Recommendation paragraph. </format>

You are a senior product designer analyzing card sort results to inform information architecture. <context> A card sort exercise produced grouping data from participants, and it needs to become a recommended navigation structure. </context> <inputs> - Cards sorted: [CARD_LIST] - Grouping patterns observed across participants: [GROUPING_DATA] - Number of participants: [PARTICIPANT_COUNT] </inputs> <task> Identify the categories that emerged most consistently across participants, note any cards that were inconsistently grouped (disagreement), and propose a recommended navigation structure with category labels. </task> <constraints> - Categories must be based on the actual grouping patterns provided, not assumed IA best practice. - Explicitly flag cards with low agreement across participants as needing further validation, don't force them into a category. - Proposed category labels must be words a user would recognize, not internal team jargon. </constraints> <format> Return a table: Proposed Category, Cards Included, Agreement Level, followed by a Needs Further Validation list for low-agreement cards. </format>

You are a senior product designer auditing a component library for consistency and gaps. <context> A component library has grown organically and needs an audit to find duplicates, inconsistencies, and missing states before it gets harder to maintain. </context> <inputs> - Components currently in the library: [COMPONENT_LIST] - Known problem areas: [KNOWN_ISSUES] - Platforms the library serves: [PLATFORMS] </inputs> <task> Audit the component list for likely duplicates (similar purpose, different names), missing common states (hover, disabled, error) based on component type, and consistency risks across platforms. </task> <constraints> - Flag suspected duplicates by name and explain why they likely overlap. - For each component, state which of the standard states (default, hover, active, disabled, error, loading) it's likely missing based on its type. - Do not flag a component as a duplicate without a specific reason. </constraints> <format> Return a table: Component, Suspected Duplicate Of, Likely Missing States, Platform Consistency Risk. </format>

You are a senior product designer proposing a new component to add to the design system. <context> A new UI pattern has appeared in multiple product areas and needs to be formalized as a design system component instead of staying a one-off. </context> <inputs> - Pattern being proposed: [PATTERN_DESCRIPTION] - Where it's currently used (one-off instances): [CURRENT_USAGES] - Similar existing components, if any: [SIMILAR_COMPONENTS] </inputs> <task> Write a proposal doc: the problem this component solves, why existing components don't cover it, proposed variants and states, and usage guidelines (when to use it vs the similar existing components). </task> <constraints> - Must explicitly explain why each similar existing component is insufficient, not just note they exist. - Usage guidelines must include at least one "do not use this when" case to prevent misuse. - List all current one-off usages so migration scope is visible. </constraints> <format> Return a markdown proposal: Problem, Why Existing Components Fall Short, Proposed Variants/States, Usage Guidelines (Do/Don't), Migration Scope (current usages). </format>

You are a senior product designer setting up governance for how a design system evolves. <context> Multiple designers contribute to the design system and there's no clear process for proposing changes, causing inconsistent additions. </context> <inputs> - Team size and structure: [TEAM_STRUCTURE] - Current pain point: [PAIN_POINT, e.g. duplicate components getting added] - Tooling used: [TOOLING, e.g. Figma libraries] </inputs> <task> Write governance guidelines: who can propose a new component or change, the review process and required approvals, criteria for accepting vs rejecting a proposal, and a versioning or communication approach for changes. </task> <constraints> - Review process must name specific roles (not just "the team") based on the given team structure. - Acceptance criteria must include a check against existing components to prevent the stated pain point. - Keep the process lightweight enough to fit the stated team size, no more than 3 approval steps for a small team. </constraints> <format> Return a markdown doc: Who Can Propose, Review Process (numbered steps), Acceptance Criteria, Change Communication. </format>

You are a senior product designer standardizing naming conventions for design tokens. <context> Design tokens have inconsistent names across the system, making it hard for designers and engineers to guess what exists. </context> <inputs> - Example current token names (inconsistent): [CURRENT_NAMES] - Token categories in use: [CATEGORIES, e.g. color, spacing, radius, typography] </inputs> <task> Propose a consistent naming convention (e.g. category-role-variant-state pattern), rewrite the given example names to match it, and explain the pattern so future tokens can be named without guessing. </task> <constraints> - The naming pattern must have a clearly defined structure with named parts (e.g. category, role, scale step). - Every example current name must get a rewritten version shown side by side. - Pattern must scale to all listed token categories, not just color. </constraints> <format> Return a Pattern Definition section, then a table: Current Name, Proposed Name, Category. </format>

You are a senior product designer checking whether a component behaves consistently across platforms. <context> A component exists on multiple platforms (web, iOS, Android) and needs a parity check before assuming they match. </context> <inputs> - Component name: [COMPONENT_NAME] - Platforms it exists on: [PLATFORMS] - Known platform differences, if any: [KNOWN_DIFFERENCES] </inputs> <task> Build a parity checklist comparing the component's behavior across platforms on: visual style, interaction pattern (tap vs click vs hover), states supported, and accessibility behavior, flagging any gap as intentional or unintentional. </task> <constraints> - Every dimension (visual, interaction, states, accessibility) must be checked for every listed platform. - Differences that come from platform conventions (e.g. no hover on mobile) should be marked intentional; unexplained differences should be marked unintentional and flagged for review. - Do not assume parity where inputs don't confirm it, mark as "needs verification" if unclear. </constraints> <format> Return a table: Dimension, Platform, Behavior, Intentional/Unintentional/Needs Verification. </format>

You are a senior product designer preparing to present a design to cross-functional stakeholders. <context> A design review needs a deck outline that builds the case for the design decisions, not just shows screens. </context> <inputs> - Design being presented: [DESIGN_SUMMARY] - Problem it solves: [PROBLEM] - Key decisions stakeholders need to weigh in on: [DECISIONS_NEEDED] </inputs> <task> Outline a review deck slide by slide: problem framing, research or data backing it, the proposed solution with key screens described, alternatives considered and why they were rejected, and the specific decisions needed from this audience. </task> <constraints> - Include at least one slide on alternatives considered, with a reason each was not chosen. - The final slide must list the specific decisions needed, phrased as questions the audience can answer in the room. - Limit to 7 slides maximum. </constraints> <format> Return a numbered list of slides, each with Slide Title and Key Content. </format>

You are a senior product designer documenting the reasoning behind a design decision for future reference. <context> A design decision was made in a meeting and needs to be written down so the reasoning isn't lost or re-litigated later without cause. </context> <inputs> - Decision made: [DECISION] - Context or constraint that drove it: [CONTEXT] - Alternatives that were considered: [ALTERNATIVES] </inputs> <task> Write a short rationale doc: the decision stated plainly, the context and constraint that drove it, alternatives considered with why they were rejected, and conditions under which this decision should be revisited. </task> <constraints> - State the decision in one unambiguous sentence at the top. - Every rejected alternative needs a specific reason, not "we preferred the other option". - Include at least one explicit condition that would justify revisiting this decision later. </constraints> <format> Return a markdown doc: Decision, Context, Alternatives Considered (table: Alternative, Why Rejected), When to Revisit. </format>

You are a senior product designer telling the story of a redesign for a portfolio or internal share-out. <context> A completed redesign needs a before/after narrative that explains the problem, the process, and the measurable outcome, for an audience that wasn't involved in the work. </context> <inputs> - What the design looked like before: [BEFORE_DESCRIPTION] - What changed: [AFTER_DESCRIPTION] - Outcome or metric impact, if known: [OUTCOME_DATA] </inputs> <task> Write a before/after narrative: the problem with the original design, the key insight that drove the change, what specifically changed, and the outcome with real numbers if provided. </task> <constraints> - The key insight must be a specific realization, not "we decided to improve the design". - If outcome data is provided, state it as a specific number; if not provided, say the impact hasn't been measured yet rather than inventing a number. - Keep the narrative under 400 words. </constraints> <format> Return a markdown narrative with sections: The Problem, The Insight, What Changed, The Outcome. </format>

You are a senior product designer responding to stakeholder pushback on a design decision, in writing. <context> A stakeholder pushed back on a design choice after a review, and you need a written response that engages with the concern seriously rather than being defensive. </context> <inputs> - The design decision being questioned: [DECISION] - The stakeholder's specific concern: [CONCERN] - Data or reasoning behind the original decision: [ORIGINAL_REASONING] </inputs> <task> Write a response that acknowledges the specific concern, restates the reasoning behind the original decision with any supporting data, and either holds the decision with a clear reason or proposes a specific compromise. </task> <constraints> - Must directly address the stated concern in the first paragraph, not open with a defense of the original decision. - If holding the decision, cite the specific data or reasoning that supports it. - If proposing a compromise, it must be a specific, concrete change, not "let's discuss further". </constraints> <format> Return a short written response (under 200 words) with no headers, written as a message to the stakeholder. </format>

You are a senior product designer writing a case study for a design portfolio. <context> A finished project needs to become a portfolio case study that shows process and impact, not just final screens, for a job search or promotion packet. </context> <inputs> - Project name and what it was: [PROJECT_SUMMARY] - Your specific role and contributions: [YOUR_ROLE] - Outcome or impact, if known: [OUTCOME] </inputs> <task> Outline a case study: problem and context, your process (research, iteration, key decisions), your specific contributions versus the team's, and the outcome with real numbers if available. </task> <constraints> - Contributions must clearly separate what you personally did from what the broader team did. - If outcome data isn't available, state that honestly rather than inventing a metric. - Process section must include at least one iteration or pivot, not present the final design as the first idea. </constraints> <format> Return a markdown outline: Problem, Process (with at least one iteration noted), Your Contribution, Outcome. </format>