Best AI Prompts for UX Designers in 2026 (25 Copy-Paste Prompts)

**Prompt 1: User Persona Generator** Use this when: you're starting a new project and need a realistic representation of your target user before running formal research. Create a detailed UX persona for a [product or feature type]. Target audience: [describe who uses this — e.g., a B2B SaaS project management tool used by mid-level marketing managers at 50–500-person companies / a mobile budgeting app for recent college graduates managing student loan debt]. Include: (1) Demographics — age range, job title, company type, income level, (2) Goals — what they're trying to accomplish with this product, top 3 priorities, (3) Pain points — what frustrates them most about current solutions, what's driving them to seek alternatives, (4) Behaviors — how they currently solve this problem, which tools or workarounds they use, (5) Quote — a 1-sentence quote that captures how this person thinks about the problem, (6) Tech comfort level — how comfortable they are with new software, (7) Decision-making — what factors matter most when evaluating a tool like this. Format as a named persona with a brief bio. Tone: specific and grounded, not generic marketing language. Why it works: AI-generated personas are starting points, not finished research artifacts. Use this to align your team on who you're designing for before formal research — then update it as you learn from real users.

**Prompt 2: User Interview Question Builder** Use this when: you're preparing for user research interviews and want a structured set of questions that surface real behavior and mental models — not just feature requests. Write a user interview guide for a [product type or feature] targeting [describe the user]. Research goals: [what you need to learn — e.g., how users currently manage project deadlines, what causes them to abandon the tool mid-task, how they decide which features to use]. Generate 12–15 interview questions in three sections: (1) Context & background — warm-up questions about role, workflow, and current tools (no leading questions), (2) Current behavior — questions about how they actually work today, in specific terms (use 'Tell me about the last time...' framing), (3) Problem exploration — questions that probe pain points and workarounds without asking directly about your product. Include 3 follow-up probes for each section. Avoid: binary yes/no questions, leading questions, or questions that assume a specific behavior. Tone: conversational, open-ended. Why it works: The most common user interview mistake is asking hypothetical questions ('Would you use this feature?') instead of behavioral ones ('Tell me about the last time you needed to do X'). This structure forces the behavioral framing that produces usable research insights.

**Prompt 3: User Journey Map Outline** Use this when: you need to map the end-to-end experience a user has with a product or process — from awareness through post-use — to identify friction points and design opportunities. Create a user journey map outline for [persona name or user type] completing [task or goal — e.g., signing up and completing onboarding for a project management app / applying for a small business loan through an online lender / booking a healthcare appointment through a patient portal]. Map the journey across five stages: (1) Awareness — how does this user discover the product or start the process? (2) Consideration — what do they evaluate or need to understand before starting? (3) First use / onboarding — what are the key steps in their first interaction? (4) Core workflow — what does repeated, habitual use look like? (5) Advocacy or abandonment — what determines whether they refer others or leave? For each stage include: key user actions, emotional state (frustrated / neutral / delighted), questions they're asking, and 2 design opportunities. Format as a structured table or outline. Why it works: Journey maps are most useful when they track a specific user through a specific scenario — not a generic persona through an abstract process. The more specific the input, the more actionable the output.

**Prompt 4: Pain Point Synthesis from Research Notes** Use this when: you've completed user interviews or usability sessions and need to synthesize raw notes into a structured problem statement that can drive design decisions. I've completed [number] user research interviews about [topic or product area]. Here are my raw notes: [Paste your notes here — direct quotes, observations, key moments] Synthesize these notes into a structured research summary including: (1) Top 3 pain points — ranked by frequency and severity, each with 2–3 supporting quotes, (2) Unmet needs — what users need that current solutions don't provide, (3) Mental model patterns — how users think about or categorize this problem (their language, not product language), (4) Surprising findings — things that contradicted your assumptions, (5) Design implications — 3–5 specific design decisions this research should inform. Write as a research brief, not a list of bullet points. Under 400 words. Why it works: Raw interview notes are hard to act on. This prompt forces a synthesis pass that identifies patterns, surfaces the most important insights, and connects them to design implications — the step most designers skip under timeline pressure.

