Best ChatGPT Prompts for UX Designers & Product Designers (2026)

You are a senior UX researcher. Create a structured user interview question guide for the target persona and research goal described below. The guide should include: a warm-up section (3–4 rapport-building questions about the participant's background and daily context — not product-specific), a core exploration section (8–10 open-ended questions designed to uncover behaviours, motivations, and pain points — not opinions or feature preferences), a current solutions section (3–4 questions about how they currently solve the problem, what they use, and where those solutions fall short), and a closing section (2–3 questions to surface anything you haven't asked and leave them feeling heard). For each question, provide a brief interviewer note on what you're trying to learn and a follow-up probe to use when the initial answer is surface-level. Write questions that uncover behaviour and context, not validation for pre-existing ideas. Avoid leading questions or questions that reveal your design hypothesis.

RESEARCH DETAILS:
- Product or problem space: [PRODUCT TYPE / DOMAIN — e.g., "expense tracking tool for freelancers"]
- Target persona: [DESCRIBE PERSONA — role, context, key characteristics]
- Research goal (what you need to learn): [1–3 KEY QUESTIONS THIS RESEARCH SHOULD ANSWER]
- Stage of design process: [DISCOVERY / GENERATIVE / EVALUATIVE]
- Interview length: [30 MIN / 45 MIN / 60 MIN]
- Known assumptions you want to test: [LIST — or "none confirmed yet"]
- Topics to avoid or handle with care: [SENSITIVE AREAS — or "none"]

You are a senior UX researcher. Synthesise the raw interview notes below into a structured research summary. The summary should include: a one-paragraph overview of the key patterns that emerged across participants, a Behaviours section (how participants actually behave — not what they say they want), a Motivations section (the underlying goals driving their behaviour), a Pain Points section (specific frustrations, workarounds, and friction points — with quotes where possible), a Mental Models section (how participants conceptualise the problem or domain, including any surprising or counterintuitive beliefs), and a Design Implications section (3–5 actionable insights that should inform design decisions — framed as "How might we..." statements). Do not project intent onto participants or conflate what they said with what they meant. Where the data is ambiguous or contradictory, flag it explicitly rather than smoothing it over. Include participant reference codes (e.g., P1, P2) when attributing insights.

RESEARCH DATA:
- Number of participants: [NUMBER]
- Participant codes and brief profiles: [LIST — e.g., "P1: freelance designer, 32, London; P2: in-house PM, 28, remote"]
- Raw interview notes or transcript excerpts: [PASTE NOTES HERE]
- Product or problem space: [DESCRIBE]
- Research questions this was designed to answer: [LIST]
- Any known data quality issues (missed questions, interrupted sessions, etc.): [OR "none"]

You are a UX research specialist. Based on the interview excerpts and raw observations below, generate a structured affinity diagram framework. For each category, provide: the category name (a concise label for the theme), a 1–2 sentence description of what belongs in this category, 3–5 example data points or quotes from the source material that illustrate it, and the design implication this category points toward. Organise the categories into a two-level hierarchy: high-level themes (major insight clusters) and sub-themes (specific patterns within each cluster). Aim for 4–6 high-level themes with 2–4 sub-themes each, depending on what the data supports — do not force more structure than the data justifies. Flag any data points that don't fit cleanly into a category (these often contain the most interesting insights). Suggest which sub-themes should be explored further in a second round of research.

RESEARCH DATA:
- Raw observations, quotes, and notes: [PASTE ALL DATA HERE]
- Number of participants or sessions: [NUMBER]
- Product or problem space: [DESCRIBE]
- Research method used: [INTERVIEWS / CONTEXTUAL INQUIRY / DIARY STUDY / USABILITY SESSIONS / MIXED]
- Any themes you've already identified (for the AI to build on, not constrain): [LIST — or "none identified yet"]
- Anything you want explicitly excluded from the clustering: [e.g., "ignore technical feedback — that goes to engineering"]

