ChatGPT Prompts for Product Designers

<context> I am kicking off design for [FEATURE] on [PRODUCT], serving [USER]. Stakeholders are PM, eng lead, and marketing. I need a crisp brief to align everyone. </context> <task> 1. Draft a one-page design brief with these sections: Problem, Target user, Success metrics, Scope, Out of scope, Constraints, Open questions. 2. Keep each section to 2-4 bullet points, written for a mixed audience. 3. Phrase success metrics as measurable outcomes, not features. 4. End with a single sentence stating the design hypothesis we are testing. </task>

<context> We are designing [FEATURE] for [PRODUCT]. Leadership wants to know how we will measure success for [USER], but we only have a vague goal: 'improve engagement.' </context> <task> 1. Translate 'improve engagement' into 4-6 specific, measurable metrics tied to [FEATURE]. 2. For each metric, give a definition, a data source, and a sensible target direction. 3. Separate leading indicators from lagging indicators. 4. Recommend the single North Star metric and one guardrail metric to prevent gaming it. </task>

<context> I am about to brief [FEATURE] for [PRODUCT]. The stakeholders are [LIST ROLES]. They have competing priorities and I want to anticipate friction. </context> <task> 1. For each stakeholder role, infer their likely top priority and their biggest concern about [FEATURE]. 2. Identify the 2 most likely points of conflict between stakeholders. 3. Suggest framing for the brief that pre-empts each conflict. 4. Draft one alignment question to ask each stakeholder before design starts. </task>

<context> The brief for [FEATURE] on [PRODUCT] has grown too big to ship this quarter. I need to cut scope without losing the core value for [USER]. </context> <task> 1. Separate the brief into must-have, should-have, and could-have using MoSCoW. 2. Define the smallest version that still delivers the core user value (the walking skeleton). 3. List what we defer and the explicit risk of deferring each item. 4. Propose a phased rollout: v1 now, v1.1 next, with the trigger for each phase. </task>

<context> Before designing [FEATURE] for [PRODUCT], I want to ground the brief in how competitors handle the same job for [USER]. Key competitors: [LIST COMPETITORS]. </context> <task> 1. For each competitor, summarize how they solve the job [FEATURE] addresses (use general knowledge, flag uncertainty). 2. Identify the table-stakes elements we must match. 3. Identify 2 gaps or weaknesses we could exploit as differentiation. 4. Recommend one positioning angle for the brief and the design decision it implies. </task>

<context> I am mapping the flow for [USER] completing the core task of [FEATURE] in [PRODUCT]. I want a complete happy-path flow before I touch Figma. </context> <task> 1. List every step from entry point to task completion as a numbered sequence. 2. For each step, note the user goal, the screen or surface, and the primary action. 3. Mark decision points where the flow branches. 4. Identify the single step most likely to cause drop-off and why. </task>

<context> I have designed the happy path for [FEATURE] in [PRODUCT] for [USER]. Before handoff I need to cover edge cases and error states. </context> <task> 1. Enumerate edge cases across these categories: empty states, error states, permission/auth, network failure, and extreme inputs. 2. For each edge case, describe the trigger and the ideal user-facing behavior. 3. Recommend the message or microcopy the user should see. 4. Prioritize which edge cases must be designed for v1 versus deferred. </task>

<context> I want a journey map for [USER] adopting [FEATURE] in [PRODUCT], spanning awareness to habitual use, not just a single session. </context> <task> 1. Break the journey into stages: Awareness, First use, Activation, Habit, Advocacy. 2. For each stage describe the user goal, emotional state, and key touchpoint. 3. Identify the biggest friction or doubt at each stage. 4. Suggest one design intervention per stage to move the user forward. </task>

<context> I am restructuring the navigation of [PRODUCT] to better support [FEATURE] for [USER]. Current sections are: [LIST SECTIONS]. </context> <task> 1. Propose a cleaner IA, grouping content by user mental model rather than internal team structure. 2. Show the proposed nav as a labeled hierarchy (max 3 levels deep). 3. Explain each major grouping decision in one sentence. 4. Flag any current label that is jargon and suggest a clearer user-facing term. </task>

<context> New [USER] sign up for [PRODUCT] but drop off before experiencing the value of [FEATURE]. I need an onboarding flow that gets them to first value fast. </context> <task> 1. Define the single 'aha moment' for [FEATURE] and the shortest path to it. 2. Design a step-by-step onboarding flow with the minimum steps needed to reach that moment. 3. For each step, specify the goal, what to show, and what to defer. 4. Recommend where to use progressive disclosure versus required input. </task>

<context> I am specifying the interactions for [FEATURE] in [PRODUCT] so I can build a high-fidelity prototype. The key component is [DESCRIBE COMPONENT]. </context> <task> 1. Write a detailed interaction spec for the component: default, hover, active, focus, disabled, loading, and error states. 2. For each state, describe the visual change and the trigger. 3. Specify transition timing and easing recommendations. 4. Note any accessibility behavior (keyboard, screen reader, focus order) for each state. </task>

<context> I want to add a delightful but purposeful microinteraction to [FEATURE] in [PRODUCT] for [USER]. The trigger is [DESCRIBE ACTION]. </context> <task> 1. Propose 3 microinteraction concepts for this trigger, each with a clear functional purpose (not decoration). 2. For each, describe the feedback, the animation, and the duration. 3. Explain the user benefit and the risk of overdoing it. 4. Recommend the one most appropriate for our context and why. </task>