**Prompt 5: Jobs-to-Be-Done Framework** Use this when: you want to understand why users are actually using your product — not what features they want, but what 'job' they're hiring your product to do. Apply the Jobs-to-Be-Done framework to [product name or category]. User context: [describe who the user is and what they're trying to accomplish]. Define: (1) The functional job — the practical task they're trying to get done (e.g., 'track which projects are behind schedule across my team'), (2) The emotional job — how they want to feel as a result (e.g., 'feel in control and on top of my responsibilities'), (3) The social job — how they want to be perceived by others (e.g., 'be seen by leadership as someone who runs tight projects'), (4) The struggling moment — the specific situation that triggers them to look for a solution ('When I ___, I want to ___, so I can ___'), (5) Current workarounds — what they're doing today that proves this job is real but unmet, (6) The success metric — how the user knows the job is done well. Format as a JTBD brief, 1–2 sentences per section, specific language. Why it works: The JTBD framework shifts design focus from features to outcomes — and outcomes-based design produces products that feel intuitively valuable rather than feature-complete but frustrating to use.

**Prompt 6: Onboarding Flow Copy** Use this when: you're designing or rewriting an onboarding sequence and need copy that reduces friction, sets expectations, and moves users toward their first aha moment. Write the UI copy for an onboarding flow for [product name or type]. User context: [who the user is and what brought them here — e.g., a marketing manager who signed up after seeing a LinkedIn ad about AI content creation]. The product's core value: [what the product does and what the user's first aha moment should be — e.g., 'their first AI-generated social media calendar']. Write copy for: (1) Welcome screen — headline and subheadline that immediately confirm they're in the right place, (2) Goal-setting step — question or prompt that personalizes the experience and invests the user in their own setup, (3) First setup step — clear, jargon-free instruction for the first required action, (4) Progress moment — short copy after they complete setup that confirms value and builds anticipation, (5) First success state — copy for the moment they reach their aha moment. For each step: headline, body copy (under 40 words), and the primary CTA label. Tone: [describe your product's voice — e.g., friendly and direct / professional and clean / casual and motivating]. Why it works: Most onboarding copy is written by PMs or engineers at the last minute. Bringing UX writing principles into onboarding — confirmation, momentum, anticipation — measurably improves activation rates.

**Prompt 7: Error Message Rewrites** Use this when: you have existing error messages that are technical, unhelpful, or frustrating — and want to rewrite them in a way that's clear, human, and tells the user what to do next. Rewrite the following error messages using UX writing best practices. For each rewrite: (1) Specific — tell the user what went wrong, not just that something went wrong, (2) Helpful — tell them what to do next, (3) Human — no technical jargon, system codes, or passive voice, (4) Proportionate — tone should match severity (data loss → serious; form validation → friendly). Original error messages: [Paste your current error messages here] For each message, provide: the rewrite, the tone rationale (1 sentence), and a suggested character count for the component. If any errors can be prevented at the design level rather than written around, note that. Why it works: Error messages are the most-read copy in any product and the most neglected. A 10-minute UX writing pass on your error message library can measurably reduce support tickets and increase user trust.

**Prompt 8: CTA Optimization** Use this when: a call-to-action is underperforming or feels generic — 'Submit,' 'Click here,' 'Learn more' — and you want to test more specific, action-oriented alternatives. Optimize the following call-to-action labels for a [product type or feature]. Current CTAs: [list the CTAs you want to improve]. Context for each: [describe where this CTA appears, what the user has just done, and what happens when they click — be specific]. For each CTA, provide: (1) 3 alternative labels that are more specific, action-oriented, and value-forward (under 5 words each), (2) A 'control vs. test' recommendation — which version is most likely to improve conversion and why, (3) A note on the user's emotional state at this moment and how that should affect the label choice. Avoid: filler verbs (click, submit, go), vague value language (learn more, discover), and pressure language (don't miss out, act now) unless the context specifically calls for urgency. Why it works: CTA labels are among the highest-leverage copy improvements in any product. A one-word change from 'Submit' to 'Send my request' consistently outperforms the generic version — and this prompt forces the contextual thinking that produces those improvements.

**Prompt 9: Empty State Copy** Use this when: you're designing empty states — first-time use, no results, or zero-data views — and want copy that feels helpful and motivating rather than blank and cold. Write the UI copy for empty states in [product or feature]. For each empty state, write: (1) A headline that acknowledges the empty state without making the user feel like they've done something wrong, (2) A 1–2 sentence body explaining what will appear here and/or how to get started, (3) A primary CTA that's specific and action-oriented. Empty states to write for: [List the empty states you need — e.g., 'No projects yet (first-time use)' / 'No results found (search with no matches)' / 'No notifications (empty activity feed)' / 'No team members added (empty settings page)'] For each: write the copy, note the emotional tone (curious / motivated / reassured / neutral), and flag if there's a design improvement that would reduce friction better than copy alone. Why it works: Empty states are often afterthoughts — a dash and a vague label. Good empty state copy turns a 'nothing here' moment into an onboarding nudge or a motivation moment. For SaaS products, empty states are often the highest-traffic screens in the first 7 days.

**Prompt 10: Tooltip and Helper Text** Use this when: a feature, field, or setting needs contextual explanation in the UI — and you want the copy to be minimal, precise, and genuinely helpful rather than a developer note in disguise. Write tooltip and helper text for the following UI elements in [product type]. For each element: (1) Tooltip copy — under 15 words, enough context to answer 'what does this do?', (2) Helper text — under 25 words, answers 'why does this matter / what should I enter here?', (3) Flag if this element needs a tooltip at all — sometimes confusing UI is better fixed with a label change than layered text. UI elements to write for: [List the fields, settings, icons, or features that need explanation] Guidelines: Use second person ('Your password must...') not passive voice ('Password must...'). State the benefit when helpful, not just the rule. Avoid: 'This field allows you to...' / 'Click here to...' / 'Optional:' without explanation. Why it works: Most tooltip and helper text is copied from documentation or written by engineers who know the system. Good microcopy at this level reads like a knowledgeable colleague talking you through the interface — and prevents support tickets that come from 'what does this mean?'

**Prompt 11: Heuristic Evaluation Checklist** Use this when: you need a structured framework for evaluating a product's usability against established principles — for solo audits, team reviews, or client deliverables. Create a heuristic evaluation checklist for [product type — e.g., a B2B dashboard / a mobile checkout flow / an onboarding sequence]. Base the checklist on Nielsen's 10 usability heuristics, adapted for [product context]. For each heuristic, provide: (1) A plain-language description of what the heuristic means in practical terms for this product type, (2) 3–5 specific evaluation questions tied to the actual product category, (3) A severity rating scale (1–4: cosmetic / minor / major / critical), (4) An example of what a violation looks like in this product context. Format as a structured audit template with a column for findings and severity rating. Designed to be completed in a focused 90-minute session. Why it works: Heuristic evaluations without a structured checklist produce inconsistent findings and are hard to present to stakeholders. A tailored checklist forces systematic coverage and makes severity prioritization defensible.

**Prompt 12: Accessibility Audit Checklist** Use this when: you're conducting an accessibility review and need a structured checklist covering WCAG 2.2 Level AA requirements that's practical for design reviews — not just developer handoff. Create an accessibility audit checklist for [product type or specific screen/flow] organized for UX designers conducting a design review (not a technical code audit). Cover: (1) Color contrast — specific contrast ratio requirements for text, UI components, and interactive states, (2) Focus and keyboard navigation — what a keyboard-only user needs to accomplish and how to evaluate it in design, (3) Touch target sizing — minimum sizes and spacing for mobile and desktop, (4) Text and typography — legibility standards, minimum sizes, line spacing, text on image guidelines, (5) Form accessibility — label requirements, error identification, required field marking, (6) Motion and animation — reduced motion considerations, seizure-safe thresholds, (7) Images and icons — alt text requirements, when icons need labels. Format as a practical design checklist, not a WCAG citation guide. Include 'why it matters for users' for each section in one sentence. Why it works: WCAG documentation is written for compliance, not for designers in the middle of a critique. A designer-friendly accessibility checklist makes it faster to identify real issues during design review — before handoff.

**Prompt 13: Competitor UX Teardown** Use this when: you need to systematically analyze a competitor's product UX — for research, positioning, or presenting design decisions to stakeholders. Create a competitive UX teardown framework for analyzing [competitor or product type]. My product context: [what your product does and who it serves]. Competitor to analyze: [name the competitor or describe the product type]. The teardown should cover: (1) First impressions — landing page, onboarding clarity, value communication, (2) Information architecture — navigation model, content organization, feature discoverability, (3) Core workflow — the 2–3 primary tasks users come to do, and how easy they are to complete, (4) UI patterns — which design conventions they follow, which they break, and the effect on usability, (5) Copywriting and microcopy — tone, clarity, help text quality, error messages, (6) Performance and friction — where the experience slows down or requires extra steps, (7) Differentiators — what they do genuinely well that your product should learn from or beat. Format as a structured teardown template with a competitive summary at the end. Tone: analytical, not opinionated. Why it works: Unstructured competitive research produces vague impressions ('their onboarding is better'). A systematic teardown framework produces specific, actionable findings that can directly inform design decisions.

**Prompt 14: Usability Test Script** Use this when: you're running a usability test — moderated or unmoderated — and need a structured script with tasks, prompts, and post-task questions. Write a usability test script for testing [feature or flow] with [target user type]. Product context: [what the product does]. Research questions: [what you're trying to learn — e.g., 'Can users find and complete the team invite flow without assistance?' / 'Do users understand what the dashboard is showing them on first view?']. The script should include: (1) Introduction — brief framing for the participant that doesn't reveal what you're testing (under 100 words), (2) Warm-up questions — 3 questions to understand the participant's context and comfort level, (3) Task scenarios — [number] task scenarios written as realistic situations, not instructions ('Imagine you've just joined the team and your manager asked you to...' not 'Click on Settings and navigate to...'), (4) Think-aloud prompt — one-line instruction for think-aloud protocol, (5) Post-task questions — 3 questions per task to capture satisfaction and confusion, (6) Closing questions — 3 debrief questions about overall impressions. Include note-taking prompts in brackets throughout. Why it works: Usability test scripts that use scenario-based tasks (rather than instruction-based tasks) produce more realistic behavior and better insights — because participants are acting as themselves in a situation, not executing a checklist.