You are a senior UX researcher and design strategist. Based on the research data below, write 5–7 key insight statements for the design team. Each insight statement should follow this structure: [OBSERVED BEHAVIOUR or FACT] because [UNDERLYING MOTIVATION or ROOT CAUSE], which means [DESIGN IMPLICATION or OPPORTUNITY]. Insights should be non-obvious (not just descriptions of the obvious), specific enough to be actionable (not "users want it to be easier"), grounded in observed data rather than inferred preferences, and framed in a way that creates a clear mandate for design decisions. Each insight should stand alone — a designer who reads it without seeing the research data should understand the finding and know what it asks of the design. After the insight statements, include a section flagging 2–3 "tension points" where the data pulls in contradictory directions — these are often the most valuable design challenges.

RESEARCH DATA:
- Synthesis summary or key findings: [PASTE SYNTHESIS — or raw notes if no synthesis exists]
- Product or problem space: [DESCRIBE]
- Target persona: [DESCRIBE]
- Stage of design: [DISCOVERY / CONCEPT DEVELOPMENT / ITERATION]
- Known design constraints (technical, business, regulatory): [LIST — or "none identified"]
- What the team currently believes (to stress-test against the data): [CURRENT ASSUMPTIONS — or "none documented"]

You are a senior UX designer. Using the research summary below, create a detailed design persona. The persona should include: a name and photo description (brief physical/contextual description for illustration purposes — not stereotyping), a one-paragraph narrative describing a day in their life that's relevant to the problem space, a Demographics section (age range, occupation, location, tech fluency — keep it design-relevant, not marketing-demographic), a Goals section (the 3–4 underlying motivations that drive their behaviour — not feature wishes), a Pain Points section (the 3–4 most significant frustrations in the current experience), a Behaviours section (how they actually work, what tools they use, what workarounds they've built), a Quotes section (2–3 verbatim or representative quotes from the research that capture their perspective authentically), a Mental Model section (how they think about the problem domain), and a Design Priorities section (what this persona needs from the product above all else). This persona should feel like a real person the design team will refer to throughout the project — not a marketing archetype.

RESEARCH INPUT:
- Research summary or key findings: [PASTE SYNTHESIS]
- Number of participants the persona is based on: [NUMBER]
- Primary research method: [INTERVIEWS / SURVEYS / CONTEXTUAL INQUIRY / MIXED]
- Product or service being designed: [DESCRIBE]
- How many personas are needed (and what differentiates them): [NUMBER AND DIFFERENTIATOR — or "single primary persona"]
- Any demographic or behavioural constraints from the brief: [OR "none"]

You are a senior UX designer and service designer. Based on the persona and scenario described below, write a detailed customer journey map narrative. For each stage of the journey, describe: the stage name and goal, what the user is doing (their actions and tasks), what they are thinking (their internal monologue and assumptions), what they are feeling (emotional state — use specific emotions, not "happy/sad"), the touchpoints they interact with (channels, people, systems, artefacts), and the pain points and friction that occur at this stage. After the full narrative, provide a summary table with columns for Stage / Doing / Thinking / Feeling / Touchpoints / Opportunities (key design opportunities at each stage). Highlight the "moment of truth" — the single stage where the user's experience most determines whether they stay, churn, or advocate. The narrative should read as a coherent story, not a bulleted list — this is the version you present to stakeholders.

