ChatGPT Prompts for UX Designers

<context> I have research insights about [USER] who use [PRODUCT]. I will paste key findings. I want a behavioral persona grounded in data, not demographic stereotypes. </context> <task> 1. Wait for my research findings, then build a single primary persona. 2. Include goals, motivations, behaviors, frustrations, context of use, and a representative quote. 3. Anchor every persona attribute to a specific finding I provided and note where evidence is thin. 4. Avoid demographic filler that does not affect design decisions. 5. Add a short 'design implications' section translating the persona into 3 actionable UX priorities. </task>

<context> I am mapping how [USER] currently completes [FLOW] with [PRODUCT], including the messy parts before and after they touch our product. </context> <task> 1. Break [FLOW] into 5-8 sequential stages from trigger to outcome. 2. For each stage, describe user actions, thoughts, emotions, touchpoints, and pain points. 3. Plot an emotional curve and call out the lowest moments. 4. Identify the 3 highest-impact friction points and the evidence behind each. 5. Suggest one opportunity per top friction point. </task>

<context> I want to design an improved experience for [USER] completing [FLOW] in [PRODUCT]. I have the current-state pain points and want a credible future-state vision. </context> <task> 1. Re-imagine each stage of [FLOW] showing the ideal user actions, emotions, and touchpoints. 2. For each improvement, name the friction it removes and the design move that enables it. 3. Keep the vision realistic for a mid-size product team, not science fiction. 4. Highlight 3 quick wins versus 2 larger bets. 5. Note assumptions that must be validated before building. </task>

<context> I need an empathy map for [USER] interacting with [PRODUCT] during [FLOW] to align my team on the user's perspective. </context> <task> 1. Produce a four-quadrant empathy map: Says, Thinks, Does, Feels. 2. Populate each quadrant with 4-6 specific, research-grounded entries. 3. Add a Pains and a Gains section beneath the quadrants. 4. Flag any entry that is an assumption versus an observed behavior. 5. End with 3 design questions the empathy map raises. </task>

<context> I have a persona for [USER] of [PRODUCT] with known pains around [FLOW]. I want to connect those pains to potential features without over-promising. </context> <task> 1. List the persona's top 5 pains in priority order. 2. For each pain, propose 1-2 feature or design ideas that directly address it. 3. Rate each idea on user impact and rough effort (high/medium/low). 4. Recommend which ideas to validate first and how. 5. Flag any feature that solves a problem the persona does not actually have. </task>

<context> I am about to wireframe a screen in [PRODUCT] where [USER] performs [FLOW]. I want a clear brief before I open the design tool so the layout serves the task. </context> <task> 1. Define the screen's primary goal and the single most important user action. 2. List required content and UI elements in priority order. 3. Recommend a layout structure and visual hierarchy from most to least important. 4. Note states to design: empty, loading, error, and success. 5. List 3 usability risks for this screen and how the layout can mitigate them. </task>

<context> I am organizing the navigation and content structure of [PRODUCT] so [USER] can easily complete [FLOW] and find related tasks. </context> <task> 1. Propose a top-level navigation with 4-7 primary categories and rationale for each. 2. Outline a sitemap two levels deep showing where key flows live. 3. Apply clear, user-language labels and avoid internal jargon. 4. Flag any content that could belong in multiple places and recommend a home. 5. Suggest a card-sort study to validate the structure with real users. </task>

<context> I need to map the step-by-step user flow for [USER] completing [FLOW] in [PRODUCT], including decision points and error paths. </context> <task> 1. Lay out the happy-path flow as a numbered sequence of screens and actions. 2. Mark every decision point and branch with its condition. 3. Add error and recovery paths for the most likely failure points. 4. Identify steps that could be removed or combined to reduce friction. 5. Output the flow in a format I can recreate in a flow-diagram tool. </task>