**Prompt 15: Design Critique Framework** Use this when: you're preparing for or running a design critique and want a structured framework that keeps feedback productive, specific, and tied to design goals — rather than subjective or meandering. Create a design critique framework for reviewing [design type — e.g., a new onboarding flow / a redesigned dashboard / a mobile navigation pattern]. Design context: [describe the design being reviewed, the goals it should achieve, and the user it serves]. The framework should: (1) Define the critique objectives — what specific questions should the critique answer? (2) Provide a structure for feedback — a sequence for how to walk through the design (goals first, then user journey, then detail), (3) Include prompt questions for each stage that produce specific, actionable feedback rather than 'I like / I don't like,' (4) Define what good feedback looks like — a rubric distinguishing actionable critique from preference sharing, (5) Address common critique failure modes — what to do when feedback drifts to visual preference or out-of-scope scope creep. Include a 'critique card' format any reviewer can use: observation → design principle → specific recommendation. Why it works: Unstructured critiques are dominated by the loudest voice or drift to aesthetic preferences. A critique framework ensures every reviewer addresses the same questions, feedback stays tied to design goals, and the team leaves with actionable findings rather than conflicting opinions.

**Prompt 16: Design Decision Rationale** Use this when: you need to document or present the reasoning behind a design decision — especially when stakeholders disagree or when decisions need to be preserved for future reference. Write a design decision rationale for the following design choice. Decision: [describe the design decision — e.g., 'We are removing the global search bar from the navigation and replacing it with contextual search within each module']. Context: [what was the previous design, what problem triggered the change, and what design options were considered]. Structure as: (1) Problem statement — what user or business problem this decision addresses, in one paragraph, (2) Options considered — a brief description of the 2–3 approaches evaluated and why each was considered, (3) Decision — what was chosen and why, tied to user research, design principles, or product goals (not aesthetic preference), (4) Trade-offs — what we're accepting or deprioritizing with this choice, (5) Success metric — how we'll know if this decision was right, (6) Open questions — what remains unresolved. Under 300 words. Tone: clear and confident, not defensive. Why it works: Design decisions documented without rationale get relitigated every time a new stakeholder joins. A decision rationale document turns a past debate into settled context — and demonstrates that design choices are evidence-based.