JOURNEY DETAILS:
- Persona name and summary: [NAME — 2–3 sentence description]
- Scenario (what they're trying to accomplish): [SPECIFIC TASK OR GOAL — e.g., "onboard to the platform and submit their first invoice"]
- Journey scope (start and end points): [START TRIGGER — END STATE]
- Product or service being designed: [DESCRIBE]
- Number of journey stages expected: [e.g., 5–7 — or "use your judgement"]
- Known pain points to include (from research): [LIST — or "none confirmed"]
- Channels or touchpoints to include: [e.g., mobile app, email, support chat — or "all relevant"]

You are a UX strategist and product designer. Based on the persona described below, write a comprehensive set of Jobs-to-be-Done (JTBD) statements. Use the format: "When [SITUATION], I want to [MOTIVATION / ACTION], so I can [DESIRED OUTCOME]." Provide: 3–4 Functional Jobs (the practical tasks the persona is trying to accomplish), 2–3 Emotional Jobs (how they want to feel during or after the task), 2–3 Social Jobs (how they want to be perceived by others as a result), and 1–2 Negative Jobs (things they want to avoid or stop doing). For each job statement, rate its importance to the persona (High / Medium / Low) based on the research data and note whether existing solutions satisfy it (Well-satisfied / Partially satisfied / Under-served). The under-served, high-importance jobs are your design opportunities — call them out explicitly in a summary at the end.

PERSONA & RESEARCH INPUT:
- Persona summary: [PASTE PERSONA OR KEY DETAILS]
- Product or problem space: [DESCRIBE]
- Research findings that support these jobs: [PASTE RELEVANT EXCERPTS — or "infer from persona"]
- Known competitor solutions this persona currently uses: [LIST — or "unknown"]
- Business constraints on which jobs the product can address: [OR "none identified"]

You are a UX lead and product strategist. Based on the user research data below, create a structured pain point prioritisation framework to help the design team decide where to focus. For each identified pain point, provide: the pain point description (specific, behaviour-based — not vague like "confusing UI"), the frequency (how often it occurs in the user journey — Always / Often / Sometimes / Rarely), the severity (how significantly it impacts the user's ability to complete their goal — Critical / Major / Minor), the breadth (what percentage of the target user base experiences it — based on research data or estimated), a Business Impact score (High / Medium / Low — how addressing this pain point would affect key product metrics like retention, activation, NPS), and a Complexity to Solve score (High / Medium / Low — design and engineering effort required). Create a 2×2 prioritisation matrix mapping Severity vs. Business Impact and categorise each pain point as: Quick Win (low complexity, high impact), Strategic Investment (high complexity, high impact), Low Priority (low complexity, low impact), or Deprioritise (high complexity, low impact). The top 3 "solve-first" recommendations should be clearly stated.

RESEARCH DATA:
- Raw pain points from research (list or paste): [PAIN POINTS]
- Number of research participants: [NUMBER]
- Product or service context: [DESCRIBE]
- Stage of design (to calibrate how much detail is appropriate): [DISCOVERY / CONCEPT / ITERATION]
- Known business priorities or OKRs to align against: [LIST — or "not specified"]
- Technical constraints the design team is working within: [OR "none specified"]

You are a senior UX writer. Rewrite the error messages below to be clear, friendly, and genuinely helpful — without being condescending or overly casual. For each error message, provide: the rewritten message (headline + 1–2 sentence explanation where needed), the action the user should take next (written as a specific, actionable instruction — not "please try again"), and a brief rationale note explaining what was wrong with the original and what the rewrite fixes. Follow these principles: tell the user what happened and why (in plain language — no technical jargon), tell them what to do next (a specific action, not a vague direction), own the problem on behalf of the product where appropriate (avoid "You did X wrong"), match the product's voice and tone, and keep it as short as possible while remaining helpful. If an error message exposes sensitive system information (stack traces, internal error codes), flag it and provide a sanitised version.

ERROR MESSAGES TO REWRITE:
- Original error messages: [PASTE EACH ONE ON A SEPARATE LINE]
- Product type: [WEB APP / MOBILE APP / SaaS / E-COMMERCE / OTHER]
- Context (where these errors appear): [CHECKOUT FLOW / ONBOARDING / FORM SUBMISSION / LOGIN / etc.]
- Brand voice characteristics: [e.g., "professional but approachable, no slang, second person" — or "match the product name above and infer from context"]
- Audience: [DESCRIBE USER BASE — technical level, familiarity with the product]
- Any platform-specific constraints (character limits, tone guidelines): [OR "none"]

You are a senior UX writer. Write a complete onboarding tooltip copy set for the product and feature area described below. For each tooltip, provide: the trigger element (what the user is hovering over or what has just appeared), the tooltip headline (5–8 words max — action-oriented or benefit-led), the tooltip body (1–2 sentences max — what this does and why it matters to the user right now), and a CTA label if the tooltip includes an action button (e.g., "Got it", "Show me", "Try it now" — choose based on context, not convention). The full set should feel like a guided narrative, not a disconnected collection of feature explanations — each tooltip should build on the previous and move the user toward their first meaningful moment of value. Flag any tooltips where the UX copy is doing work the UI should be doing (i.e., anything that requires more than 2 sentences to explain signals a design problem, not a copy problem).

PRODUCT & FEATURE DETAILS:
- Product name and type: [NAME, TYPE — e.g., "Frameloop, a video feedback tool for agencies"]
- Feature area being onboarded: [e.g., "creating and sharing a project review link"]
- User segment being onboarded: [e.g., "first-time users who signed up via a referral"]
- The "aha moment" this onboarding sequence should drive toward: [DESCRIBE — e.g., "sharing their first review link and receiving a comment"]
- Number of tooltips in the sequence: [NUMBER — or "suggest based on feature complexity"]
- Brand voice: [DESCRIBE — e.g., "direct, low-fluff, slightly playful — think Notion meets Linear"]
- Any UI elements that need a tooltip regardless: [LIST SPECIFIC ELEMENTS — or "cover the full onboarding flow"]

You are a senior UX writer and product designer. Write empty state copy for the dashboard screens described below. For each empty state, provide: a headline (outcome-oriented, not "Nothing here yet" — tell them what they'll see when it's populated), a supporting body line (1 sentence: why the state is empty + a hint of what's possible once it's filled), and a primary CTA label (the single most important action the user should take from this state — make it specific and benefit-led, not generic). Also provide: a secondary option if relevant (e.g., a link to docs, a sample view, or an import option), and a brief design note on the illustration or icon direction that would complement the copy (optional but useful for handoff). Empty states are one of the highest-leverage UX writing opportunities in any product — they should motivate action, not apologise for emptiness. Avoid "Nothing to see here", "No data yet", and any copy that makes the empty state feel like a failure state.

DASHBOARD CONTEXT:
- Product name and type: [NAME, TYPE]
- Empty states to cover: [LIST EACH SCREEN / WIDGET / MODULE — e.g., "Projects list, Notifications panel, Analytics chart, Team members section"]
- User context (when they see this empty state): [e.g., "just signed up and haven't created anything yet" / "filtered results returned nothing" / "team feature not yet activated"]
- The first action that would fill this state: [DESCRIBE — e.g., "create a project", "invite a team member", "connect a data source"]
- Brand voice: [DESCRIBE — or paste a voice/tone excerpt from your brand guidelines]
- Audience: [WHO IS USING THIS DASHBOARD — role, experience level]

You are a senior UX writer with conversion copywriting expertise. Write 3 copy variants for each CTA button described below. For each variant, provide: the button label (2–5 words maximum — action verb + outcome or object), the psychological mechanism it uses (e.g., urgency, specificity, benefit-led, risk reduction, social proof signal), the context where this variant performs best (type of user, stage of journey, placement on screen), and a brief rationale (1–2 sentences) explaining why this copy is more effective than a generic label like "Submit" or "Get Started". After the 3 variants per CTA, give a recommendation on which to test first and why. Apply these principles: start with a verb (not a noun), be specific about the outcome the user gets (not the action they take), match the commitment level of the action (low-commitment language for early funnel, confident language for high-intent moments), and avoid false urgency or dark patterns.

CTA DETAILS:
- CTAs to write variants for: [LIST EACH BUTTON — e.g., "primary sign-up CTA on homepage", "upgrade button on pricing page", "submit button on contact form"]
- Product type: [DESCRIBE]
- User segment seeing this CTA: [WHO IS THIS AUDIENCE — awareness level, intent level]
- What happens immediately after clicking: [DESCRIBE THE NEXT STEP]
- What the user is hesitant about (the friction): [e.g., "they're not sure if it's free", "they don't want to give a credit card", "they're unsure if it's relevant to their role"]
- Brand voice: [DESCRIBE — e.g., "confident, direct, minimal"]
- Any character limits or button size constraints: [OR "none"]

You are a senior UX designer. Write a design decision rationale document for the design decision described below. The document should include: a Decision Summary (1–2 sentences: what was decided and for which feature or flow), the Problem Statement (what user or business problem this decision addresses), the Options Considered (list each option explored with a 2–3 sentence description and its pros and cons — minimum 2 alternatives to the chosen direction), the Decision (which option was selected and by whom), the Rationale (why this option was chosen over the alternatives — reference research data, design principles, business constraints, or technical limitations), the Trade-offs Accepted (what was knowingly given up by making this decision), and the Open Questions (anything still unresolved or dependent on future data). Write this as a living document that a designer who joins the team in 12 months can read and understand why the product works the way it does — not as a justification of what was already built.

DECISION DETAILS:
- Feature or flow: [DESCRIBE]
- Product: [NAME / TYPE]
- Decision made: [DESCRIBE THE CHOSEN DIRECTION]
- Alternatives considered: [LIST — or "describe and the AI will infer alternatives"]
- Primary rationale for choosing this direction: [KEY REASONS]
- Research or data that informed this decision: [REFERENCE — or "intuition / heuristics if no formal research"]
- Trade-offs or compromises made: [DESCRIBE]
- Decision date and key stakeholders involved: [DATE, NAMES / ROLES]

You are a senior UX designer and design systems specialist. Write developer handoff annotations for the UI components described below. For each component, provide: a Component Name (the exact name to use in the codebase — align with the design system naming convention if specified), a Description (what this component does, where it's used, and what problem it solves), a Variants & States section (list every variant, state, and interactive behaviour — default, hover, focus, active, disabled, loading, error, empty — with a note on what triggers each state change), a Content & Constraints section (character limits, required vs. optional content, fallback behaviour for truncated text, minimum and maximum sizes), an Interaction Notes section (specific animation, transition, and micro-interaction details that aren't visible in static frames), an Accessibility section (keyboard navigation behaviour, ARIA roles and labels, focus management, colour contrast requirements), and a Design Token Mapping (which tokens map to which visual properties — colours, spacing, typography, radius — using the token names from the design system). Flag any component that has ambiguous states or missing designs.

COMPONENT DETAILS:
- Components to annotate: [LIST EACH COMPONENT — e.g., "Primary Button, Search Input, Notification Toast, Data Table Row"]
- Design system or token library in use: [NAME — or "none, use generic descriptors"]
- Platform: [WEB / iOS / ANDROID / CROSS-PLATFORM]
- Key interactive behaviours to document: [DESCRIBE — or "cover all states above"]
- Any known implementation complexity or edge cases: [FLAG — or "none flagged"]
- Developer audience: [e.g., "React frontend engineers, familiar with Tailwind CSS" — or "general frontend"]

You are a senior UX designer with accessibility expertise. Create a comprehensive accessibility annotation checklist and annotation set for the design file described below. The output should include two parts: Part 1 — Annotation Checklist: a complete list of every accessibility annotation that should exist on this design (grouped by category: Semantic Structure, Keyboard Navigation, Focus Management, Screen Reader Behaviour, Colour & Contrast, Motion & Animation, and Error Handling). For each checklist item, note whether it's required for WCAG 2.1 AA compliance or a best-practice recommendation. Part 2 — Annotations: the actual annotation text for each UI element in the described design (or the most common annotation patterns for this type of screen). Each annotation should include the element, the ARIA role/label/attribute to apply, the keyboard behaviour, and any screen reader announcement text. Flag any designs that require developer decisions (e.g., dynamic content updates, complex interactions) and note where code review is needed alongside the design review.

DESIGN DETAILS:
- Screen or component to annotate: [DESCRIBE — e.g., "modal dialog with a form and a close button" / "data table with sortable columns and row actions"]
- Platform: [WEB / iOS / ANDROID]
- WCAG target level: [A / AA / AAA — default to AA if unspecified]
- Key interactive elements (list all buttons, links, inputs, and dynamic content): [LIST]
- Any known accessibility issues or constraints: [FLAG — or "none identified yet"]
- Design system in use (so annotations use correct token/component names): [NAME — or "none"]
- Primary assistive technology target: [SCREEN READER / KEYBOARD ONLY / BOTH / ALL]

You are a senior UX designer and design lead. Write a complete design review presentation outline for the design work described below. The outline should include: a slide-by-slide structure with the content goal for each slide (not just the topic — what the audience needs to understand or decide by the end of that slide), the narrative arc for the presentation (how to move from context through problem framing, design exploration, chosen direction, validation data, and next steps without losing a non-designer audience), talking points for each section (3–5 bullet points per major slide), likely questions or objections from each stakeholder type present (engineering, product, business) and how to address them preemptively, and a clear "decision required" or "feedback requested" framing at the end of each major design section (so stakeholders know their role is to decide or advise, not just observe). Also include a pre-read summary (100 words max) to send stakeholders 24 hours before the review.

REVIEW DETAILS:
- Design work being reviewed: [DESCRIBE — e.g., "redesigned onboarding flow for B2B SaaS product"]
- Stage of design: [CONCEPT / REFINED / READY FOR BUILD]
- Audience and stakeholders: [LIST ROLES — e.g., "Head of Product, Engineering Lead, CEO, Customer Success Manager"]
- What decision needs to be made in this review: [DESCRIBE THE REQUIRED OUTCOME]
- Key design alternatives that were explored: [LIST — or "single direction being presented"]
- Research or validation data available to reference: [DESCRIBE — or "no formal research, intuition-led so far"]
- Time available for the presentation: [LENGTH]
- Format: [IN-PERSON / REMOTE / ASYNC VIDEO]

You are a design lead and facilitator. Create a structured design critique agenda for the session described below. The agenda should include: a Pre-Session setup section (how to brief participants in advance, what to share, and how to frame their role as critics vs. decision-makers — 15–20 minutes before the session), an Opening section (how to set the stage, establish critique norms, and clarify the specific feedback the designer needs — 5 minutes), a Presentation section (how the designer should present the work — context first, then constraints, then design — before opening to feedback — 10–15 minutes), a Structured Critique section (a facilitation protocol for gathering high-quality feedback: silent review, observation round, question round, and recommendation round — 20–30 minutes), a Synthesis section (how to close with prioritised feedback and clear next steps — 10 minutes), and a Post-Session section (how to document and share the critique outcomes). Include specific facilitation prompts for redirecting unhelpful feedback ("I don't like it" / "Can we just do X?") back to design principles and user needs. Time allocations should fit the total session length provided.

CRITIQUE DETAILS:
- Design work being critiqued: [DESCRIBE]
- Stage of design: [EARLY CONCEPT / REFINED / PRE-PRODUCTION]
- Total session length: [e.g., 60 MINUTES / 90 MINUTES]
- Number of participants: [NUMBER — include role types]
- Specific feedback the designer needs from this critique: [e.g., "is the information hierarchy clear?", "does the proposed flow reduce the current drop-off?"]
- Known tendencies in this team's critique culture: [e.g., "tendency to jump to solutions", "HiPPO problem — senior voices dominate", "too polite, not enough honest feedback" — or "standard team dynamics"]
- Format: [IN-PERSON / REMOTE (FIGMA / MIRO / SLIDES)]

You are a senior UX designer and design strategist. Write an executive summary for the design proposal described below. The summary should be written for a non-designer executive audience — it should be jargon-free, business-outcome focused, and readable in under 3 minutes. Include: a Problem Statement (the user and business problem being solved — quantify impact where possible), a Proposed Solution (what the design addresses and how — no UX jargon), the Evidence Base (what research, data, or competitive benchmarks support this direction), the Expected Outcomes (specific, measurable business and user outcomes — not "improved UX" but "reduce task completion time from 4 minutes to under 90 seconds"), the Investment Required (design time, engineering effort, and any dependencies — be honest about scope), the Risks and Mitigations (what could go wrong and how the team is managing it), and the Decision / Action Required from the audience (specific and time-bound). The executive summary should make the business case for the design investment without requiring the reader to look at a single wireframe to understand the value.

PROPOSAL DETAILS:
- Design proposal description: [DESCRIBE THE WORK AND ITS SCOPE]
- Product and user context: [DESCRIBE]
- Business problem being solved: [QUANTIFY IF POSSIBLE — e.g., "28% drop-off at the payment step"]
- Proposed solution direction: [DESCRIBE]
- Supporting research or data: [PASTE OR SUMMARISE]
- Estimated effort: [DESIGN WEEKS + ENGINEERING ESTIMATE — or "TBD"]
- Expected business outcomes: [LIST — or "frame as hypotheses to be validated"]
- Audience for this summary: [EXECUTIVE ROLES — e.g., "CEO, CFO, VP Product"]
- Decision deadline: [DATE — or "next design review on [DATE]"]

You are a product designer and experimentation specialist. Write a structured A/B test hypothesis statement for the design change described below. Use the format: "We believe that [DESIGN CHANGE] for [TARGET USER SEGMENT] will result in [PRIMARY METRIC CHANGE] because [RATIONALE FROM RESEARCH OR DATA]." Then expand into a full hypothesis document including: the Test Name (short, descriptive — for use in the experiment tracking tool), the Control (describe the current state clearly), the Variant (describe the proposed change specifically), the Primary Metric (the single metric this test is designed to move — be precise: "7-day activation rate" not just "activation"), Secondary Metrics to Monitor (signals that indicate the change is working beyond the primary metric — and guardrail metrics that would indicate unintended harm), the Rationale (why you believe this change will produce the expected outcome — reference research, heuristics, or prior experiment data), the Minimum Detectable Effect (what % change would be meaningful enough to act on), and the Estimated Sample Size and Duration (based on current traffic if provided — or a placeholder calculation).

EXPERIMENT DETAILS:
- Design change being tested: [DESCRIBE THE VARIANT]
- Page or flow: [WHERE IN THE PRODUCT]
- Target user segment: [WHO WILL SEE THIS TEST]
- Primary metric to improve: [SPECIFIC METRIC WITH CURRENT BASELINE IF KNOWN]
- Rationale for the change (research, data, heuristics): [DESCRIBE]
- Current traffic or session volume: [NUMBER PER WEEK / MONTH — or "unknown"]
- Business context: [WHY THIS METRIC MATTERS NOW]
- Any risks or guardrail metrics to monitor: [LIST — or "standard conversion and engagement metrics"]

You are a UX lead and design strategist. Create a design impact metrics framework for the product and team described below. The framework should include: a Metric Hierarchy (organise metrics across three levels — Business Outcomes, Product Performance, and UX Quality — showing how UX metrics connect upward to business KPIs), a Core UX Metrics Set (the 5–8 most important metrics to track for this product, with definition, measurement method, target benchmark, and current baseline if known), a Leading vs. Lagging Indicators section (which metrics predict future business outcomes vs. confirm past decisions — and why this distinction matters for the team), a Measurement Cadence (when to measure each metric — per sprint, monthly, quarterly, or event-triggered), a Reporting Template (how to present these metrics to different audiences: design team, product team, and executives), and an Anti-Metrics section (3–4 metrics that look good but are misleading for this type of product — e.g., time-on-site for a task-completion product — and what to use instead). The framework should be usable by a design team without a dedicated data analyst.

PRODUCT & TEAM DETAILS:
- Product type: [DESCRIBE — e.g., "B2B SaaS project management tool"]
- Primary user goal: [WHAT DOES THE USER COME TO DO]
- Business model: [SUBSCRIPTION / TRANSACTIONAL / USAGE-BASED / OTHER]
- Stage of product: [EARLY / GROWTH / MATURE]
- Current metrics tracked (if any): [LIST — or "none formally tracked yet"]
- Key design goals for this quarter: [e.g., "improve onboarding activation", "reduce support tickets from UI confusion", "increase feature discovery"]
- Available data sources: [e.g., "Mixpanel, Hotjar, Intercom, quarterly NPS survey" — or "limited — Google Analytics only"]
- Team size and composition: [DESIGN TEAM SIZE + KEY STAKEHOLDERS]