AI prompts for
UX/UI designers.

Design brief from a vague request

Use it when: A client or manager gives you a one-line request and you need a clear brief.

Turn this request into a design brief:
"[PASTE THE REQUEST]"

What I know so far: [CONTEXT, USERS, PRODUCT].

Structure the brief as: background, problem to solve, target users, goals (user and business), success metrics, scope (in / out), constraints, deliverables, timeline, stakeholders and open questions. Mark every item you had to assume so I can confirm it with the requester.

Competitor flow teardown

Use it when: You want to learn from how competitors handle the same task.

I reviewed how [COMPETITOR] handles [TASK, e.g. onboarding / checkout / booking]. Here are my notes and screen-by-screen observations:
[PASTE NOTES]

Analyse it as a product designer: the steps and friction points, patterns used, what they do well, trade-offs they seem to make, and 3 ideas we could adapt (not copy) for [OUR PRODUCT] with our users [USERS]. Separate my observations from your interpretations.

Opportunity solution tree

Use it when: You want to connect a business outcome to user opportunities and ideas.

Build an opportunity solution tree.

Desired outcome: [OUTCOME, e.g. increase repeat bookings by 15%]
Research insights: [PASTE KEY FINDINGS]

Show: the outcome → 4–6 user opportunities (needs, pain points, desires) grounded in the insights → 2–3 solution ideas per opportunity → a quick assumption test for the most promising ideas. Format it as an indented list and flag opportunities that lack evidence.

Design principles for a product

Use it when: Your team needs shared principles to guide decisions.

Draft 5 design principles for [PRODUCT] used by [USERS].

Context: brand values [VALUES], what users care about most [INSIGHTS], and common team debates [e.g. speed vs completeness].