<context> I have a content-heavy screen in [PRODUCT] for [USER] doing [FLOW] and I need to decide what to show, hide, or defer. </context> <task> 1. Classify each content element as essential, supporting, or optional for the primary task. 2. Recommend what belongs above the fold versus progressively disclosed. 3. Suggest where to use scanning patterns, grouping, or summarization. 4. Identify content that adds cognitive load without aiding the task. 5. Provide a prioritized content order for both mobile and desktop. </task>

<context> I am designing [FLOW] in [PRODUCT] for [USER] across mobile, tablet, and desktop and want a responsive layout strategy before wireframing. </context> <task> 1. Recommend a layout approach for each breakpoint and what changes between them. 2. Specify how navigation, primary actions, and content reflow per device. 3. Identify touch-target, thumb-reach, and readability considerations for mobile. 4. Note any element that should be hidden, collapsed, or reordered on small screens. 5. List the 3 most likely responsive bugs to test for. </task>

<context> I am running a moderated usability test of [PRODUCT] where [USER] attempts [FLOW]. I need a script that produces clean, comparable observations across sessions. </context> <task> 1. Write an intro that sets a think-aloud expectation and reassures the participant we are testing the product, not them. 2. Create 4-6 realistic, scenario-based tasks for [FLOW] with clear success criteria. 3. Keep task wording neutral so it does not reveal the path or hint at the answer. 4. Add probing follow-up questions to ask after each task. 5. End with post-test rating questions and an open debrief. </task>

<context> I am doing an expert review of [FLOW] in [PRODUCT] used by [USER] and want to apply Nielsen's 10 heuristics systematically. </context> <task> 1. For each of the 10 usability heuristics, list 2-3 concrete checks specific to [FLOW]. 2. Provide a severity scale (0-4) with definitions for rating any issue found. 3. Suggest where each heuristic most commonly breaks in flows like this. 4. Give me a table to log issue, heuristic, severity, location, and recommendation. 5. Recommend how to convert findings into a prioritized fix list. </task>

<context> I finished usability testing [PRODUCT] on [FLOW] with [USER] and have observations to turn into a credible, stakeholder-friendly report. </context> <task> 1. Wait for my raw observations, then group them into prioritized findings. 2. For each finding, state the issue, evidence, affected users, severity, and a recommended fix. 3. Lead with an executive summary of the top 3 issues and overall task success. 4. Separate must-fix issues from nice-to-haves. 5. Keep tone objective and avoid blaming users or designers. </task>

<context> I want a first-pass accessibility review of [FLOW] in [PRODUCT] for [USER], aligned to WCAG 2.2 AA before a formal audit. </context> <task> 1. List the most relevant WCAG 2.2 AA checks for this flow across perceivable, operable, understandable, and robust. 2. For each check, describe how to test it manually and what failure looks like. 3. Highlight common issues for forms, color contrast, focus order, and keyboard navigation. 4. Recommend assistive-tech scenarios (screen reader, keyboard-only) to walk through. 5. Output a checklist I can run in under an hour. </task>

<context> I suspect a friction point in [FLOW] within [PRODUCT] is hurting [USER] completion and want to design a sound A/B test. </context> <task> 1. Help me turn the suspected problem into a clear, falsifiable hypothesis. 2. Define the primary metric, guardrail metrics, and what success looks like. 3. Propose a control and 1-2 variant concepts that isolate one change each. 4. Note sample-size and duration considerations at a high level. 5. List confounds or biases that could invalidate the result. </task>

<context> I will describe or paste a design for [FLOW] in [PRODUCT] used by [USER] and want a structured, constructive critique rather than vague opinions. </context> <task> 1. Wait for my design description, then critique it against clarity, hierarchy, consistency, accessibility, and task fit. 2. For each issue, explain the underlying UX principle and the likely user impact. 3. Separate critical problems from minor polish items. 4. Offer at least one concrete improvement per issue, not just criticism. 5. Note what the design does well so feedback stays balanced. </task>

