The UX Toolkit + AI Prompt Library

Synthesise raw interview notes into themes

Use when: After a batch of interviews, before you start writing a report

I'm going to paste raw notes from [number] user interviews about [topic/product]. Read all of them, then:

1. Identify the 4-6 themes that come up across multiple participants -- not one-off comments.
2. For each theme, name it in plain language (not jargon), write one sentence describing it, and list which participants mentioned it (by the label I've given them, e.g. "P1", "P3").
3. Flag anything that only one person said but that seems important or surprising -- don't discard it, just mark it as a single data point rather than a pattern.
4. Do not invent, generalise, or soften anything I have not actually said in the notes. If two participants contradict each other, tell me -- don't pick a side or average them out.

Here are the notes:
[paste your raw interview notes here]

Turn a rough problem statement into a research plan

Use when: Early discovery, when you have a hunch but no structure yet

Here is a rough problem statement: [describe the problem in a sentence or two, e.g. "Users are abandoning the sign-up flow at the payment step and we don't know why"].

Turn this into a one-page research plan with:
1. Three specific research questions this study should answer -- not restatements of the problem, but things a real conversation or test could actually surface.
2. The method that best fits (moderated interview, unmoderated usability test, survey, or analytics review) and one sentence on why.
3. Who to recruit -- be specific about the type of person and how many, not just "users".
4. One risk or blind spot in this plan I should be aware of before I run it.

Do not assume you already know the answer to the problem -- this is a plan for research I have not done yet.

Generate a first-pass user flow / wireframe brief

Use when: Before opening Figma, to think through the flow in words first

I need to design a flow for: [describe the task, e.g. "a user resetting their password after 3 failed login attempts"].

Context: [describe the platform (web/mobile), the user type, and any constraint that matters, e.g. "mobile app, non-technical users, must work without a registered phone number"].

Write this as a numbered list of screens/steps, where each step includes:
- What the user sees or is asked to do
- The one primary action available on that step
- What happens on error or if they can't complete the step (don't skip the unhappy path)

Keep it to steps and content, not visual design -- I'm using this as a brief for wireframing, not a finished design. Flag any step where you're making an assumption about the business rules rather than working from something I told you.

Run a heuristic evaluation against Nielsen's 10 heuristics

Use when: Reviewing an existing screen or flow, live or asynchronously

I'm going to describe a screen or flow. Evaluate it against Jakob Nielsen's 10 usability heuristics (visibility of system status, match between system and the real world, user control and freedom, consistency and standards, error prevention, recognition rather than recall, flexibility and efficiency of use, aesthetic and minimalist design, help users recognise/diagnose/recover from errors, help and documentation).

For each heuristic: state whether the screen violates it, and if so, describe the specific violation (not a generic definition of the heuristic) and rate severity as Low/Medium/High based on how much it would actually block or frustrate a user completing their task. Skip heuristics that clearly don't apply rather than forcing a finding.

End with a prioritised list of the 3 issues to fix first, ranked by severity, not by how easy they'd be to fix.

Here is the screen/flow:
[describe or paste a description of the screen, its content, and the actions available on it]

Draft interview questions for a given research goal

Use when: Preparing a discussion guide before recruiting starts

My research goal is: [state the goal, e.g. "understand why experienced users skip the onboarding tutorial"].

Draft 6-8 interview questions that would help answer this, following these rules:
- Open questions only, no yes/no questions
- No leading questions (nothing that implies the "right" answer, e.g. avoid "don't you find it annoying when...")
- Ask about past behaviour and specific past instances, not hypothetical future behaviour ("tell me about the last time..." not "would you ever...")
- Order them from broad/warm-up to specific
- End with one catch-all question that gives the participant a chance to raise something I haven't asked about

For each question, add a one-line note on what it's actually trying to surface, so I can adapt on the fly if the conversation naturally answers it a different way.

Summarise a set of user quotes into an actionable insight

Use when: Turning raw quotes into something you can put in front of stakeholders

Here are direct quotes from [number] different users, all responding to the same question or task: [describe the question/task].

[paste the quotes, one per line, labelled by participant]

Write:
1. One sentence describing the pattern across these quotes (the "what")
2. One sentence on why this is likely happening, based only on what's in the quotes -- don't speculate beyond them
3. One sentence on what this means for the design or the business (the "so what")
4. The single strongest verbatim quote to use alongside this insight in a report, and why you picked that one over the others

If the quotes don't actually agree with each other, say so explicitly instead of forcing a single pattern.

Draft a persona from raw research notes

Use when: After several interviews, before a workshop or design kickoff

Here are notes from [number] interviews with people who share [describe the shared trait/segment, e.g. "line managers who approve expense claims"].

[paste your raw notes]