For each principle give: a short memorable name, one sentence explaining it, what it means in practice (a do and a don't), and an example decision it would settle. Avoid generic principles like "simple" unless you make them specific.

Value proposition canvas

Use it when: You want to check whether the product fits real customer needs.

Fill in a value proposition canvas for [PRODUCT] and the customer segment [SEGMENT], using this research: [PASTE].

Customer profile: jobs, pains, gains. Value map: products and services, pain relievers, gain creators. Then assess the fit: which pains and gains we address well, which we ignore, and what to validate next. Mark anything not supported by the research.

Lean UX hypothesis

Use it when: You want to frame a feature as a testable bet.

Write a Lean UX hypothesis for [FEATURE IDEA].

Use: "We believe that [building this feature] for [these users] will achieve [this outcome]. We will know this is true when we see [measurable signal]."

Then list the riskiest assumptions behind it, the smallest experiment to test each (e.g. fake door, concierge, prototype test), and what result would make us stop, pivot or continue.

Kick-off workshop plan

Use it when: You are starting a new project with a team or client.

Plan a [LENGTH] project kick-off workshop for [PROJECT] with [PARTICIPANTS].

Goals: align on the problem, users, success metrics, scope and risks. Include an agenda with timings, activities (e.g. goals and anti-goals, assumption mapping, risk storming), what to prepare beforehand, a template to capture decisions, and a follow-up email summary structure.

Quick heuristic market scan for a new idea

Use it when: You need a fast view of the problem space before a project.

I am exploring an idea: [IDEA] for [USERS] in [MARKET, e.g. India].

Help me structure a quick discovery: the main user needs to explore, types of existing solutions (direct, indirect, offline workarounds), questions to ask 5 potential users this week, signals that the problem is worth solving, and risks to check early. Mark everything as hypotheses to validate.

Write a research plan

Use it when: You are starting a project and need a clear, lightweight research plan.

Help me write a UX research plan.

Context:
- Product: [PRODUCT AND WHO IT IS FOR]
- What we already know: [KNOWN FACTS, DATA, FEEDBACK]
- Decision this research should support: [DECISION]
- Constraints: [TIME, BUDGET, ACCESS TO USERS]

Include: background, research goals, 4–6 research questions, recommended methods with reasons, participant criteria, number of participants, timeline, risks, and how findings will be shared.

Keep research questions about user behaviour and needs, not about our solution.

Choose the right research method

Use it when: You are unsure whether to run interviews, a survey, a usability test or something else.

I need to choose a UX research method.

What I want to learn: [QUESTION]
Product stage: [idea / early design / live product]
Available time: [TIME]
Access to users: [e.g. 5 customers, analytics only, none]

Compare 3–4 suitable methods (for example interviews, contextual inquiry, survey, diary study, usability testing, analytics review, card sorting). For each: what it answers well, what it cannot answer, effort, and sample size. Recommend one method or combination and explain why.

Turn assumptions into research questions

Use it when: Your team has opinions and you want to test them properly.

Here are our team's assumptions about our users:
[LIST ASSUMPTIONS]

For each assumption:
1. Rate how risky it is if we are wrong (high / medium / low) and why
2. Rewrite it as a neutral research question
3. Suggest the quickest way to test it

Then rank the assumptions by what we should test first. Present it as a table.

Participant screener

Use it when: You need to recruit the right people for interviews or tests.

Write a participant screener for a study about [TOPIC].

We want to talk to: [TARGET USERS, e.g. people in India who ordered groceries online at least twice in the last month]
We want to exclude: [e.g. people working in tech or design, competitors' employees]

Write 6–8 short screening questions. Avoid leading questions and don't reveal the ideal answer. For each question mark which answers qualify or disqualify. Add a short, friendly invitation message I can send on WhatsApp or email.

Competitive analysis framework

Use it when: You want a structured comparison of competitor products.

Create a competitive analysis framework for [PRODUCT CATEGORY, e.g. fitness apps in India].

Competitors to compare: [LIST 3–5, or ask me to add them]

Suggest the criteria to compare (for example onboarding, core task flow, pricing clarity, accessibility, trust signals, content tone) and a table I can fill in. Tell me what to observe for each criterion and how to turn the comparison into 3–5 design opportunities.

Do not invent facts about competitors; leave cells for me to fill after I review the products myself.

Pilot an interview guide with a synthetic user

Use it when: You want to rehearse and improve your questions before talking to real participants.

I will interview [TARGET USERS] about [TOPIC]. Before real interviews, I want to pilot my guide.

Role-play one realistic participant: [BRIEF DESCRIPTION]. I will ask questions one at a time. Answer naturally and briefly, the way a real person would, including vague or off-topic answers.

After I type "END PILOT", step out of the role and give me feedback on my questions: which were leading, confusing, double-barrelled or too abstract, and how to improve them.

Remember: this is only practice. Your answers are not research data.

Good practice: Treat AI "users" as rehearsal partners only. Findings must come from real people.

Diary study plan

Use it when: You need to understand behaviour over days or weeks.

Plan a [DURATION] diary study about [TOPIC] with [PARTICIPANTS].

Include: study goals, number of participants, entry prompts for each day or trigger (short and easy on a phone, e.g. WhatsApp or a form), a mid-study check-in, incentive suggestions, how to keep participants engaged, and how to analyse entries. Keep the effort for participants under 5 minutes a day.

Analytics funnel review

Use it when: You have product data and want to find where users drop off.

Here is funnel data for [FLOW]:
[PASTE STEP NAMES, USERS AT EACH STEP, TIME PERIOD, DEVICE SPLIT]

Calculate the drop-off at each step, identify the biggest leaks, and suggest possible UX causes for each (clearly labelled as hypotheses). Then recommend what qualitative research or session recordings would confirm the cause, and which fix to test first.

Mixed-methods research roadmap

Use it when: You need a research plan for a quarter, not a single study.

Create a [3-month] research roadmap for [PRODUCT].

Our key questions: [LIST]. Team capacity: [PEOPLE, BUDGET]. Upcoming product decisions: [DECISIONS AND DATES].

Sequence studies so each informs the next (e.g. analytics → interviews → survey → usability tests). For each study give: question, method, timing, participants, and the decision it supports. Keep it realistic for our capacity.

User interview guide

Use it when: You are preparing for user interviews.

Write a 45-minute user interview guide.

Topic: [TOPIC]
Participants: [WHO]
Research goals: [GOALS]

Structure it as: warm-up (5 min), current behaviour (15 min), pain points and workarounds (15 min), wrap-up (5 min).

Use open, non-leading questions about past behaviour ("Tell me about the last time…"). Avoid questions about the future or hypothetical features. Add 2–3 follow-up probes for each main question and a short consent and recording script at the start.

Fix my leading questions

Use it when: You have drafted questions and want to remove bias.

Review these interview or survey questions for bias:
[PASTE QUESTIONS]

For each question say whether it is leading, closed, double-barrelled, hypothetical, jargon-heavy or fine. Explain the problem in one line and rewrite it. Keep my research goal: [GOAL].

Survey design

Use it when: You need a short, well-structured survey.

Design a survey to learn [GOAL] from [AUDIENCE].

Rules:
- Maximum 10 questions, completable in under 5 minutes on a phone
- Start with easy screening questions
- Use balanced answer scales and include "Not applicable" where needed
- Maximum 2 open-ended questions
- No leading or double-barrelled questions

For each question show the question type and answer options. Then explain how I should analyse the results and the sample size I need for reasonable confidence.

Contextual inquiry plan

Use it when: You want to observe people doing a task in their own environment.

Help me plan a contextual inquiry with [USERS, e.g. pharmacy owners] while they [TASK, e.g. manage stock].

Include: what to observe, questions to ask during the task, artefacts to photograph or collect (with permission), a note-taking template, ethical considerations, and how to avoid influencing their behaviour. Keep it practical for a solo designer with [TIME].

Stakeholder interview questions

Use it when: You are starting with a new client or team and need business context.

I am a designer starting a project on [PROJECT]. Write interview questions for stakeholders in [ROLES, e.g. founder, sales lead, support lead, engineering lead].

Cover: business goals and success metrics, target users, known problems, constraints (technical, legal, budget, timeline), previous attempts, and how decisions are made. Group questions by role and mark the 3 most important per role.

Interview note-taking template

Use it when: You want consistent notes that are easy to analyse later.

Create a note-taking template for user interviews about [TOPIC].

Include sections for: participant details (no personal identifiers), context, goals, current process step by step, quotes, pain points, workarounds, emotions, surprises and follow-up ideas. Add a short guide on separating what the participant said from my interpretation.

Affinity mapping from notes

Use it when: You have interview notes and need to find patterns.

Here are anonymised notes from [NUMBER] user interviews about [TOPIC]:
[PASTE NOTES — remove names, phone numbers and other personal data]

Group the observations into themes like an affinity map. For each theme give: a clear name, the supporting observations, how many participants mentioned it, and a representative quote.

Only use what is in the notes. If a theme rests on one participant, say so. Finally list open questions we still need to research.

Good practice: Remove personal data before pasting notes into any AI tool, and check your organisation's policy first.

Turn findings into insights

Use it when: You have observations but need sharp, actionable insights.

Turn these research findings into insights:
[PASTE FINDINGS]

For each insight use the structure: "[User group] need [need] because [reason], but currently [barrier]." Then add the evidence, the confidence level (high/medium/low) and one design implication.

Do not add needs that the findings don't support.

Write How Might We questions

Use it when: You want to move from problems to ideas.

Here is our key research insight:
[INSIGHT]

Write 8 "How might we…" questions that open up different directions. Vary the scope: some narrow, some broad, some that flip the problem. Then pick the 3 strongest and explain why they are neither too broad nor too narrow.

Research readout summary

Use it when: You need to share findings with stakeholders who have little time.

Write a one-page research summary for [AUDIENCE, e.g. product manager and developers].

Study: [WHAT WE DID, WITH WHOM, HOW MANY]
Findings: [PASTE FINDINGS]

Structure: the headline in one sentence, 3–5 key findings with evidence, what this means for the product, recommended next steps, and limitations of the study. Use plain language and keep it under 400 words.

Analyse open-ended survey answers

Use it when: You have many free-text survey responses.

Below are [NUMBER] open-ended answers to the question "[QUESTION]":
[PASTE RESPONSES]

1. Code the responses into themes and give the count and percentage for each
2. Show 2 representative quotes per theme
3. Highlight surprising or minority responses that deserve attention
4. Note any answers you could not classify

Show your coding rules so I can check them. Do not invent responses.

Challenge my conclusions

Use it when: You want to test your synthesis for bias before presenting it.

Here are my research conclusions and the evidence behind them:
[PASTE]

Act as a critical research lead. For each conclusion: identify possible biases (confirmation, sampling, recency, leading questions), alternative explanations, and what additional evidence would make it stronger. Be direct but constructive.

Summarise support tickets into UX issues

Use it when: You have customer support data and want design priorities.

Here are [NUMBER] anonymised support tickets or app reviews:
[PASTE]

Group them into UX problem themes, count how often each appears, separate bugs from usability problems and feature requests, quote 2 examples per theme, and suggest which screens or flows to investigate first. Don't invent issues that aren't in the data.

Good practice: Remove names, phone numbers and order IDs before pasting.

Combine qualitative and quantitative findings

Use it when: You have interview insights and analytics data that need to tell one story.

Qualitative findings: [PASTE INTERVIEW OR USABILITY INSIGHTS]
Quantitative data: [PASTE METRICS, FUNNEL OR SURVEY RESULTS]

Connect them: where do the numbers confirm the qualitative findings, where do they contradict them, and what might explain the gaps? Suggest 3 combined insights with the evidence from both sides, how confident we can be, and what to research next. Don't overstate causation.

Persona from real research

Use it when: You have research data and want a persona grounded in it.

Create a persona using ONLY this research data:
[PASTE SYNTHESISED FINDINGS]

Include: name and short description, context, goals, frustrations, behaviours, tools they use, a representative quote, and what they need from our product. Avoid demographic stereotypes that the data doesn't support. Mark any field where the data is thin.

Good practice: A persona is only as good as the research behind it. Don't use AI-invented personas as evidence.

Proto-persona to test later

Use it when: You have no research yet and need a starting hypothesis.

Help me create a proto-persona (an assumption-based hypothesis) for [PRODUCT] aimed at [AUDIENCE].

Clearly label it "Hypothesis — not validated". List the assumptions behind each attribute and, for each, a research question that would confirm or disprove it.

Customer journey map

Use it when: You want to visualise an end-to-end experience.

Create a customer journey map for [PERSONA] trying to [GOAL] using [PRODUCT OR SERVICE].

Stages: [e.g. discover, compare, sign up, first use, repeat use]
For each stage give: user actions, touchpoints, thoughts, emotions (positive/neutral/negative), pain points and opportunities.

Base it on this research: [PASTE FINDINGS or write "assumption-based — label as hypothesis"]. Present it as a table.

Empathy map

Use it when: You want to summarise what a user says, thinks, does and feels.

Create an empathy map for [USER] in the situation [SITUATION] using this research: [PASTE].

Fill in: Says, Thinks, Does, Feels, plus Pains and Gains. Use real quotes for "Says" and mark interpretations clearly as interpretations.

Problem statement

Use it when: You need a clear problem to design for.

Write 3 alternative problem statements based on this insight: [INSIGHT].

Use the format: "[User] needs a way to [need] because [insight]. We will know we have succeeded when [measurable outcome]."

Keep them solution-free. Then tell me which is the strongest and why.

Jobs-to-be-done statements

Use it when: You want to frame needs around what users are trying to get done.

From this research [PASTE], write jobs-to-be-done statements in the format: "When [situation], I want to [motivation], so I can [expected outcome]."

Group them into a main job and related jobs, and add the functional, emotional and social dimensions for the main job. Only use what the research supports.

Information architecture draft

Use it when: You are organising content or features for an app or website.

Propose an information architecture for [PRODUCT] for [USERS].

Content and features to include:
[LIST]

Give: a sitemap (as an indented list), the labelling logic, the top-level navigation with reasons, and items that might be hard to place. Suggest how I can validate this with a card sort or tree test.

Card sorting study setup

Use it when: You want users to help you group and label content.

Help me plan a card sorting study for [PRODUCT].

Cards: [LIST 30–60 ITEMS]

Recommend open, closed or hybrid sorting and explain why. Review my card labels for ambiguity and suggest clearer wording. Give participant instructions, the number of participants, and how to analyse the results (similarity matrix, common groups, disagreements).

Tree test tasks

Use it when: You want to test whether people can find things in your navigation.

Here is my navigation tree:
[PASTE TREE]

Write 8 tree-testing tasks based on real user goals. Phrase tasks without using the exact labels from the tree. For each task give the correct answer path. Then tell me what success rate and directness would suggest a problem.

User flow

Use it when: You need to map the steps of a task.

Create a user flow for [USER] completing [TASK] in [PRODUCT].

Start point: [ENTRY, e.g. push notification or home screen]
End point: [SUCCESS STATE]

List every screen, decision point and system response in order. Include the happy path plus alternative paths for: errors, returning users, missing information and cancellation. Format it so I can redraw it in FigJam (for example: Screen → Action → Decision → Next screen).

Find the edge cases

Use it when: Your flow only covers the happy path.

Here is my user flow for [TASK]:
[PASTE FLOW]

List the edge cases and unhappy paths I have missed, grouped by: user errors, system errors, empty states, slow or no network, permissions, interruptions, accessibility, and different user types. For each, suggest how the design should respond.

Navigation pattern recommendation

Use it when: You are deciding between tabs, a hamburger menu, a sidebar and so on.

Recommend a navigation pattern for [PRODUCT] on [PLATFORMS: mobile app / responsive web / desktop].

Main sections: [LIST]
Most frequent tasks: [LIST]

Compare suitable patterns (bottom tabs, top tabs, hamburger, sidebar, hub-and-spoke) with pros, cons and platform conventions. Recommend one and explain how it handles the most frequent tasks.

Service blueprint

Use it when: The experience involves people and processes behind the screen.

Create a service blueprint for [SERVICE, e.g. booking a home repair].

Include rows for: customer actions, frontstage (visible) interactions, backstage actions, support processes and systems, and evidence/touchpoints. Mark failure points and waiting times, and suggest 3 improvements that would most improve the customer experience.

Generate many ideas fast

Use it when: You need a wide range of ideas before choosing a direction.

Problem: [HOW MIGHT WE QUESTION]
Users: [USERS]. Constraints: [CONSTRAINTS].

Generate 20 ideas in 4 groups: quick wins, bold ideas, ideas that remove a step entirely, and ideas borrowed from other industries. One line each. Then pick the 3 most promising based on user value and feasibility, and explain why.

SCAMPER an existing feature

Use it when: You want to improve a feature instead of starting from scratch.

Apply SCAMPER to [FEATURE] in [PRODUCT].

For each lens (Substitute, Combine, Adapt, Modify/Magnify, Put to other use, Eliminate, Reverse) give 2 concrete ideas tied to our users' needs: [NEEDS]. Finish by ranking the top 3 ideas by impact and effort.

Storyboard a concept

Use it when: You want to show how a concept fits into a user's day.

Write a 6-panel storyboard for [CONCEPT] from the point of view of [PERSONA].

For each panel describe: the setting, what the person does and feels, what the product does, and a short caption. Show the trigger, the moment of use and the outcome. Keep it realistic for users in [CONTEXT, e.g. tier-2 cities in India on a mid-range Android phone].

Concept evaluation matrix

Use it when: You have several concepts and need to choose objectively.

Help me compare these concepts:
[LIST CONCEPTS WITH SHORT DESCRIPTIONS]

Create an evaluation matrix with criteria: user value, alignment with research, business impact, technical feasibility, effort, risk and accessibility. Suggest weights, score each concept 1–5 with a one-line reason, and recommend what to prototype. Point out where the scores rely on assumptions.

Analogous inspiration

Use it when: You want fresh ideas from other industries.

Our challenge: [CHALLENGE, e.g. reducing anxiety while waiting for a medical test result].

Suggest 6 analogous situations in other industries or everyday life that solve a similar underlying problem. For each explain the shared need, what they do well, and one idea we could adapt for [OUR PRODUCT].

Crazy 8s prompts

Use it when: You are running a sketching session.

I am running a Crazy 8s sketching session on [PROBLEM].

Give me 8 different angles to sketch, one per frame (e.g. the fastest version, a voice-first version, a version for first-time users, a version with no text input). For each angle add a one-line hint of what to draw. Then give 5 questions to discuss the sketches afterwards.

Wireframe content brief

Use it when: You want to plan what goes on a screen before sketching.

I am designing the [SCREEN, e.g. product detail page] for [PRODUCT]. The user's goal on this screen is [GOAL] and the business goal is [GOAL].

List the content and components the screen needs, in order of priority, with a short reason for each. Mark what must be above the fold on mobile. Suggest one primary action and any secondary actions. Don't design visuals; focus on content and hierarchy.

Screen states checklist

Use it when: You want to design every state, not just the perfect one.

For the [SCREEN OR COMPONENT] in [PRODUCT], list every state I should design: empty, loading, partial data, ideal, error, offline, no permission, first-time use, and success.

For each state describe what the user sees, the message or microcopy, and the action available to them.

Form design review

Use it when: You are designing a sign-up, checkout or application form.

Review this form for usability:
[LIST FIELDS, LABELS, ORDER, VALIDATION RULES]

The form's purpose: [PURPOSE]. Users: [USERS], mostly on [DEVICE].

Check: unnecessary fields, field order, label clarity, input types and keyboards on mobile, inline validation, error messages, accessibility, and trust (privacy, why we ask). Give a prioritised list of improvements.

Explore design alternatives

Use it when: You are stuck on one solution and want other directions.

The problem: [PROBLEM STATEMENT]
My current idea: [DESCRIBE]

Suggest 5 alternative design approaches that are genuinely different (for example a different pattern, flow order, level of automation or entry point). For each: how it works, who it suits, risks, and how to test it quickly. Then tell me which to prototype first.

Micro-interaction specification

Use it when: You need to describe an interaction for developers.

Write a micro-interaction spec for [INTERACTION, e.g. adding an item to the cart].

Use the structure: trigger, rules, feedback (visual, haptic, sound), states, timing and easing, loops/modes, and reduced-motion behaviour. Keep durations realistic for mobile and explain why the feedback helps the user.

Promptframe for an AI feature

Use it when: Your screen includes AI-generated content and you need to specify it.

I am designing a screen where AI generates [CONTENT, e.g. a trip summary]. Help me write a promptframe (a wireframe annotation for generated content).

For each AI-generated area specify: purpose, inputs the AI receives, desired tone and length, what it must never include, how the user can edit or regenerate it, how we show uncertainty or sources, and a fallback when generation fails.

Search experience design

Use it when: You are designing search for an app or website.

Design the search experience for [PRODUCT], where users search for [ITEMS].

Cover: search entry point, suggestions and autocomplete, recent and popular searches, spelling mistakes and transliteration (e.g. Hinglish), filters and sorting, results layout, zero-results state, and loading. For each part recommend a pattern and explain why it fits our users [USERS].

Filters and sorting pattern

Use it when: Users need to narrow down a long list.

Recommend a filter and sort design for [LIST, e.g. 500 hotel results] on [mobile / desktop].

Filters available: [LIST]. Most used filters: [IF KNOWN].

Compare patterns (filter bar, bottom sheet, sidebar, chips), explain how to show applied filters, clear-all, result counts, and what happens when filters return nothing. Recommend one approach.

Complex flow simplification

Use it when: A multi-step process feels long and confusing.

This flow has [NUMBER] steps:
[LIST STEPS AND FIELDS]

Help me simplify it: which steps can be removed, merged, reordered, automated, deferred until later, or pre-filled from data we already have? Suggest a progress indicator approach and how to save progress. Show the new flow and estimate the reduction in steps and fields.

Notification and alert design

Use it when: You need to choose between toasts, banners, modals and badges.

For each message below, recommend the right pattern (inline message, toast/snackbar, banner, modal dialog, badge, push notification or email) and explain why:
[LIST MESSAGES AND WHEN THEY HAPPEN]

Consider urgency, whether the user must act, persistence, accessibility (screen reader announcements) and interruption cost.

Motion spec for a UI animation

Use it when: You are animating a transition in a tool like Figma Motion and need a clear spec.

I am animating [INTERACTION, e.g. a bottom sheet opening] in [PRODUCT].

Write a motion spec: the purpose of the motion (what it helps the user understand), start and end states, which properties change, duration and easing for each, sequencing and delays, how it behaves when interrupted, and the reduced-motion alternative. Keep durations realistic for mobile (most under 300 ms) and explain why.

Microcopy options

Use it when: You need clear text for buttons, labels or helper text.

Write 5 options for [UI ELEMENT, e.g. the main button on a payment screen] in [PRODUCT].

Context: the user is trying to [GOAL]. Our voice is [e.g. friendly, clear, professional]. Character limit: [LIMIT].

For each option explain the tone and when it works best. Recommend one. Use plain language that works for users with basic English.

Helpful error messages

Use it when: Your error messages are vague or technical.

Rewrite these error messages to be clear, human and helpful:
[PASTE MESSAGES AND WHEN THEY APPEAR]

Each message should say what happened, why (if helpful), and how to fix it. No blame, no jargon, no error codes on their own. Keep each under [LIMIT] characters.

Empty state copy

Use it when: A screen has no content yet and you want to guide the user.

Write empty-state copy for [SCREEN, e.g. saved items] in [PRODUCT].

Include: a short headline, one line explaining the value of this screen, and a call-to-action button label. Give 3 variations: helpful, encouraging and playful. Match our voice: [VOICE].

Onboarding copy

Use it when: You are designing first-run screens.

Write onboarding copy for [PRODUCT] with [NUMBER] screens.

Users: [USERS]. Their main goal: [GOAL]. The one action we want them to take first: [ACTION].

For each screen give a headline (max 6 words), body (max 20 words) and button label. Focus on user benefits, not features, and let users skip.

Content style guide

Use it when: Your product's writing is inconsistent.

Create a short content style guide for [PRODUCT] used by [AUDIENCE].

Include: voice (3 traits with do/don't examples), tone for different situations (success, error, warning, empty, marketing), capitalisation, numbers, dates and currency (Indian formats: ₹1,25,000 and DD MMM YYYY), inclusive language, and a list of preferred terms. Keep it to one page.

Simplify complex text

Use it when: You have legal, financial or technical text users struggle with.

Rewrite this text in plain language for [AUDIENCE] with a reading level of about [LEVEL, e.g. class 8]:
[PASTE TEXT]

Keep the meaning accurate. Use short sentences, everyday words and bullet points where they help. After the rewrite, list anything I should confirm with a legal or domain expert.

Push notification copy

Use it when: You are writing notifications that people actually want.

Write push notifications for [PRODUCT] for these triggers:
[LIST TRIGGERS, e.g. order shipped, cart abandoned, streak about to break]

For each give a title (max 40 characters) and body (max 90 characters), 2 variations, and the best time to send. Keep them helpful and specific, never guilt-tripping or clickbait, and suggest which ones users should be able to switch off.

Localise copy for Indian languages

Use it when: Your product needs to work in Hindi, Telugu or other languages.

Prepare this English UI copy for localisation into [LANGUAGES]:
[PASTE STRINGS]

Flag: text that will expand or shrink, idioms or culture-specific phrases, gendered language, string concatenation problems, date/number/currency formats, and places where a transliterated English word may be clearer than a formal translation. Suggest changes to the English source that make translation easier.

Good practice: Always have translations reviewed by a native speaker.

Consent screens that people understand

Use it when: You need privacy consent or permission copy, for example under India's DPDP Act.

Write the consent experience for [PRODUCT] when we collect [DATA] for [PURPOSE].

Include: a short, plain-language notice (what, why, how long, who it's shared with), separate choices for optional purposes, how to withdraw consent later, and the settings screen copy. Keep it honest and easy to read on mobile, in [LANGUAGES]. List questions I must confirm with a legal expert, for example requirements under India's Digital Personal Data Protection Act, 2023.

Good practice: Have legal or privacy experts review consent copy before launch.

Visual hierarchy critique

Use it when: A screen feels busy or the main action gets lost.

Critique the visual hierarchy of my screen. Here is a description (or upload a screenshot):
[DESCRIBE LAYOUT, TEXT SIZES, COLOURS, BUTTONS]

The user's main goal on this screen: [GOAL].

Tell me what draws attention first, second and third; whether the primary action stands out; issues with spacing, alignment, contrast and grouping; and 5 specific improvements in priority order.

Colour palette with accessible contrast

Use it when: You are creating a colour system for a product.

Create a UI colour palette for [PRODUCT] with the brand colour [HEX] and the personality [e.g. trustworthy, energetic].

Include: primary, secondary, neutral greys (10 steps), and semantic colours (success, warning, error, info), each with hex values. For every text/background pair I am likely to use, state the WCAG contrast ratio and whether it passes AA for normal text.

I will verify every ratio with a contrast checker before using it.

Good practice: Always verify AI-calculated contrast ratios with a contrast checker.

Typography scale

Use it when: You need a consistent type system.

Suggest a typography system for [PRODUCT] on [PLATFORM].

Recommend 1–2 free fonts that support [LANGUAGES, e.g. English and Hindi], a type scale (sizes, line heights, weights) for display, headings, body, captions and labels for both mobile and desktop, and rules for line length and paragraph spacing. Explain the ratio you used.

Spacing and layout grid

Use it when: Your layouts feel inconsistent.

Define a spacing and layout system for [PRODUCT].

Include: a spacing scale based on a 4 or 8 point grid, layout grids for mobile (360–430px), tablet and desktop (columns, gutters, margins), common spacing rules (between sections, cards, form fields), and how to apply them in Figma with auto layout.

Moodboard direction

Use it when: You want to define a visual direction before designing.

Help me define 3 distinct visual directions for [PRODUCT] aimed at [AUDIENCE]. Brand values: [VALUES].

For each direction describe: the feeling, colour approach, typography style, imagery and iconography, shape language (corners, shadows), and 5 search terms I can use to collect inspiration on Pinterest, Dribbble or Mobbin. Say which audience each direction suits best.

Dark mode adaptation

Use it when: You are adding a dark theme.

Help me adapt this light theme to dark mode:
[LIST COLOUR TOKENS AND VALUES]

Suggest dark-mode values for each token, explain how to handle elevation, shadows, brand colours, images and illustrations, and list contrast pairs I must check. Avoid pure black backgrounds unless there is a reason.

UI design feedback like a senior

Use it when: You want honest feedback on a finished screen.

Act as a senior product designer reviewing a junior's work. Here is my screen (screenshot or description): [ATTACH OR DESCRIBE]

Its purpose: [PURPOSE]. Target users: [USERS].

Give feedback on: clarity, hierarchy, consistency, spacing, typography, colour, accessibility and interaction cues. Start with what works, then the 5 most important improvements, each with the reason. Be specific and kind, not generic.

Button hierarchy system

Use it when: Screens have too many competing buttons.

Define a button hierarchy for [PRODUCT]: primary, secondary, tertiary/text, destructive and icon buttons.

For each: when to use it, visual style, sizes, states (default, hover, focus, pressed, loading, disabled), minimum touch target, and rules such as "only one primary action per view". Include examples of common mistakes.

Icon style brief

Use it when: You need a consistent icon set.

Write an icon style brief for [PRODUCT].

Include: style (outline, filled or duotone) and when to use each, grid and keyline sizes, stroke width, corner radius, level of detail, colour usage, how icons pair with text, accessibility (labels, not relying on icons alone), and a list of the first 30 icons we need for [KEY FEATURES].

Data-dense interface layout

Use it when: You are designing an admin tool or enterprise screen with lots of information.

I am designing a data-dense screen for [USERS, e.g. operations managers] who need to [TASKS].

Information on screen: [LIST]

Recommend a layout that supports scanning and quick action: density settings, grouping, typography for numbers, table vs cards, sticky headers, progressive disclosure and keyboard shortcuts. Explain how to keep it readable without hiding important data.

Illustration and imagery guidelines

Use it when: You want imagery that feels consistent and inclusive.

Create illustration and photography guidelines for [PRODUCT] aimed at [AUDIENCE].

Cover: style, colour use, representation of people (diverse skin tones, ages, body types, regional clothing), where imagery adds value vs decoration, file formats and sizes for performance, alt text rules, and 5 do's and don'ts.

Turn a moodboard into a visual direction

Use it when: You collected inspiration and need a clear, usable visual direction.

Here are the references in my moodboard and what I like about each: [LIST REFERENCES AND NOTES].

Product: [PRODUCT]. Users: [USERS]. Brand values: [VALUES].

Summarise the common visual direction (colour, type, shape, imagery, density, motion), point out references that conflict with each other, and translate the direction into 10 concrete design rules I can apply. Flag anything that may hurt accessibility or readability.

Component structure plan

Use it when: You are building reusable components.

Help me plan a Figma component for [COMPONENT, e.g. a text input].

List: the properties (variants, boolean, text and instance-swap properties), all states (default, hover, focus, filled, error, disabled), sizes, how to name layers and properties, and how auto layout should be set so it resizes correctly. Keep the number of variants manageable.

Prototype plan for testing

Use it when: You are preparing a clickable prototype for a usability test.

I want to test [TASKS] with a Figma prototype of [PRODUCT].

Tell me which screens and states the prototype must include, which interactions need to work (and which can be faked), how to handle text input, realistic content to use instead of lorem ipsum, and a checklist to test the prototype before the session.

Organise a messy Figma file

Use it when: Your file is hard to navigate or hand off.

Suggest a clean structure for a Figma file for [PROJECT].

Include: page structure (for example cover, research, flows, wireframes, UI, components, archive), frame naming conventions, layer naming, how to mark work-in-progress vs ready-for-dev, and a cover page checklist.

Realistic content for mockups

Use it when: You need believable data instead of lorem ipsum.

Generate realistic sample content for [SCREEN, e.g. a list of 10 orders in a food-delivery app] for users in [COUNTRY/CITY].

Include varied lengths (short and very long names), edge cases (missing images, zero values, long addresses) and Indian formats for currency, phone numbers and dates. Return it as a table I can paste into Figma. Use made-up names only.

Prompt an AI prototyping tool

Use it when: You use tools like Figma Make, v0 or Lovable to generate a first draft UI.

Build a [PLATFORM: mobile / web] screen for [PRODUCT].

Context: [WHO THE USERS ARE AND THEIR GOAL]
Screen: [SCREEN NAME] — the user needs to [TASK].
Content, in priority order: [LIST]
Primary action: [ACTION]. Secondary: [ACTIONS].
States to include: [e.g. loading, empty, error].
Visual style: [e.g. clean, 8pt spacing, brand colour #HEX, Inter font, rounded 12px cards].
Constraints: accessible contrast (WCAG AA), 44px minimum touch targets, responsive from 360px.

Do not add features I did not ask for.

Good practice: Detailed prompts give far more consistent AI prototypes than vague ones. Treat the output as a sketch to refine.

Turn a design system into AI-ready context

Use it when: You want AI prototyping tools to follow your design system.

I want AI prototyping tools to generate screens that follow our design system.

Our system: colours [TOKENS], typography [SCALE], spacing [SCALE], components [LIST], tone of voice [VOICE].

Write a concise design-system brief (under 400 words) I can paste into an AI design tool as context: rules, component names and when to use them, do's and don'ts, and accessibility requirements. Then write one example prompt that uses it to generate [SCREEN].

Adapt a desktop design for mobile

Use it when: You have a desktop layout and need a mobile-first version.

Here is my desktop screen: [DESCRIBE LAYOUT AND CONTENT, OR ATTACH SCREENSHOT]

Adapt it for a 360–430px mobile screen. Decide what to keep, reorder, collapse, move into a bottom sheet or remove; where the primary action should sit for thumb reach; how tables and side navigation should change; and what must stay visible without scrolling. Explain each decision.

Responsive behaviour spec

Use it when: Developers need to know how a layout changes across screen sizes.

Write a responsive behaviour spec for [SCREEN/COMPONENT] at these breakpoints: [e.g. 360, 768, 1024, 1440].

For each breakpoint describe: grid and columns, what stacks or reflows, font sizes, image behaviour, navigation changes, and hidden or added elements. Note edge cases like very long text, landscape phones and browser zoom at 200%.

iOS vs Android conventions

Use it when: You are designing a native app for both platforms.

For [FEATURE] in our app, explain where iOS (Human Interface Guidelines) and Android (Material Design) conventions differ: navigation, back behaviour, tabs, action placement, dialogs, date pickers, typography and gestures.

Recommend where we should follow each platform's convention and where a shared design is fine. Tell me to confirm details against the latest official guidelines.

Design for low bandwidth and low-end phones

Use it when: Many of your users have slow networks or budget devices.

Review [FEATURE/FLOW] for users on slow 3G/4G networks and low-end Android phones with limited storage.

Suggest: offline and poor-connection states, what to cache, skeleton vs spinner loading, image and video strategies, retry and resume behaviour, reducing data usage, and how to communicate what is happening. Prioritise changes by impact.

Gesture and touch interactions

Use it when: You are adding swipes, long-press or drag interactions.

I want to use [GESTURE, e.g. swipe to delete] for [ACTION] in [PRODUCT].

Evaluate discoverability, accidental triggers, accessibility (alternatives for people who can't perform gestures, screen reader support), undo, and platform conventions. Recommend how to design it safely, including a visible alternative control.

Dashboard information plan

Use it when: You are designing a dashboard and need to decide what goes on it.

I am designing a dashboard for [USERS] who need to [DECISIONS THEY MAKE].

Available data: [LIST METRICS]

Help me decide: the 3–5 key questions the dashboard must answer, which metrics answer them, the layout priority (overview → detail), default time range, comparisons (vs last period, vs target), and what belongs in drill-downs instead of the main view.

Choose the right chart

Use it when: You're unsure which chart type fits your data.

I want to show [WHAT, e.g. monthly revenue by region over a year] to [AUDIENCE] so they can [DECISION].

Recommend the best chart type and 1–2 alternatives, explain why, and give design rules: axis labels, number formats (₹ lakhs/crores or millions), colour use, highlighting, and accessibility (not relying on colour alone). Tell me which chart types to avoid for this data.

Data table design

Use it when: You are designing a table with many rows and columns.

Design a data table for [DATA, e.g. 2,000 customer orders] used by [USERS] to [TASKS].

Columns: [LIST]

Cover: column order and alignment (numbers right-aligned), sorting, filtering, search, pagination vs infinite scroll, row actions, bulk actions, sticky columns, density options, empty and loading states, and how it adapts to mobile.

KPI card design

Use it when: You need summary cards that are easy to read at a glance.

Design KPI cards for [METRICS] on a [PRODUCT] dashboard.

For each card specify: label, main value format, comparison (vs previous period or target) with direction and colour meaning, sparkline or not, tooltip content, and how to show missing or delayed data. Make sure meaning doesn't depend only on red/green colour.

Explain data insights in plain language

Use it when: Users see numbers but don't understand what they mean.

Our dashboard shows: [DESCRIBE DATA AND A SAMPLE]

Write short, plain-language insight messages that explain what changed, why it might matter, and a suggested next action. Give 5 examples with templates I can reuse, and rules to avoid over-claiming causation from correlations.

Checkout flow audit

Use it when: Your checkout has high drop-off.

Audit this checkout flow for [PRODUCT] used mostly on mobile in India:
[DESCRIBE EACH STEP, FIELDS, PAYMENT OPTIONS]

Check: guest checkout, number of steps and fields, address entry (pincode auto-fill), delivery information, price transparency (fees and taxes shown early), payment options (UPI, cards, COD, EMI), trust signals, error handling and order confirmation. Give a prioritised list of fixes.

Product detail page structure

Use it when: You are designing or improving a product page.

Plan the product detail page for [PRODUCT TYPE] on [mobile / desktop].

Order the content by what shoppers need to decide: images, price and offers, key benefits, variants (size, colour), delivery date by pincode, returns, reviews, specifications, and FAQs. Say what must be visible before scrolling, where to place the add-to-cart button, and how to handle out-of-stock variants.

Landing page wireframe

Use it when: You need a high-converting landing page structure.

Create a wireframe outline for a landing page for [OFFER] aimed at [AUDIENCE]. The one action we want: [ACTION].

Give each section in order with its purpose, headline idea and content: hero with value proposition and CTA, problem, how it works, proof (only real testimonials or data), features as benefits, pricing or offer, FAQs, final CTA. Keep one clear primary action throughout.

Pricing page design

Use it when: You are presenting plans or packages.

Design a pricing page for [PRODUCT] with these plans: [PLANS, PRICES, FEATURES].

Recommend the layout, which plan to highlight and why, how to present feature differences without a giant table, monthly vs yearly toggle, currency and tax display (₹, GST), FAQs that reduce hesitation, and the call-to-action for each plan. Avoid manipulative patterns.

Conversion optimisation hypotheses

Use it when: You want evidence-based ideas to improve conversion.

Our [PAGE/FLOW] converts at [RATE]. Data we have: [ANALYTICS, HEATMAPS, FEEDBACK].

Generate 8 conversion hypotheses using the format "Because we saw [evidence], we believe [change] will [result] for [users]. We'll measure [metric]." Rate each by expected impact, confidence and effort. Exclude dark patterns and anything that harms user trust.

Trust signals review

Use it when: Users hesitate to sign up or pay.

Review [PAGE/FLOW] for trust. Describe what users see: [DESCRIBE].

Identify moments of doubt (e.g. entering payment details, sharing a phone number) and suggest honest trust signals for each: clear policies, security cues, real reviews, contact options, transparent pricing and data use explanations. Tell me which signals need real evidence before we can use them.

UPI payment flow review

Use it when: You are designing or improving a UPI checkout.

Review this UPI payment flow for [PRODUCT]:
[DESCRIBE STEPS: app selection, intent/collect/QR, waiting screen, success, failure]

Check: default payment app choice, what happens while waiting for approval in the UPI app, timeouts, pending status, failures and retries, avoiding double payments, refund communication, and trust cues. Suggest improvements for each step and the copy for pending and failed states.

Onboarding flow design

Use it when: New users sign up but don't reach the core value.

Design an onboarding flow for [PRODUCT]. The "aha" moment is when users [KEY ACTION/VALUE]. Users: [USERS].

Recommend: what to ask during sign-up (only what's needed), personalisation questions, the fastest path to the aha moment, progressive onboarding vs tours, empty states that teach, and what to postpone. Show the flow step by step and the metric to track activation.

Feature discovery

Use it when: Users don't know an important feature exists.

Users rarely discover [FEATURE] in [PRODUCT]. It helps them [VALUE].

Suggest 6 ways to improve discoverability (e.g. contextual hints, empty states, placement, naming, onboarding checklists, announcements) with pros and cons. Recommend 2 to test first and how to measure success without annoying users.

Retention and habit loop

Use it when: You want users to come back regularly, ethically.

Help me design for healthy retention in [PRODUCT], where the core repeat action is [ACTION].

Map the habit loop (trigger, action, reward, investment), identify why users currently drop off [DATA OR HYPOTHESES], and suggest improvements. Include a check for manipulative patterns and how users can stay in control (notification settings, pausing, easy cancellation).

Re-engagement journey

Use it when: You want to bring back inactive users.

Design a re-engagement journey for users inactive for [PERIOD] in [PRODUCT].

Segment them by likely reason for leaving [REASONS], and for each segment suggest channels (push, email, WhatsApp, in-app), message timing, content, and the in-app experience when they return. Include frequency limits and an easy opt-out.

Permission request design

Use it when: You need users to allow location, notifications or contacts.

Design the permission request for [PERMISSION] in [PRODUCT].

Explain when to ask (in context, not at launch), a pre-permission screen with clear benefit copy, what happens if the user says no, and how they can enable it later. Write the copy for the pre-permission screen and the settings reminder.

Chatbot conversation design

Use it when: You are designing a support or assistant chatbot.

Design the conversation for a chatbot that helps [USERS] to [TASKS] in [PRODUCT].

Include: the greeting and what the bot can and can't do, 3 main conversation flows with sample dialogue, how to ask clarifying questions, handling misunderstood input, a handover to a human, tone of voice, and quick-reply buttons. Show one flow as a script.

AI feature UX patterns

Use it when: You are adding a generative AI feature to a product.

We are adding an AI feature: [FEATURE, e.g. AI-written product descriptions].

Design the experience: how users give input (prompt box, suggestions, structured fields), how results are shown, editing and regenerating, showing sources or confidence, handling wrong or harmful output, loading time expectations, user control and undo, and how we set honest expectations. List risks and mitigations.

Prompt suggestion chips

Use it when: Users don't know what to ask your AI feature.

Our AI assistant helps [USERS] with [DOMAIN]. Write 12 prompt suggestion chips that show the range of what it can do, grouped by user goal. Keep each under 45 characters, specific, and action-oriented. Suggest when to show them (empty state, after an answer) and how to personalise them.

Voice interface flow

Use it when: You are designing a voice-first or voice-assisted feature.

Design a voice interaction for [TASK] in [PRODUCT] used by [USERS], possibly in [LANGUAGES].

Include: wake or start action, how the system confirms it's listening, sample utterances (including regional accents and code-mixed Hinglish), confirmations for important actions, error recovery when speech isn't understood, and a visual/text fallback. Write a sample dialogue.

Responsible AI design review

Use it when: You want to check an AI feature for risks before launch.

Review [AI FEATURE] for responsible design.

Consider: accuracy and hallucination risk, bias across user groups, transparency (do users know it's AI?), privacy and data use, consent, user control and override, accessibility, and failure modes. For each risk rate severity and suggest design mitigations and what to monitor after launch.

Review an AI-generated UI

Use it when: You generated a screen with Figma Make, Stitch or another AI tool and need to judge it critically.

I generated this screen with an AI design tool for [PRODUCT] and [USERS]. Here is a description or screenshot: [ATTACH OR DESCRIBE].

Review it like a senior product designer: does it actually support the user's task [TASK]? Check hierarchy, content realism, consistency with our design system [TOKENS/COMPONENTS], accessibility (contrast, target sizes, labels), states that are missing (empty, error, loading), and patterns that look generic or wrong for our users. List what to keep, what to fix, and what to redesign by hand.

Good practice: AI tools produce plausible-looking screens quickly; your job is to check them against real user needs.

Design AI agent handoffs and approvals

Use it when: Your product uses an AI agent that takes actions for the user.

Our product has an AI agent that can [ACTIONS, e.g. book appointments, send emails, pay bills] for [USERS].

Design the control experience: what the agent can do without asking, what needs approval, how it shows its plan before acting, progress and activity history, undo, how errors are reported, and how users set limits. Give examples of approval screens for a low-risk and a high-risk action.

Compare AI prototyping tools for a project

Use it when: You need to choose between tools like Figma Make, Google Stitch, v0 or Claude Design.

I need an AI tool to [GOAL, e.g. prototype a mobile onboarding flow for usability testing]. Constraints: [TEAM, BUDGET, DESIGN SYSTEM, NEED FOR FIGMA EDITING OR CODE].

Compare [TOOLS] on: output quality for this task, editability, design system support, export options (Figma, code, slides), collaboration, cost, and data/privacy considerations. Recommend one, and tell me what to verify on each vendor's site because features change often.

Design token structure

Use it when: You are setting up variables and tokens.

Help me set up design tokens for [PRODUCT] in Figma variables.

Propose a structure with primitive tokens (raw values) and semantic tokens (e.g. text/primary, surface/raised, border/focus) for colour, spacing, radius and typography, with light and dark modes. Show naming conventions and 10 example tokens with values.

Component documentation

Use it when: You need to document a component for designers and developers.

Write documentation for the [COMPONENT] in our design system.

Include: purpose, when to use and when not to use it, anatomy, variants and states, content guidelines, behaviour, accessibility requirements (keyboard, screen reader, focus), do's and don'ts, and related components. Keep it scannable.

Design system audit

Use it when: Your product has inconsistent UI and you want to consolidate.

I have inventoried the UI in our product:
[LIST COMPONENTS, VARIATIONS, COLOURS, TEXT STYLES FOUND]

Help me audit it: group duplicates and near-duplicates, suggest which to keep, merge or retire, estimate the effort, and propose a prioritised roadmap for building our design system. Suggest how to measure adoption.

Pattern guideline

Use it when: You want a rule for a recurring pattern like confirmation dialogs.

Write a design guideline for the [PATTERN, e.g. destructive action confirmation] pattern.

Cover: the problem it solves, when to use each variation (inline undo vs dialog vs typed confirmation), content rules, accessibility, examples of good and bad usage, and how it should behave on mobile and desktop.

Naming conventions

Use it when: Your team names components and layers differently.

Propose naming conventions for our design system shared by designers and developers.

Cover: component names, variant properties and values, colour and spacing tokens, icons, and Figma pages. Align names with how developers name them in code ([FRAMEWORK, e.g. React]). Give examples and a short list of rules.

Component API for developers

Use it when: You want design components and code components to match.

Define the component API for [COMPONENT] so design and code match.

List: props with types and defaults, variants, slots/children, events, accessibility props, and which Figma properties map to which code props. Flag design options that would be hard to build and suggest simplifications.

Design system release notes

Use it when: You changed components and need to tell the team.

Write release notes for design system version [VERSION]. Changes: [LIST CHANGES].

Group them as new, changed, deprecated and fixed. For breaking changes explain the impact and migration steps for designers and developers. Keep it short and scannable.

Migrate styles to variables and tokens

Use it when: You are moving a Figma file from old styles to variables and modes.

Our Figma library uses [NUMBER] colour styles and [NUMBER] text styles with inconsistent names: [PASTE EXAMPLES].

Plan a migration to Figma variables with primitive and semantic layers and light/dark modes: proposed naming, mapping from old styles to new tokens, how to handle duplicates, the order of migration to avoid breaking files, how to communicate it to the team, and a checklist to verify nothing broke.

Write a DESIGN.md for AI tools

Use it when: You want AI design and coding tools to follow your design system consistently.

Write a DESIGN.md file for [PRODUCT] that AI design and coding tools can read as context.

Include: brand personality in 3 words, colour tokens with usage rules, typography scale, spacing and radius scales, core components and when to use each, layout rules for mobile and desktop, accessibility requirements, tone of voice for UI copy, and a short list of things to never do. Our current system: [PASTE TOKENS, COMPONENTS, GUIDELINES]. Keep it under 600 words and use clear headings.

Accessibility review of a screen

Use it when: You want to catch accessibility issues early.

Review this screen for accessibility against WCAG 2.2 AA:
[DESCRIBE OR ATTACH SCREEN, INCLUDING COLOURS, TEXT SIZES, INTERACTIONS]

Check: colour contrast, text size and resizing, touch target size, focus order and visible focus, labels and instructions, error identification, use of colour alone, motion, and screen reader announcements. For each issue give the WCAG success criterion, the impact on users and a fix.

Good practice: AI can miss issues. Confirm with automated checkers, keyboard testing and a screen reader.

Alt text writer

Use it when: You need meaningful alternative text for images.

Write alt text for these images on [PAGE]:
[DESCRIBE EACH IMAGE AND ITS PURPOSE ON THE PAGE]

For each: decide whether it is decorative (empty alt), informative or functional, and write concise alt text (under 125 characters) that conveys the purpose, not just the appearance.

Keyboard and screen reader spec

Use it when: You are handing off an interactive component.

Write an accessibility specification for [COMPONENT, e.g. a date picker / tabs / modal].

Include: keyboard interactions (Tab, arrows, Enter, Space, Esc), focus management, ARIA roles, states and properties, what a screen reader should announce, and how to test it. Follow the WAI-ARIA Authoring Practices pattern where one exists.

Inclusive design review

Use it when: You want to design for a wider range of people.

Review [FEATURE] for inclusive design. Consider people with low vision, colour blindness, motor impairments, cognitive and learning differences, low literacy, older users, slow internet, low-end phones and users who speak [LANGUAGES].

For each group, describe likely barriers and practical design changes. Prioritise changes that help many groups at once.

Accessible colour and status design

Use it when: Your UI relies on colour to show status.

Our UI uses colour to show [STATUSES, e.g. success, warning, error, pending].

Redesign the status system so it works for colour-blind users and in grayscale: add icons, text labels, patterns or shapes. Suggest colour values with WCAG AA contrast against [BACKGROUND] and tell me which pairs I must verify with a contrast checker.

Accessibility test with disabled users

Use it when: You want to include people with disabilities in research.

Plan a usability study with participants who use assistive technology (screen readers, magnification, switch access, voice control) for [PRODUCT].

Include recruitment channels, respectful screener questions, accessible consent and session setup (remote tools that work with assistive tech), task design, fair compensation, and how to analyse findings. Keep the language person-first and respectful.

Accessibility acceptance criteria

Use it when: You want accessibility built in from the start, not fixed at the end.

Write accessibility acceptance criteria for [FEATURE/COMPONENT] based on WCAG 2.2 AA.

Group them as: keyboard, focus, screen reader, colour and contrast, text resizing and reflow, motion, forms and errors, and touch targets. Write each as a testable statement developers and QA can check, and mark which need manual testing.

Good practice: Confirm details against the official WCAG 2.2 Understanding documents.

Usability test plan

Use it when: You are about to test a prototype or live product.

Write a usability test plan for [PRODUCT/PROTOTYPE].

Goals: [WHAT WE WANT TO LEARN]
Participants: [WHO, HOW MANY]
Format: [moderated / unmoderated, remote / in person]

Include: objectives, participant criteria, 5–6 realistic task scenarios, success criteria for each task, metrics (success rate, time, errors, confidence), a session script, and a post-test questionnaire.

Realistic task scenarios

Use it when: Your test tasks give away the answer.

Write usability test tasks for [PRODUCT] based on these user goals:
[GOALS]

Each task should give context and motivation, avoid words that appear on the interface, have a clear end point, and not reveal the path. Also give me the success criteria for each task and one follow-up question to ask.

Moderator script

Use it when: You are running a moderated test for the first time.

Write a moderator script for a [LENGTH]-minute usability test.

Include: introduction and consent, the think-aloud explanation, a warm-up question, how to introduce each task, neutral prompts to use when the participant is silent or stuck (without helping them), how to answer their questions without leading, and a closing with debrief questions.

Analyse usability findings

Use it when: You have test notes and need to prioritise issues.

Here are anonymised notes from [NUMBER] usability sessions:
[PASTE NOTES]

List the usability issues found. For each give: description, number of participants affected, severity (critical, major, minor) with reasoning, evidence (quotes or behaviour), and a recommended fix. Sort by severity, then frequency. Only include issues supported by the notes.

A/B test hypothesis

Use it when: You want to test a design change with live traffic.

Help me design an A/B test for [CHANGE] on [PAGE/SCREEN].

Write: the hypothesis ("If we…, then…, because…"), primary metric, guardrail metrics, the variants, the audience, how long to run it and what sample size to aim for, and what result would make us keep, change or drop the idea. Remind me of common mistakes like stopping tests early.

Post-test questionnaire

Use it when: You want to measure perceived usability after a test.

Create a short post-test questionnaire for [PRODUCT].

Include the standard System Usability Scale (SUS) questions and explain how to score it, plus 3 open questions about what was easy, confusing and missing. Keep the wording exactly as the standard SUS where it applies.

Unmoderated test instructions

Use it when: You are running a remote test without a moderator.

Write instructions for an unmoderated usability test of [PROTOTYPE/PRODUCT].

Include: a welcome message, think-aloud instructions participants will understand, 4–5 self-explanatory tasks with clear end points, questions after each task (ease rating and why), and closing questions. Anticipate where participants could get stuck without a moderator and make the instructions resistant to that.

First-click and five-second tests

Use it when: You want quick feedback on a layout or landing page.

Plan a first-click test and a five-second test for [SCREEN].

For the first-click test write 5 tasks with the correct target areas. For the five-second test write 4 recall questions (what is this page for, what stood out, what would you do next, who is it for). Explain how to interpret results and the number of participants needed.

Usability findings presentation

Use it when: You need stakeholders to act on test results.

Turn these usability findings into a short presentation for [AUDIENCE]:
[PASTE FINDINGS]

Structure: what we tested and with whom, top 3 issues with video clip or quote suggestions, severity and business impact, recommended fixes with effort, what worked well, and next steps. Keep it to 8 slides with a one-line headline per slide.

Accessibility-focused test tasks

Use it when: You want to check a flow with keyboard and screen reader users.

Write usability tasks to test [FLOW] with participants who use [screen readers / keyboard only / screen magnification].

For each task give the scenario, success criteria, what to observe (focus order, announcements, error recovery), and follow-up questions. Add setup notes for running the session remotely with their own assistive technology.

Heuristic evaluation

Use it when: You want an expert-style review of a product.

Do a heuristic evaluation of [PRODUCT/FLOW] using Nielsen's 10 usability heuristics. Here is what the flow looks like:
[DESCRIBE STEPS OR ATTACH SCREENSHOTS]

For each issue give: the heuristic violated, where it happens, severity (0–4) with a reason, and a recommendation. Also list what the design does well. Only comment on what you can see or what I described.

Good practice: AI reviews are a starting point. Combine them with your own review and real user testing.

Cognitive walkthrough

Use it when: You want to check how learnable a task is for new users.

Do a cognitive walkthrough of [TASK] in [PRODUCT] for a first-time user who [USER CONTEXT].

Steps:
[LIST EACH STEP AND WHAT THE USER SEES]

For each step answer: Will the user try to achieve the right result? Will they notice the correct action is available? Will they connect the action with their goal? Will they see progress after the action? Note failure points and fixes.

Structured design critique

Use it when: You want to give or receive feedback on a design.

Help me run a design critique of [DESIGN] with my team.

The design's goal: [GOAL]. The stage: [early concept / detailed design].

Give me a 30-minute agenda, ground rules, 8 critique questions tied to the goal (not personal taste), and a template to capture feedback as: observation → impact on user → suggestion.

Devil's advocate for my design

Use it when: You want to stress-test a design before presenting it.

Here is my design decision and rationale:
[DECISION AND REASONING]

Act as a sceptical product manager, then a sceptical engineer, then a sceptical user. Each should raise their 3 strongest objections. Then help me prepare a short, evidence-based response to each objection, and tell me which objections should make me change the design.

Dark pattern check

Use it when: You want to make sure a design is ethical and trustworthy.

Review [FLOW, e.g. subscription cancellation / checkout / cookie consent] for dark patterns and manipulative design:
[DESCRIBE THE FLOW]

Check for: confirmshaming, hidden costs, forced continuity, pre-selected options, misdirection, nagging, and making it harder to leave than to join. For each problem explain the harm and suggest an honest alternative that still supports the business goal.

Design QA checklist

Use it when: You are reviewing the built product against the design.

Create a design QA checklist for reviewing [FEATURE] in [staging / the live build] against the Figma design.

Cover: layout and spacing, typography, colours and tokens, component states, responsive behaviour, content and truncation, interactions and animations, accessibility (keyboard, focus, screen reader, contrast), error and empty states, and performance feel. Add a severity scale for issues.

Clear UI bug report

Use it when: You found a visual or UX bug and need developers to fix it quickly.

Write a clear bug report for this issue: [DESCRIBE WHAT YOU SAW].

Use the structure: title, environment (device, OS, browser, app version), steps to reproduce, expected result (with Figma link placeholder), actual result, screenshot/video note, severity, and suggested fix. Keep it short and factual.

Annotate a design for handoff

Use it when: Developers keep asking the same questions about your designs.

Help me write annotations for [SCREEN] before handoff.

For each area of the screen list what developers need to know: behaviour on interaction, dynamic content rules (min/max lengths, truncation), conditions for showing or hiding elements, validation rules, analytics events, accessibility notes (focus order, labels) and links to components. Format them as numbered notes.

Content and edge-case matrix

Use it when: You want to test designs with real-world content before development.

Create an edge-case matrix for [COMPONENT/SCREEN].

Include rows for: very long and very short text, missing data, large numbers (₹10,00,00,000), many items vs one vs zero, different languages (Hindi, Telugu), right-to-left if relevant, slow loading, error states and permission levels. For each, describe the expected design behaviour.

Review an interactive code prototype

Use it when: You built a prototype with code layers, v0 or another code-based tool and want to check it before sharing.

I made an interactive code prototype of [FEATURE]. Here is what it does: [DESCRIBE OR PASTE].

Review it like a design lead: does it match the intended flow and states, are interactions and focus behaviour accessible, are content and edge cases realistic, does it follow our design system [TOKENS/COMPONENTS], and what would mislead stakeholders into thinking it's production-ready? Give a prioritised fix list.

Good practice: A coded prototype is still a prototype. Label it clearly when you share it.

Prioritise features

Use it when: You have too many ideas and limited time.

Help me prioritise these features for [PRODUCT]:
[LIST FEATURES]

Our goal this quarter: [GOAL]. Constraints: [TEAM SIZE, TIME].

Score each feature using RICE (reach, impact, confidence, effort) and explain the scores. Then show the ranked list and challenge any feature where my confidence is low because we lack evidence.

UX success metrics

Use it when: You need to show whether a design change worked.

Define UX success metrics for [FEATURE] in [PRODUCT].

Use the HEART framework (happiness, engagement, adoption, retention, task success). For each relevant category, give a goal, a signal and a specific metric we can track. Tell me which 2–3 metrics matter most for this feature and what data we need to collect.

Write user stories and acceptance criteria

Use it when: You are handing a feature over to developers.

Write user stories for [FEATURE] for [USERS].

Use the format "As a [user], I want [action], so that [benefit]." For each story add acceptance criteria in Given/When/Then format, including error states and edge cases. Keep stories small enough to build in one sprint.

Developer handoff notes

Use it when: You want developers to build the design exactly as intended.

Write developer handoff notes for [SCREEN/FEATURE].

Include: purpose and user flow, components used (with names from our design system), responsive behaviour at [BREAKPOINTS], all states and interactions, content rules (truncation, long text, localisation), accessibility requirements, analytics events to track, and open questions. Format it as a checklist.

Explain design ROI to leadership

Use it when: You need buy-in for design or research investment.

Help me make the case to [AUDIENCE, e.g. founders / leadership] for investing in [INITIATIVE, e.g. usability testing before launch].

Our situation: [CONTEXT, DATA, PROBLEMS]

Write a short business case: the problem in business terms, the cost of doing nothing, the proposal, expected benefits, effort and cost, risks, and how we will measure success. Use only numbers I provide; mark estimates clearly.

Workshop agenda

Use it when: You are running a design thinking or ideation workshop.

Design a [LENGTH] workshop for [PARTICIPANTS] to [GOAL, e.g. generate ideas for improving onboarding].

Include: objectives, agenda with timings, activities (for example Crazy 8s, dot voting, how-might-we), materials needed (for in-person and online in FigJam/Miro), facilitator notes, and how to capture outcomes and next steps.

Design rationale document

Use it when: You need to record why a design decision was made.

Write a one-page design rationale for [DECISION] in [PRODUCT].

Include: the problem, options considered with pros and cons, evidence used (research, data, standards), the decision and why, trade-offs accepted, risks, and how we will measure whether it worked. Keep it neutral and easy to revisit later.

Stakeholder design review presentation

Use it when: You are presenting designs to stakeholders for approval.

Help me prepare a [LENGTH]-minute design review for [STAKEHOLDERS].

Design: [DESCRIBE]. Goal of the meeting: [e.g. approval to build, feedback on direction].

Give me an agenda, how to frame the problem and goals before showing screens, the story to walk through, the specific feedback to ask for, likely objections with evidence-based responses, and how to close with clear decisions and owners.

Resolve design disagreement

Use it when: You and a stakeholder disagree on a design direction.

I disagree with [STAKEHOLDER ROLE] about [DECISION]. Their view: [VIEW]. My view: [VIEW]. Evidence we have: [EVIDENCE].

Help me understand their underlying goals, find common ground, and propose a fair way to decide (e.g. a quick test, a metric, a reversible experiment). Draft a short, respectful message suggesting that approach.

Write a design critique summary for the team

Use it when: You ran a critique and need to share decisions.

Here are my notes from a design critique of [DESIGN]:
[PASTE NOTES]

Summarise them for the team: decisions made, feedback we agreed to act on (with owners), feedback we decided not to act on and why, open questions, and next review date. Keep it short and neutral.

Case study outline

Use it when: You are turning a project into a portfolio case study.

Help me outline a UX/UI case study for my portfolio.

Project: [PROJECT]
My role: [ROLE AND TEAM]
Timeline: [DURATION]
What I did: [RESEARCH, DESIGN, TESTING STEPS]
Outcome: [RESULTS, EVEN IF QUALITATIVE]

Create a structure with: hook, context and problem, my role, process highlights (only the decisions that matter), key design decisions with reasoning, final design, results and learnings. Suggest which visuals to show in each section. Keep it scannable for a recruiter with 2 minutes.

Tighten my case study

Use it when: Your case study is too long or reads like a process diary.

Here is my case study text:
[PASTE]

Edit it like a hiring manager would want: cut process steps that don't lead to a decision, make my individual contribution clear ("I" vs "we"), strengthen the problem statement, add the reasoning behind decisions, and end with outcomes and learnings. Keep my voice and don't invent results or numbers.

Portfolio project idea

Use it when: You need a realistic self-initiated project.

Suggest 5 realistic UX/UI portfolio project ideas for someone targeting [ROLE/INDUSTRY, e.g. fintech product design in India].

For each give: the user problem, target users, why it shows relevant skills, the research I can realistically do alone, and the key screens to design. Avoid overused ideas like generic food-delivery or weather app redesigns unless you give a fresh angle.

Portfolio review

Use it when: You want feedback before applying for jobs.

Review my UX/UI portfolio as a hiring manager for a [LEVEL] product designer role at [COMPANY TYPE].

Here is the text and structure of my portfolio:
[PASTE HOME PAGE AND CASE STUDY SUMMARIES]

Tell me: my first impression in 30 seconds, whether my positioning is clear, the strongest and weakest case study and why, gaps in skills shown, and the top 5 improvements in priority order.

About-me and positioning statement

Use it when: You need a clear intro for your portfolio and LinkedIn.

Write 3 versions of a short portfolio intro (max 40 words) and a LinkedIn headline (max 220 characters) for me.

About me: [BACKGROUND, SKILLS, TYPES OF PROJECTS, WHAT I WANT NEXT]

Make it specific and human, not buzzword-heavy. Each version should have a different emphasis: problem-solving, domain expertise, and career-switcher story.

Add an AI-assisted process honestly to a case study

Use it when: You used AI tools in a project and want to describe it credibly.

In my project [PROJECT], I used AI for [TASKS, e.g. synthesis drafts, copy options, early wireframes].

Help me write a short case-study section that explains where AI helped, what I did myself, how I verified the output, and what I would do differently. Keep it honest and specific so hiring managers trust my skills.

Present a case study in an interview

Use it when: You need to present your work in 10–15 minutes.

Help me turn my case study into a [LENGTH]-minute interview presentation.

Case study: [PASTE OR SUMMARISE]

Give me a slide-by-slide outline with timings, the story arc, what to say on each slide, the 2 decisions to go deep on, and 6 questions the panel is likely to ask with strong answer outlines.

Mock design interview

Use it when: You want to practise interview questions.

Run a mock interview for a [LEVEL] UX/UI designer role at a [COMPANY TYPE].

Ask me one question at a time: 2 about my background, 3 about a case study, 2 behavioural (collaboration, conflict), and 1 about design process. After each answer, give feedback on structure, clarity and evidence, and a better example answer outline. Wait for my answer before asking the next question.

Whiteboard design challenge practice

Use it when: You are preparing for a live design exercise.

Give me a realistic 45-minute whiteboard design challenge for a [LEVEL] product designer, in the domain [DOMAIN].

Act as the interviewer: share only the brief first and answer my clarifying questions briefly. When I say "DONE", evaluate my approach on: clarifying the problem, users and constraints, prioritisation, idea exploration, solution quality, and communication. Suggest what a strong candidate would have done differently.

"Tell me about yourself" answer

Use it when: You need a strong, short opening answer for design interviews.

Help me write a 60–90 second answer to "Tell me about yourself" for a [LEVEL] [ROLE] interview at [COMPANY TYPE].

My background: [EDUCATION, EXPERIENCE, KEY PROJECTS, WHAT I'M LOOKING FOR].

Structure: who I am as a designer, 1–2 proof points, what I'm great at, and why this role. Make it sound natural when spoken, not memorised. Give me 2 versions: one for a startup and one for a large company.

Common UX interview questions practice

Use it when: You want to prepare answers for the questions most interviews include.

List the 15 most common questions in [LEVEL] UX/UI designer interviews, grouped as: process, collaboration, research, visual design, portfolio and motivation.

For each question give what the interviewer is really checking, a strong answer structure, and one mistake to avoid. Then ask me 5 of them one at a time and give feedback on my answers.

Behavioural answers with STAR

Use it when: You need clear stories for behavioural questions.

Help me prepare STAR (Situation, Task, Action, Result) stories for these behavioural questions:
- A time you disagreed with a stakeholder or developer
- A project that failed or changed direction
- A time you worked with unclear requirements
- A time you used research to change a decision
- Handling tight deadlines

My raw experiences: [DESCRIBE 3–5 SITUATIONS]

Match each question to the best experience, write the STAR answer (under 2 minutes spoken), and highlight what shows my design maturity. Don't invent details or results.

Portfolio walkthrough rehearsal

Use it when: You will present a case study live and want to practise.

Act as a hiring panel of a design manager, a product manager and an engineer. I will present my case study: [PROJECT SUMMARY].

After I share my walkthrough, ask me 3 tough questions from each panelist's perspective (e.g. "What would you do differently?", "How did you measure success?", "How did engineering constraints change the design?"). Then score my answers on clarity, ownership, reasoning and impact, with tips to improve.

App critique exercise

Use it when: Interviewers often ask you to critique an app on the spot.

Give me a live app critique exercise. Choose a widely used app category (e.g. food delivery, banking, travel) and a specific flow.

First ask me to critique it in 10 minutes. When I answer, evaluate whether I: considered the user and context, identified the business goal, structured my critique (heuristics, hierarchy, flows), prioritised issues, and proposed realistic improvements. Then show a model answer outline.

Product sense question

Use it when: You are interviewing for product design roles that test product thinking.

Ask me a product design question such as "Design [PRODUCT] for [USER GROUP]" or "How would you improve [FEATURE] of [APP]?".

Let me answer in steps. Evaluate how I: clarify the goal and constraints, choose a user segment, identify pain points, prioritise, propose solutions, define success metrics and consider trade-offs. Give a score out of 10 for each area and a model answer framework.

Take-home assignment plan

Use it when: You received a design assignment with a deadline.

I received this take-home design assignment:
[PASTE BRIEF]. Time available: [HOURS/DAYS].

Help me plan it: clarifying questions to ask the recruiter, assumptions to state, how to split my time, what research is realistic, what to design in depth vs sketch, how to present the process concisely, and what reviewers usually look for. Warn me if the assignment scope looks like unpaid real work.

Research-focused interview questions

Use it when: The role involves UX research and you need to show research depth.

Prepare me for research questions in a [ROLE] interview:
- How do you choose a research method?
- How do you avoid bias?
- How do you convince stakeholders to act on findings?
- Tell me about research with limited time or budget
- How do you measure UX?

For each give an answer framework and ask me to answer with my own example: [MY RESEARCH EXPERIENCE]. Then give feedback.

Design system interview questions

Use it when: You are interviewing for a role that works on a design system.

Prepare me for a design systems interview. Ask me 8 questions one at a time about: building vs adopting a system, tokens and theming, component governance, contribution models, versioning, accessibility, measuring adoption, and working with engineering. After each answer, give feedback and a stronger answer outline based on my experience: [MY EXPERIENCE].

Questions to ask the interviewer

Use it when: You want smart questions that also help you judge the company.

Suggest 12 thoughtful questions I can ask at the end of a [ROLE] interview at [COMPANY TYPE], grouped by: design culture and process, team and mentorship, product and users, and growth. Mark the 4 best for a first-round interview and explain what a good or worrying answer sounds like for each.

Weakness and gaps answers

Use it when: You get asked about weaknesses, gaps or a career break.

Help me answer these honestly and confidently:
1. "What is your biggest weakness?"
2. "Why is there a gap in your resume?" [REASON]
3. "You don't have [SKILL/EXPERIENCE] — why should we hire you?"

My situation: [DETAILS]. For each, give a short answer structure and a sample answer that shows self-awareness and what I'm doing to improve. Avoid clichés like "I'm a perfectionist".

Company and product research before an interview

Use it when: You want to show you understand the company's product and users.

I have an interview at [COMPANY] for [ROLE]. Based on what I have gathered from their website, app and public information: [PASTE NOTES].

Help me prepare: the likely target users and their needs, the business model, 3 UX strengths and 3 opportunities I noticed (framed respectfully), how my experience connects to their product, and 3 informed questions to ask. Label anything you're unsure about as a hypothesis.

Post-interview follow-up and reflection

Use it when: You finished an interview and want to follow up and improve.

I just finished a [ROUND] interview for [ROLE] at [COMPANY]. What happened: [SUMMARY OF QUESTIONS AND MY ANSWERS].

1. Write a short, genuine thank-you email (under 120 words) that references one specific topic we discussed.
2. Reflect with me: which answers were strong, which were weak, and how to improve them for the next round.

"How do you use AI in your design work?"

Use it when: Interviewers now often ask how you use AI tools.

Help me answer "How do you use AI in your design process?" for a [LEVEL] [ROLE] interview.

My actual usage: [TOOLS AND HOW I USE THEM].

Structure an answer (under 90 seconds) that shows practical examples, where AI saves time, where I don't trust it (research, accessibility, final decisions), and how I check its output. Also prepare answers to follow-ups like "Won't AI replace designers?" and "Show me an example".

Explain a design decision under pressure

Use it when: You get asked "Why did you design it this way?" and freeze.

Practise defending design decisions with me. My case study: [SUMMARY].

Ask me 6 "why" questions about specific decisions (layout, flow order, a feature I cut, a colour or pattern choice). After each answer, rate it on evidence, user focus and clarity, and show a stronger version using the structure: goal → options considered → evidence → trade-off → result.

Senior or lead designer interview prep

Use it when: You are interviewing for a senior, lead or manager role.

Prepare me for a [SENIOR / LEAD / MANAGER] product designer interview at [COMPANY TYPE].

Ask me questions one at a time about: influencing without authority, raising design quality across a team, mentoring, prioritising design debt, working with product and engineering leadership, hiring, and measuring design impact. After each answer, give feedback on seniority signals and a stronger answer outline using my experience: [EXPERIENCE].

"Tell me about a project that failed"

Use it when: Interviewers want to see how you learn from mistakes.

Help me answer "Tell me about a project or design that didn't work out" for a [ROLE] interview.

What happened: [DESCRIBE THE PROJECT, WHAT WENT WRONG, YOUR ROLE].

Structure a 2-minute answer: context, what I decided and why, what went wrong (owning my part without blaming others), what I learned, and what I now do differently, with a concrete example. Then ask me 2 follow-up questions an interviewer might ask.

Portfolio review call preparation

Use it when: A recruiter or design lead has asked for a quick portfolio call.

I have a [LENGTH]-minute portfolio call with [WHO, e.g. a design lead at a fintech startup] for a [ROLE] role.

My case studies: [LIST WITH ONE-LINE SUMMARIES].

Help me choose which case study to lead with for this company and why, plan a 5-minute walkthrough with timings, list 5 likely questions with answer outlines, and prepare 3 questions to ask them. Remind me what to check technically before the call (links, screen share, access).

Resume bullet rewrite

Use it when: Your resume lists tasks instead of impact.

Rewrite these resume bullets for a UX/UI designer role:
[PASTE BULLETS]

Use the format: action verb + what I did + how + outcome. Keep each under 2 lines, remove buzzwords, and make my contribution clear. Do not invent numbers; where a metric would help, add a placeholder like [X%] and tell me what to measure.

Tailor my application to a job

Use it when: You want to match your resume and message to a job description.

Here is a job description:
[PASTE JD]

Here is my resume summary:
[PASTE]

Tell me: the 5 skills they care about most, which of my experiences match, gaps I should address honestly, keywords to include, and which case study to put first. Then write a short, specific message (under 120 words) to the recruiter or hiring manager.

Career switch roadmap

Use it when: You are moving into UX/UI from another field.

I am switching to UX/UI design from [CURRENT FIELD] with [YEARS] years of experience.

Identify my transferable skills, the skills I need to build, how to use my domain knowledge as an advantage, which roles or industries to target first, and a 3-month action plan. Be realistic about timelines and the job market; don't promise guaranteed jobs.

Salary and offer preparation

Use it when: You have an offer or are preparing to negotiate.

Help me prepare to discuss compensation for a [ROLE] offer in [CITY].

My experience: [EXPERIENCE]. The offer: [DETAILS].

Tell me what information I should research and where (for example peers, public salary platforms, recruiters), how to structure the conversation, what to say if asked for my expected salary, and how to negotiate non-salary benefits. Don't state specific salary figures as facts; tell me how to verify current ranges.

LinkedIn profile for designers

Use it when: You want recruiters to find and understand your profile.

Improve my LinkedIn profile for [TARGET ROLE] roles in [LOCATION].

Current headline: [HEADLINE]
About section: [PASTE]
Experience: [PASTE]

Rewrite the headline (max 220 characters), About section (under 250 words), and 3 experience bullets per role. Suggest relevant skills keywords, which case studies to feature, and a posting plan for 4 weeks. Don't invent achievements.

Project proposal

Use it when: A client has asked for a quote.

Write a project proposal for [CLIENT] who needs [PROJECT, e.g. a redesign of their booking app].

Include: understanding of their problem, goals, scope (in and out of scope), process and deliverables, timeline with milestones, assumptions, what I need from them, pricing structure [FIXED / PHASED / HOURLY, AMOUNTS], payment terms and next steps. Keep it clear and professional, under 2 pages.

Client discovery questions

Use it when: You are meeting a new client for the first time.

Write a discovery call guide for a new client who wants [PROJECT].

Include questions about: business goals, users, current problems, competitors, success metrics, budget, timeline, decision-makers, brand and content, and technical constraints. Mark the must-ask questions and add red flags to watch for.

Handle scope creep politely

Use it when: A client keeps asking for extra work.

My client has asked for [NEW REQUEST], which is outside our agreed scope: [ORIGINAL SCOPE].

Write a polite, firm message that acknowledges the request, explains it is outside the current scope, and offers options (add it as a change request with cost and time, swap it for something else, or schedule it for phase 2). Keep the relationship positive.

Present design decisions to a client

Use it when: A client has subjective feedback like "make it pop".

My client said: "[CLIENT FEEDBACK]" about [DESIGN].

Help me understand the real concern behind it, write 3 clarifying questions to ask, and draft a response that connects my design decisions to their users and business goals. Suggest options I can show that address their concern without weakening usability.