ChatGPT Prompts for UX Designers

Build a detailed user persona for the following product based on the information I provide. This persona should be usable in design reviews, stakeholder presentations, and as a reference throughout the product development cycle.

Product: [describe your product or feature]
Target market: [industry, geography, B2B/B2C]
Known user demographics: [age range, job title, tech proficiency, any data you have]
Key user goal: [what the user is trying to accomplish with your product]
Frustrations with current solutions: [what annoys them about existing tools or workflows]

Create the persona with:
1. Name, photo description, and a one-sentence bio that captures their essence
2. Demographics: age, location, job title, company size, income range, education
3. Psychographics: values, motivations, fears, aspirations — what drives their decisions
4. Technology profile: devices, apps they use daily, comfort level with new tools, browser preference
5. Goals (3-5): what they want to achieve, ranked by priority
6. Pain points (3-5): specific frustrations with their current workflow, not generic complaints
7. A day-in-the-life scenario: walk through a typical workday showing where your product fits
8. Decision-making factors: what influences their purchase decisions (price, reviews, peer recommendation, boss mandate)
9. Quote: a fictional but realistic quote that captures their attitude toward this problem space
10. Design implications: 3-5 specific design decisions this persona should influence

Format this as a one-page persona card I can print or share in Figma. Use clear section headers and keep it scannable.

Write a semi-structured user interview script for a UX research study. The interview should uncover genuine behaviors and pain points without leading the participant toward predetermined conclusions.