<context> I need to give a teammate critique on their work for [PRODUCT] and [FLOW]. I have rough notes and want to deliver them constructively without crushing morale. </context> <task> 1. Wait for my raw feedback notes, then reframe each into clear, kind, specific language. 2. Use a what-I-observe, why-it-matters, what-I-suggest structure. 3. Tie feedback to user impact and shared goals, not personal taste. 4. Phrase subjective points as questions or options rather than mandates. 5. Keep a respectful, collaborative tone throughout. </task>

<context> Before I share my design for [FLOW] in [PRODUCT] with [USER], I want to pressure-test it myself and catch weaknesses early. </context> <task> 1. Generate a self-critique checklist covering user goal fit, hierarchy, edge cases, and accessibility. 2. Ask me pointed questions a senior designer would raise in review. 3. Identify the 3 most likely objections stakeholders will have and how to pre-empt them. 4. Surface assumptions baked into the design that I should validate. 5. Suggest what evidence to bring to defend key decisions. </task>

<context> I made specific design choices for [FLOW] in [PRODUCT] and need to explain the rationale clearly to [USER] stakeholders who may push back. </context> <task> 1. Wait for me to list my key decisions, then articulate the reasoning behind each. 2. Tie each decision to user needs, research, or a UX principle. 3. Acknowledge trade-offs and explain why the chosen path wins. 4. Prepare a concise response to the 3 most likely counterarguments. 5. Keep explanations jargon-free for non-designers. </task>

<context> I want to critique how competitors handle [FLOW] to inform my design for [PRODUCT] and [USER], focusing on what to learn rather than copy. </context> <task> 1. Wait for me to describe 1-3 competitor experiences for [FLOW]. 2. Evaluate each on usability, clarity, and how well it serves the user goal. 3. Identify patterns worth adopting and anti-patterns to avoid. 4. Note where a competitor strength may not transfer to our context. 5. Summarize 3 actionable takeaways for my own design. </task>

<context> I am documenting a component in [PRODUCT]'s design system so [USER] designers and engineers use it correctly within [FLOW]. </context> <task> 1. Wait for me to describe the component, then write its documentation. 2. Include purpose, anatomy, variants, states, and props or options. 3. Add do and don't usage guidelines with rationale. 4. Specify accessibility requirements (roles, labels, keyboard behavior). 5. Provide concrete example use cases and when to choose a different component. </task>

<context> I am defining or auditing design tokens for [PRODUCT] and want a scalable, semantic naming convention the team can follow. </context> <task> 1. Propose a token naming structure (category, concept, property, variant) with examples. 2. Recommend semantic over literal names and explain why. 3. Cover color, spacing, typography, radius, and elevation tokens. 4. Show how tokens map from primitive to semantic to component levels. 5. Flag common naming pitfalls that cause confusion at scale. </task>

<context> I want clear usage guidelines for a recurring UX pattern in [PRODUCT] so [USER] designers apply it consistently across [FLOW]. </context> <task> 1. Wait for me to name the pattern, then define when to use it and when not to. 2. Describe the standard behavior, content rules, and interaction states. 3. Provide best-practice examples and common misuse examples. 4. Note accessibility and responsive considerations. 5. List related patterns and how to choose between them. </task>

<context> I am defining UX writing rules for [PRODUCT] so microcopy across [FLOW] feels consistent for [USER]. I want practical guidance, not abstract brand fluff. </context> <task> 1. Define voice and tone with 3-4 concrete adjectives and what each means in practice. 2. Give rules for buttons, error messages, empty states, and confirmations with examples. 3. Provide before-and-after rewrites that show the rules applied. 4. Cover capitalization, person, tense, and punctuation conventions. 5. List words and phrases to avoid and their preferred alternatives. </task>

<context> I am handing off [FLOW] in [PRODUCT] to engineering and want a clear spec so [USER]-facing behavior is built exactly as designed. </context> <task> 1. Wait for me to describe the screens, then produce a handoff spec outline. 2. Document layout, spacing, components used, and which design tokens apply. 3. Specify all states: default, hover, focus, active, disabled, loading, empty, error. 4. Detail interaction behavior, validation rules, and edge cases. 5. List open questions and decisions engineering needs from me before building. </task>