Draft one persona from this data using exactly these four fields, nothing else:
- Goals: 2-3 things this person is trying to accomplish, in their own language
- Frustrations: specific, observed pain points tied to a moment, not vague feelings
- Behaviours: what they actually do today, including workarounds
- Quote: one real, unedited line pulled directly from the notes above (if nothing fits, say so rather than inventing one)

Do not add demographics, hobbies, or a name/photo suggestion -- I'll add those separately. Do not invent any detail that isn't traceable back to the notes I gave you.

Write a customer journey map from raw notes

Use when: Turning interview or diary-study notes into a shareable map

Here are raw notes describing how someone goes through [describe the process, e.g. "returning a faulty product bought online"]:

[paste your notes]

Structure this as a journey map with 4-6 stages. For each stage, give me:
- Stage name (short, from the user's perspective)
- Actions: what they actually do
- Thoughts: what's going through their head, as a short first-person line where possible
- Emotion: one word, plus a rough high/neutral/low rating
- Opportunity: one specific, concrete design or process idea to address the lowest point in that stage -- skip this field for stages with no real friction rather than inventing an opportunity

Only use what's actually in the notes I gave you. If a stage is missing information for one of these fields, write "not covered in notes" rather than guessing.

Stress-test a design decision (devil's advocate)

Use when: Before you commit to a direction, to pressure-test it

I'm planning to design [describe the decision, e.g. "a single long form instead of a multi-step wizard for onboarding"] because [your reasoning].

Argue the opposite case as convincingly as you can. Specifically:
1. What's the strongest reason this could be the wrong call for my actual users (not users in general)?
2. What edge case, user type, or context am I most likely to be ignoring?
3. What would have to be true about my users for my original reasoning to hold up? Is that something I actually know, or something I'm assuming?

Don't soften this or hedge back toward agreeing with me -- I want the strongest honest counter-argument so I can either defend the decision or change it.

Turn technical requirements into user stories with acceptance criteria

Use when: Bridging a PM/engineering spec into something a design or research team can act on

Here is a technical requirement or spec: [paste the requirement, e.g. "the system must support bulk CSV upload of up to 500 rows with row-level error reporting"].

Rewrite this as 2-4 user stories in the format "As a [type of user], I want to [do something], so that [reason]", written from the perspective of the actual person who would use this, not the system. For each story, write 2-3 acceptance criteria phrased as observable outcomes ("the user sees X when Y happens"), not implementation detail.

Flag anywhere the original requirement doesn't actually tell you who the user is or why they want this -- don't invent a motivation that isn't implied by the spec.

Draft a usability test script from a set of tasks

Use when: Turning a task list into something you can actually read out in a session

I want to run a usability test with these tasks: [list your tasks in plain language, e.g. "1) find and book a return slot for an item, 2) check the status of a return already in progress"].

Write a full test script with:
1. A spoken intro (under 90 seconds read aloud) that sets expectations, explains think-aloud, and gets consent to record
2. Each task rewritten as a realistic scenario a participant would be given verbally, without naming any UI element or button (don't tell them what to click)
3. Two post-task questions to ask immediately after each task
4. A short wrap-up with 2 closing questions and a thank-you

Keep the whole thing conversational -- this needs to be read aloud by a first-time moderator, not presented as a bullet list.

Prioritise a list of usability findings

Use when: After a round of testing, before writing recommendations

Here is a list of usability issues found during testing, in no particular order:

[paste your list of findings, one per line]

For each finding, estimate:
- Severity: how much it would block or frustrate a user completing their task (Low/Medium/High)
- Frequency: how many of the participants hit this issue, if I've told you, or "unknown" if I haven't
- Confidence: how sure we can be this is a real pattern versus a one-off, based only on what I've given you

Then rank the full list from highest to lowest priority to fix, using severity and frequency together (not effort to fix -- I haven't given you that). Explain your ranking logic in one sentence so I can sanity-check it against my own judgement.

Translate a UX finding into a business case for stakeholders

Use when: Pitching a fix to people who care about outcomes, not usability heuristics

Here is a UX research finding: [describe the finding in plain terms, e.g. "60% of participants couldn't find the cancel-subscription option and contacted support instead"].

Write a short business case (under 150 words) for a non-design stakeholder audience (e.g. a finance or operations lead) that:
1. States the finding in one sentence, without design jargon
2. Connects it to a likely business cost, using only the numbers or context I've given you -- if I haven't given you cost data, say what kind of data would let you estimate it, don't invent a figure
3. Proposes one specific, scoped fix (not "redesign the whole flow")
4. States what we'd want to re-test after the fix, so this isn't a one-off claim

Write it as something I could paste directly into a Slack message or a one-slide summary, not a full report.