Product/feature: [describe what you're researching]
Research objective: [what decisions will this research inform — e.g., "determine whether users need a dashboard or prefer email summaries"]
Participant profile: [who you're interviewing — role, experience level, relationship to your product]
Interview format: [remote/in-person, duration in minutes, recorded or not]
Stage of product: [discovery / evaluative / post-launch optimization]

Write the script with:
1. Introduction (3 min): informed consent language, recording permission, "there are no wrong answers" framing, and an icebreaker question related to their work
2. Context questions (5 min): understand their role, daily workflow, and tools they currently use — establish baseline behavior before discussing your product
3. Problem exploration (10 min): 5-7 open-ended questions about the problem space. Use "tell me about a time when..." and "walk me through how you currently..." formats. Never mention your solution yet
4. Current solution deep-dive (8 min): how they solve this problem today, what works, what doesn't, workarounds they've built
5. Concept reaction (8 min): if applicable, introduce your concept and observe reactions. Include probing follow-ups for both positive and negative responses
6. Prioritization exercise (5 min): have them rank features or pain points — include the exact instructions to give the participant
7. Wrap-up (3 min): "anything else I should have asked?", next steps, thank you

Include interviewer notes in [brackets] for body language to watch for, when to probe deeper, and common pitfalls to avoid. Add 3 backup questions for when a participant gives short answers.

Create a comprehensive usability test plan for evaluating a [prototype / live product / competitor product]. This plan should be detailed enough that another researcher could run the test without additional guidance.

Product: [describe the product or feature being tested]
Test objective: [what specific questions should this test answer — e.g., "Can users complete checkout in under 3 minutes?"]
Prototype fidelity: [paper sketch / low-fi wireframe / high-fi interactive / production code]
Test format: [moderated remote / moderated in-person / unmoderated remote]
Number of participants: [planned count]
Participant criteria: [who qualifies and who doesn't]

Write the plan with:
1. Study overview: objective, methodology, timeline, team roles (moderator, note-taker, observer)
2. Participant screener: 5-7 screening questions with qualify/disqualify criteria to recruit the right users
3. Task scenarios (5-7 tasks): realistic, goal-oriented scenarios written from the user's perspective. Each should include:
   - Scenario context: a brief story that frames the task naturally
   - Task instruction: what to tell the participant (without revealing the expected path)
   - Success criteria: specific, measurable definition of task completion
   - Time limit: maximum time before moving on
   - Follow-up questions: 2-3 probes for after each task
4. Metrics to capture: task success rate, time on task, error rate, SUS score, satisfaction rating per task
5. Think-aloud protocol instructions: exact script for explaining think-aloud to participants
6. Pre-test questionnaire: 5 questions about background and expectations
7. Post-test questionnaire: SUS (System Usability Scale) questions plus 3 custom questions
8. Data analysis plan: how you'll aggregate findings and identify patterns across participants
9. Report template outline: sections for the final deliverable

Include a moderator guide with do's and don'ts — especially how to handle participants who get stuck without biasing the results.

Help me plan the information architecture for a [website / web application / mobile app]. I need to organize content and features into a logical structure that matches users' mental models.

Product: [describe the product]
Total number of pages/screens (estimated): [count]
Primary user goals (ranked): [list the top 3-5 things users come to do]
Content types: [list all content types — articles, products, user profiles, settings, dashboards, etc.]
Current pain points (if redesigning): [what's broken about the existing structure]
Benchmark sites users are familiar with: [3-5 sites/apps your users already know]

Create the IA plan with:
1. Content inventory: categorize all content and features into logical groups. For each group, note the user need it serves
2. Site map: a hierarchical text-based site map showing primary navigation (L1), secondary navigation (L2), and tertiary pages (L3). Use indentation to show hierarchy
3. Navigation model: recommend top nav, side nav, bottom nav (mobile), or hybrid — justify the choice based on content breadth vs. depth
4. Labeling system: propose clear, user-friendly labels for each navigation item. Avoid internal jargon. Include 2-3 alternative labels for A/B testing
5. Search strategy: what needs to be searchable, suggested filters and facets, search result grouping
6. Cross-linking strategy: identify content that should link to each other even if not in the same nav branch
7. URL structure: proposed URL patterns that are human-readable and SEO-friendly
8. Wayfinding aids: breadcrumbs, progress indicators, contextual navigation — where each is needed
9. Card sort recommendations: suggest 15-20 cards for an open card sort to validate this structure with real users
10. Red routes: identify the 3-5 most critical user paths and ensure they require minimal clicks

Format the site map as an indented outline I can transfer to a diagramming tool.

Create a detailed user journey map for the following scenario. The map should visualize the complete experience from initial awareness through long-term usage, capturing emotions, touchpoints, and opportunities at every stage.

Product: [describe the product]
Persona: [name and brief description of the user persona — or paste a persona you've already created]
Scenario: [the specific journey to map — e.g., "first-time user discovers, evaluates, purchases, onboards, and becomes a regular user"]
Scope: [end-to-end lifecycle / specific feature flow / support interaction / purchase decision]
Channels involved: [website, mobile app, email, social media, in-person, support chat, etc.]

Build the journey map with these lanes for each stage:

Stages (columns): Awareness → Consideration → Decision → Onboarding → Regular Use → Advocacy (adjust stages to fit your product)

For each stage, fill in:
1. User actions: specific steps the user takes (not vague — "searches Google for 'best project management tool'" not "researches options")
2. Touchpoints: every interaction point (landing page, pricing page, signup form, welcome email, in-app tutorial, etc.)
3. User thoughts: internal monologue in quotes — what they're thinking at this moment
4. Emotional state: emoji-free rating from -3 (frustrated) to +3 (delighted) with a one-word emotion label
5. Pain points: specific friction, confusion, or frustration at this stage
6. Opportunities: design or product improvements that could address each pain point
7. Metrics to track: what KPI tells you if this stage is working (bounce rate, time to first value, NPS, etc.)
8. Responsible team: who owns this touchpoint (marketing, product, engineering, support)

End with:
- Moment of truth: the single most critical make-or-break moment in the journey
- Quick wins: 3 improvements that could ship this week
- Strategic bets: 3 improvements that require deeper investment but have the highest impact

Format as a structured table that can be transferred to Miro, FigJam, or a spreadsheet.

Conduct a heuristic evaluation of [product/feature name] using Nielsen's 10 usability heuristics. I need a structured audit that identifies specific issues, rates their severity, and recommends fixes.

Product: [describe the product or feature]
Platform: [web / iOS / Android / desktop application]
Key user tasks: [list the 3-5 primary tasks users perform]
Pages/screens to evaluate: [list specific pages or flows — or "entire product"]
Comparison benchmark: [a well-designed competitor or best-in-class example]

For each of Nielsen's 10 heuristics, create an evaluation section:

1. Visibility of System Status
2. Match Between System and Real World
3. User Control and Freedom
4. Consistency and Standards
5. Error Prevention
6. Recognition Rather Than Recall
7. Flexibility and Efficiency of Use
8. Aesthetic and Minimalist Design
9. Help Users Recognize, Diagnose, and Recover from Errors
10. Help and Documentation

For each heuristic, provide:
- Definition: one-sentence explanation of what this heuristic means in practice
- Evaluation questions: 3-5 specific questions to ask while reviewing the interface
- Common violations to look for: 4-5 patterns that frequently fail this heuristic
- Severity rating scale: 0 (not a problem) to 4 (usability catastrophe) — define what each level means
- Finding template: a fill-in format for documenting each issue:
  [Location] → [What's wrong] → [Which heuristic is violated] → [Severity 0-4] → [Recommended fix] → [Effort estimate: low/medium/high]

End with:
- Summary scorecard: a table rating each heuristic 1-5
- Top 5 critical issues: ranked by severity × frequency
- Priority matrix: plot all findings on an impact vs. effort 2×2 grid

Format so I can use this as a working document — fill in findings as I walk through the product.

Write UX microcopy for the following interface elements. The copy should be clear, concise, helpful, and consistent with the product's voice. Every word in a UI earns its place or gets cut.

Product: [describe the product]
Brand voice: [e.g., "friendly but professional, like a knowledgeable coworker" / "minimal and direct, like a premium tool"]
User context: [who is reading this and what are they trying to do]
Platform: [web / mobile / both]

Write microcopy for each of the following UI elements:

1. Empty states (5 examples): when a list, dashboard, or search has no results — turn a dead end into a next step
2. Error messages (5 examples): form validation errors, server errors, permission errors — be specific about what went wrong AND how to fix it
3. Success confirmations (3 examples): after completing an action — confirm what happened and suggest what to do next
4. Onboarding tooltips (4 examples): first-time user guidance that teaches without patronizing
5. Loading states (3 examples): when something takes more than 2 seconds — manage expectations
6. Destructive action confirmations (3 examples): before deleting, canceling, or removing something — make the consequences clear without being dramatic
7. Permission requests (3 examples): asking for access to notifications, location, camera — explain the value before asking
8. Call-to-action buttons (5 pairs): primary and secondary button labels for key flows — verbs that describe what happens, not vague labels
9. Helper text (4 examples): inline guidance for form fields — anticipate the user's question
10. Placeholder text (4 examples): input field placeholders that actually help (not "Enter text here")

For each piece of microcopy, provide:
- The copy itself
- Character count
- Why this wording works (one sentence)
- One alternative version for A/B testing
- An anti-pattern to avoid (what NOT to write)

End with 5 UX writing principles specific to this product that a team can reference for consistency.

Conduct a competitive UX audit comparing [your product] against [2-4 competitor products]. This audit should go beyond screenshots — analyze the experience strategy behind each product's design decisions.

Your product: [name and brief description]
Competitors to analyze: [list 2-4 competitors with URLs]
Key user tasks to compare: [list 3-5 tasks users do in all products — e.g., "sign up, create first project, invite team members, export data"]
Target audience overlap: [describe the shared user base]

Structure the audit as follows:

1. First impression analysis: for each product, evaluate the landing page, value proposition clarity, and time-to-signup. Rate each 1-5
2. Onboarding comparison: how does each product handle first-time users? Document steps to first value, hand-holding vs. exploration, progressive disclosure
3. Task flow comparison: for each key task, map the steps in each product side by side:
   - Number of clicks/taps to complete
   - Cognitive load at each step (decisions the user must make)
   - Error handling when users go wrong
   - Delight moments that exceed expectations
4. Navigation and IA: compare navigation models, labeling clarity, findability of secondary features
5. Visual design and brand: compare design maturity, consistency, accessibility, use of whitespace, typography hierarchy
6. Mobile experience: responsive behavior, native app quality, feature parity between platforms
7. Performance signals: perceived speed, skeleton screens, optimistic UI patterns
8. Support and help: in-app help, documentation quality, chatbot vs. human support

For each dimension, create a comparison table:
| Criteria | Your Product | Competitor A | Competitor B | Competitor C |

End with:
- Competitive advantages: 3-5 things your product does better
- Gaps to close: 3-5 areas where competitors outperform you
- Differentiation opportunities: 3 UX strategies no competitor has tried yet
- Recommended priorities: ranked list of improvements based on competitive gaps × user impact

Help me conduct a WCAG 2.1 AA accessibility review of [product/feature]. I need to identify issues across all four POUR principles and create an actionable remediation plan.

Product: [describe the product or feature]
Platform: [web / iOS / Android / cross-platform]
Current compliance status: [unknown / partially compliant / previously audited with known issues]
Target compliance: [WCAG 2.1 AA / WCAG 2.1 AAA / Section 508 / EN 301 549]
User groups to prioritize: [screen reader users / keyboard-only / low vision / cognitive disabilities / motor impairments / all]

Create a review checklist organized by POUR principles:

**Perceivable:**
- Text alternatives for all non-text content (images, icons, charts, videos)
- Captions and transcripts for audio/video content
- Content adaptable to different presentations without losing meaning
- Minimum contrast ratios: 4.5:1 for normal text, 3:1 for large text, 3:1 for UI components
- No information conveyed by color alone
- Text resizable to 200% without loss of functionality

**Operable:**
- All functionality available via keyboard (no keyboard traps)
- Skip navigation and landmark regions
- Sufficient time for timed interactions (or ability to extend)
- No content that flashes more than 3 times per second
- Focus order follows logical reading sequence
- Focus indicators visible and meet 3:1 contrast ratio
- Touch targets minimum 44x44 CSS pixels

**Understandable:**
- Language of page declared in HTML lang attribute
- Consistent navigation across pages
- Input fields have visible labels and clear instructions
- Error identification with text description (not color alone)
- Error suggestions and prevention for legal/financial transactions

**Robust:**
- Valid HTML with proper semantic structure
- ARIA roles, states, and properties correctly implemented
- Name, role, value exposed to assistive technologies
- Status messages conveyed without focus change

For each checklist item provide:
- WCAG success criterion number and level (A/AA/AAA)
- How to test it (manual check, screen reader, browser dev tools, automated tool)
- Common failure pattern with code example
- Fix recommendation with code example
- Priority: critical / major / minor

End with a recommended testing toolkit (automated tools + manual procedures) and a suggested remediation timeline.

Write comprehensive documentation for a design system component or pattern. This documentation should serve both designers (using Figma) and developers (implementing in code) as a single source of truth.

Design system name: [name]
Component or pattern: [e.g., "Modal Dialog" / "Form Validation Pattern" / "Data Table" / "Toast Notification System"]
Tech stack: [React / Vue / Angular / Web Components + CSS framework if applicable]
Design tool: [Figma / Sketch]
Audience: [internal team / external contributors / open-source community]

Write the documentation with:

1. Overview: what this component/pattern is, when to use it, and when to use an alternative instead. Include a decision tree for choosing between similar components (e.g., modal vs. dialog vs. sheet vs. popover)
2. Anatomy diagram (text description): label every element of the component and indicate which parts are required vs. optional
3. Variants and their use cases: list each variant with a specific scenario where it's the right choice. Include visual descriptions
4. Design specifications:
   - Spacing: all padding, margins, and gaps using design token names
   - Typography: font sizes, weights, line heights for each text element
   - Colors: fill, border, text colors for each state using token names
   - Elevation: shadow values if applicable
   - Border radius and stroke widths
5. Interaction behavior:
   - State transitions: default → hover → pressed → focused → disabled
   - Animation: duration, easing, properties that animate
   - Keyboard interaction: tab order, key bindings, focus management
   - Screen reader announcements: what gets read and when
6. Responsive behavior: how the component adapts at each breakpoint
7. Content guidelines: character limits, tone, formatting rules for text within the component
8. Accessibility requirements: ARIA attributes, roles, keyboard patterns (reference WAI-ARIA Authoring Practices)
9. Code examples: props/API surface with type definitions, basic usage example, advanced usage with all options
10. Do's and don'ts: 5 correct uses and 5 incorrect uses with explanations
11. Related components: links to components often used together or easily confused

Format with clear headings, code blocks, and specification tables. This should work as a standalone reference page in a documentation site.

Help me build a presentation to justify a UX design decision to stakeholders who may push back. I need to frame design choices as business decisions backed by evidence, not aesthetic preferences.

Decision to defend: [describe the UX change — e.g., "removing the sidebar navigation in favor of a top bar", "adding 2 more steps to onboarding", "simplifying the dashboard from 12 widgets to 4"]
Stakeholders: [who's in the room — CEO, product manager, engineering lead, sales team, etc.]
Their likely concerns: [what objections they'll raise — e.g., "users will miss features", "it looks too simple", "competitors have more on their dashboard"]
Evidence you have: [user research data, analytics, usability test results, industry benchmarks]
Business context: [relevant KPIs, company goals, recent performance data]

Write the presentation with:

1. Opening hook (1 slide): start with a user pain point or metric, NOT the solution. Frame the problem as a business cost — e.g., "We're losing 40% of users during onboarding. Each lost user costs us $X."
2. User evidence (2-3 slides): present research findings that reveal the problem. Use direct user quotes, task completion rates, heatmaps descriptions, or support ticket themes. Make the audience feel the user's frustration
3. The insight (1 slide): the key finding that led to this design direction. Frame it as a discovery, not an opinion — "Our research revealed that..."
4. Design decision (2-3 slides): present the solution. For each design choice, use the framework:
   - "We observed [user behavior/data]"
   - "Which told us [insight]"
   - "So we designed [solution]"
   - "Which we expect will [measurable outcome]"
5. Addressing concerns (1-2 slides): proactively address each likely objection with evidence. Don't dismiss concerns — acknowledge them and explain the tradeoff
6. Risk mitigation (1 slide): how you'll measure success, what the rollback plan is, and what triggers a rollback. This shows confidence, not recklessness
7. Ask (1 slide): clearly state what you need from stakeholders — approval, feedback, resources, timeline

Include speaker notes for each slide. The tone should be collaborative and evidence-based — you're a partner solving a business problem, not a designer defending your taste.

Help me design a rigorous A/B test for a UX change. I need a structured hypothesis, clear metrics, and a test plan that will produce actionable results regardless of outcome.

Feature or page to test: [describe the page, flow, or component]
Current performance: [baseline metrics — conversion rate, task completion, time on task, bounce rate, etc.]
Proposed change: [describe what you want to test — be specific about the UX modification]
User segment: [who will see this test — all users, new users, power users, specific cohort]
Expected traffic: [daily/weekly visitors to this page or feature]

Build the A/B test plan:

1. Hypothesis statement: use the format: "If we [specific change], then [primary metric] will [increase/decrease] by [estimated %], because [user behavior reasoning based on research/data]"
2. Null hypothesis: "There is no significant difference between control and variant in [metric]"
3. Independent variable: the ONE thing that differs between control and variant — describe both versions in detail
4. Dependent variables:
   - Primary metric: the single metric that determines success (with current baseline and target)
   - Secondary metrics: 2-3 supporting metrics to watch for unintended consequences
   - Guardrail metrics: metrics that must NOT decrease (e.g., page load time, revenue per user)
5. Sample size calculation: based on baseline conversion rate, minimum detectable effect, and 95% confidence / 80% power — calculate required visitors per variant
6. Test duration: minimum days to run based on traffic and weekly cycles (always full weeks)
7. Segmentation plan: break results by device, traffic source, new vs. returning, and any relevant user attributes
8. Test design: control description, variant description, traffic split ratio, randomization method
9. Potential confounds: holidays, product launches, marketing campaigns, or seasonality that could skew results
10. Decision framework:
    - If variant wins clearly: ship to 100% and document the learning
    - If variant wins marginally: extend the test or run a follow-up
    - If control wins: document WHY and what to test next
    - If inconclusive: what you still learned and next iteration

Include a pre-launch checklist: QA the variant, verify analytics tracking, confirm randomization, check for flickering, set calendar reminder for minimum test duration.