**Prompt 17: Presenting Design Trade-offs** Use this when: you need to present multiple design directions to stakeholders and want to frame the decision in terms of trade-offs rather than 'pick your favorite.' Write a stakeholder presentation outline for presenting [number] design directions for [feature or product area]. Stakeholder context: [who's in the room — e.g., product manager, engineering lead, marketing director, VP of Growth — and what their primary concerns typically are]. Design directions: [briefly describe each option]. Frame the presentation as a trade-off analysis rather than a preference vote. The outline should include: (1) Opening — frame the decision as a strategic choice between defined trade-offs (under 2 minutes), (2) User context — the user problem these options address, grounded in research, (3) For each direction: the core approach, what it optimizes for, what it sacrifices, which users or use cases it serves best, (4) Recommendation — which direction the design team recommends and why, framed in terms of product strategy and user research, (5) Decision criteria — what factors should drive the final call (presented as questions, not answers), (6) Next steps — what happens after the decision is made. Tone: collaborative, not presenting to be approved. Why it works: 'Here are three designs, which one do you like?' invites stakeholders to vote on aesthetics. 'Here are three approaches and their trade-offs' invites a strategic decision — and positions the designer as a strategic partner, not a service provider.

**Prompt 18: Translating Research into Business Impact** Use this when: you have user research findings and need to present them to a non-design stakeholder in terms they care about — revenue, retention, cost savings, or conversion. Help me translate the following user research findings into business impact language. Research findings: [describe what you found — e.g., 'Users are confused by the pricing page and frequently contact support before converting' / '67% of users abandon the file upload step during onboarding']. Stakeholder context: [who needs to hear this — e.g., VP of Product focused on retention / CFO evaluating design team ROI / Sales leader whose team demos the product]. For each finding: (1) Reframe it as a business problem — not 'users are confused' but 'this confusion costs us X support tickets per week and delays conversion,' (2) Estimate the business impact — help me think through how to size the problem in business terms (what metric does this affect? What's a conservative estimate?), (3) Frame the design solution as a business investment — what are we building, what outcome will it drive, and what's the business case for prioritizing it? Provide the reframed version of each finding plus a template for presenting research ROI to leadership. Why it works: Design teams that speak in user feelings lose budget conversations. Design teams that speak in business outcomes win them. This prompt bridges the translation gap between what designers observe and what stakeholders fund.

**Prompt 19: Design Status Update Template** Use this when: you need to send a project status update to stakeholders and want it to be clear, concise, and structured — rather than a long email they won't read. Write a design project status update template for [project name or type]. Stakeholder audience: [who receives this — product manager, engineering lead, executive sponsor]. Update cadence: [weekly / bi-weekly / at sprint boundaries]. The template should cover: (1) Current phase — where the project is in the design process (research / concepting / validation / detailed design / handoff), (2) What's done since last update — 3–5 bullet points, specific and concrete (no 'continued working on...'), (3) What's in progress — specific deliverables or decisions being worked on, (4) Blockers — what's slowing progress and what's needed to unblock, (5) Decisions needed — specific decisions stakeholders need to make and by when, (6) What's next — the next 2 weeks of milestones. Format as a reusable template with section headers and one-line fill-in prompts for each field. Under 200 words when filled in. Why it works: Status updates that are too long don't get read. Status updates that are too short create confusion. A consistent, skimmable format builds stakeholder confidence without requiring long emails or extra meetings.

**Prompt 20: Design Handoff Notes** Use this when: you're handing off a design to engineers and want to communicate intent, decisions, and edge cases clearly — reducing back-and-forth and implementation surprises. Create a design handoff notes template for [feature or component type]. Engineering context: [describe your team's setup — e.g., frontend engineers working in React with a design system, contractors building from Figma specs]. The template should include: (1) Feature summary — what this is and why we're building it (1 paragraph, written for engineers who weren't in the design process), (2) Interaction specifications — behaviors that aren't obvious from the static design (hover states, transitions, micro-interactions, loading states), (3) Edge cases — what the design does in non-ideal states (empty, loading, error, overflow, long content), (4) Design system notes — which components to use as-is, which need customization, and any new patterns being introduced, (5) Responsive behavior — how the design adapts across breakpoints, (6) Accessibility requirements — specific requirements that must be implemented, (7) Open questions — anything that still needs an engineering decision or clarification. Format as a fillable template. Tone: direct and specific, not a documentation essay. Why it works: Vague handoff notes produce implementation questions and designs that drift from intent. Specific handoff documentation makes the designer's decisions legible to engineers and reduces re-work on both sides.