<context> I am building a [COMPONENT] for the [PRODUCT] design system, used across [FEATURE]. I need to define its full variant matrix before building in Figma. </context> <task> 1. Define the relevant properties for this component (e.g. size, variant, state, icon). 2. Produce the full variant matrix as a table of property combinations. 3. Flag combinations that are invalid or should be blocked. 4. Recommend sensible defaults for each property. </task>

<context> I have a clickable prototype of [FEATURE] in [PRODUCT] and need to run unmoderated usability tests with 5 [USER] participants. </context> <task> 1. Write a test plan with a clear objective and 3-4 realistic tasks for [FEATURE]. 2. Phrase each task as a goal scenario, not as instructions that reveal the UI. 3. Add a short pre-test screener and 3 post-task questions. 4. Define the success criteria and what observations would invalidate the design. </task>

<context> The [FEATURE] screen in [PRODUCT] must work across mobile, tablet, and desktop for [USER]. I need to spec the responsive behavior before prototyping. </context> <task> 1. For each breakpoint (mobile, tablet, desktop), describe the layout and what changes from the previous size. 2. Specify which elements reflow, stack, hide, or collapse into menus. 3. Define touch-target and spacing rules for the smallest breakpoint. 4. Flag the single element most at risk of breaking responsively and propose a fallback. </task>

<context> I want a structured critique of my [FEATURE] design in [PRODUCT] for [USER]. I will describe the screens and key interactions below: [DESCRIBE DESIGN]. </context> <task> 1. Evaluate the design against Nielsen's 10 usability heuristics. 2. For each heuristic, state whether it is met, partially met, or violated, with a specific reason. 3. Rank the violations by severity (cosmetic, minor, major, catastrophic). 4. Give one concrete fix for each major or catastrophic issue. </task>

<context> I am attached to my current direction for [FEATURE] in [PRODUCT] and want someone to poke holes before I present it. Here is the design and my rationale: [DESCRIBE]. </context> <task> 1. Argue the strongest case AGAINST this design direction. 2. Identify the 3 assumptions it relies on that could be wrong. 3. Describe a realistic scenario where [USER] would be frustrated or confused. 4. Suggest the single change that would most de-risk the design. </task>

<context> I need to audit my [FEATURE] design in [PRODUCT] for accessibility before handoff. The design is described here: [DESCRIBE DESIGN AND COLORS]. </context> <task> 1. Check the design against WCAG 2.2 AA for color contrast, focus, target size, and text alternatives. 2. List each likely violation with the specific guideline number. 3. Recommend a fix for each, with concrete values where relevant (e.g. contrast ratio targets). 4. Flag anything that needs real assistive-tech testing rather than a desk review. </task>

<context> I want to tighten the UX writing in [FEATURE] of [PRODUCT] for [USER]. Here is all the current copy: [PASTE COPY]. </context> <task> 1. Critique each string for clarity, length, tone, and action-orientation. 2. Rewrite each weak string, keeping our voice consistent. 3. Flag any jargon, hedging, or vague CTAs and replace them. 4. Ensure button labels describe the outcome, not the mechanism. </task>

<context> A stakeholder is pushing back on a design decision I made for [FEATURE] in [PRODUCT]. My decision: [DECISION]. Their objection: [OBJECTION]. </context> <task> 1. Steelman the stakeholder's objection so I fully understand it. 2. Lay out the strongest design rationale for my decision, grounded in user needs and principles. 3. Identify any valid point in their objection I should incorporate. 4. Draft a calm, evidence-based response I can say in the meeting. </task>

<context> I am handing off [FEATURE] of [PRODUCT] to engineering. I need a complete spec document so developers can build without back-and-forth. </context> <task> 1. Generate a handoff spec with sections: Overview, User flow, Screens and states, Component list, Interaction behavior, Edge cases, and Acceptance criteria. 2. Write acceptance criteria in clear given/when/then format. 3. Note any dependencies, API needs, or open questions for eng. 4. Keep it scannable with headings and bullets, not walls of text. </task>

<context> I need to document the design tokens used in [FEATURE] of [PRODUCT] so engineering applies them consistently. My values are: [PASTE COLORS, SPACING, TYPE]. </context> <task> 1. Organize my raw values into a token structure: color, spacing, typography, radius, shadow. 2. Propose semantic token names (e.g. color-surface-primary) mapped to my raw values. 3. Flag any inconsistent or one-off values that should be normalized. 4. Output the tokens in a clean table ready for the design system doc. </task>

<context> The [FEATURE] design in [PRODUCT] is ready and I need precise acceptance criteria so QA and eng know exactly what 'done' means for [USER]. </context> <task> 1. Write acceptance criteria for every screen and key interaction in given/when/then format. 2. Include criteria for edge cases, error states, and empty states. 3. Add accessibility acceptance criteria (keyboard, focus, contrast). 4. Flag any criterion that is ambiguous and needs a product decision before build. </task>

<context> Before I hand off [FEATURE] of [PRODUCT] to engineering, I want to anticipate the questions developers will ask so I can answer them in the spec. </context> <task> 1. List the 10 most likely questions a frontend developer would ask about this design. 2. Group them by theme: data, states, interaction, responsive, and edge cases. 3. For each, note what I should add to the spec to pre-empt it. 4. Highlight the 3 questions that, if unanswered, would most likely block the build. </task>

<context> Engineering has built [FEATURE] for [PRODUCT] from my designs. I need to do a design QA review of the implementation against the spec for [USER]. </context> <task> 1. Generate a design QA checklist covering visual fidelity, spacing, typography, states, interactions, and responsive behavior. 2. Add a section for accessibility checks and one for motion/animation timing. 3. Phrase each item as a yes/no check I can run quickly against the live build. 4. Recommend a severity label for each item so I can triage what blocks release. </task>