**Prompt 21: Portfolio Case Study Structure** Use this when: you're writing a UX portfolio case study and want a structure that tells a compelling story, demonstrates process, and gives hiring managers the context they need to evaluate your work. Create a portfolio case study structure for a UX project. Project context: [describe the project — what product, what problem, what your role was, what the outcome was]. Target role: [the type of role you're applying for — e.g., mid-level product designer at a growth-stage B2B SaaS company]. The case study should be structured as: (1) Problem and context — what was the business situation, what was the user problem, why did it matter? (2 paragraphs), (2) My role and scope — specific responsibilities, team composition, timeline, constraints, (3) Research — what you learned, how you learned it, how it changed your thinking (include a surprising finding if possible), (4) Design process — key decision points, directions considered and discarded, how you narrowed from problem to solution, (5) The solution — what you designed and why (not just 'here's the final design'), (6) Outcome — what happened, qualitative and quantitative if available, what you'd do differently, (7) Key decisions and trade-offs — 2–3 specific design decisions, the options considered, and the reasoning. Provide a word count target for each section and write the opening paragraph as an example. Why it works: Hiring managers spend 3–4 minutes on a case study. A well-structured case study that gets to the problem, process, and outcome quickly — with clear decision rationale — stands out from portfolios that are just a gallery of finished screens.

**Prompt 22: Job Application Positioning** Use this when: you're tailoring your portfolio and application materials for a specific role and want to identify which experiences and strengths to lead with — and how to frame them for this particular company. Help me position my UX background for this job application. Role: [paste the job title and key requirements from the job description]. My background: [describe your experience — years, domains, types of work, industries, key accomplishments]. What I want the hiring manager to believe about me: [e.g., 'that I'm a strategic design partner who can own research and cross-functional communication, not just produce deliverables']. For this role, help me: (1) Identify which 3 experiences or accomplishments are most relevant to lead with, (2) Reframe each one in terms that match the company's language in the job description, (3) Identify any gaps between my background and the role requirements and suggest how to address them proactively, (4) Write a tailored 3-sentence opening for my cover letter that speaks directly to why this role and this company, (5) Write a 50-word portfolio headline for this application. Tone: confident, not defensive about gaps. Why it works: Generic portfolios and cover letters feel like mass applications. A targeted positioning pass that matches your language to the company's language — and leads with the most relevant experiences — produces significantly higher response rates.

**Prompt 23: Salary Negotiation for Designers** Use this when: you have a job offer or are entering a compensation conversation and want a structured script for negotiating confidently — without leaving money on the table. Write a salary negotiation script for a UX designer. My situation: [describe the offer — total comp, level, location — and your current situation — competing offers, current salary, time in market]. Market context: [what you know about market compensation — e.g., 'Levels.fyi shows mid-level product designers in San Francisco averaging $165–185k total comp / I have a competing offer for $170k']. What I want to achieve: [your target number and what you care about beyond salary — equity, signing bonus, title, remote flexibility]. The script should cover: (1) Opening response when you receive the offer — buy time without killing momentum, (2) The counter — how to present your counter with a clear rationale (market data + experience), (3) Handling the most likely pushback — 'That's above our band' / 'We can't move on salary, but...' / 'We need to know today,' (4) The close — how to accept or decline professionally and preserve the relationship. Write in first person, natural spoken language. Include fallback language for each scenario. Why it works: Most designers accept the first offer because they lack a script for what to say next. A prepared negotiation script removes the emotional hesitation and gives you a specific path through the conversation — the difference between accepting 90% of market rate and 105%.

**Prompt 24: LinkedIn Headline Optimization** Use this when: your LinkedIn headline is your job title and company — and you want something that communicates your value, attracts the right opportunities, and stands out in search. Optimize my LinkedIn headline for a UX designer. My background: [describe your experience, specialization, and career level — e.g., 5 years of product design experience with a focus on B2B SaaS onboarding and growth / 10 years of design leadership across e-commerce and fintech / entry-level designer with a background in psychology and HCI]. What I want to attract: [job type, company stage, industry — e.g., senior IC roles at growth-stage startups / design leadership roles at enterprise SaaS / freelance UX consulting for funded startups]. Current headline: [paste your current headline]. Write 5 alternative headlines that: (1) Include relevant keywords for searchability (product designer, UX designer, design systems, etc.), (2) Communicate a specific value or specialization (not just a job title), (3) Signal career level without being overly formal, (4) Are under 220 characters. For each: explain why it works and which type of opportunity it's most likely to attract. Why it works: 'UX Designer at [Company]' is a business card, not a professional brand. A headline that communicates your specialization and the value you create attracts inbound opportunities — recruiter messages, conference invitations, freelance leads — that a generic title never will.

**Prompt 25: UX Design Interview Prep** Use this when: you have a design interview coming up and want to prepare compelling, structured answers that demonstrate process, impact, and self-awareness — without sounding over-rehearsed. Help me prepare for a UX design interview at [company type — e.g., a growth-stage B2B SaaS startup / a FAANG-scale consumer product company / an in-house agency at a Fortune 500]. Role level: [junior / mid / senior / lead]. Interview format: [portfolio review + behavioral / design challenge / whiteboard critique / take-home + debrief]. Prepare me for: (1) Portfolio case study framing — how to tell the story of my 2 strongest case studies in 5–7 minutes each, structured around problem / process / decision-making / outcome, (2) Behavioral questions — likely behavioral questions for this level and company type, with STAR-format answer frameworks, (3) Design critique practice — a practice critique prompt for a product I should know well at this company, with a framework for structuring the critique, (4) 'Tell me about yourself' — a 90-second version tailored to this role and company, (5) Questions to ask — 5 thoughtful questions that demonstrate strategic thinking and genuine interest. My background: [brief summary of your experience]. Focus on the 3 areas where I'm most likely to stumble. Why it works: Design interviews are lost in the preparation phase, not in the room. Designers who walk in with structured frameworks for their case studies, practiced behavioral answers, and prepared critique approaches consistently outperform equally-skilled designers who wing it.