The prompts I keep for design work, from first request to handoff.

Use it when: you start a new conversation about a project. Every other prompt on this page assumes it has been run.

I'm working on the design of [product]. Read this and don't produce anything yet.

Product: [what it is, in one or two sentences]
Users: [who uses it and what they're trying to get done]
Business goal: [what the company needs from this work]
Constraints: [platform, deadline, technology, brand, legal]
Done looks like: [the outcome that would count as success]
Still unknown: [open questions]

Reply only with the three things in this brief that are least clear or most likely to be wrong, written as questions.

A good answer

Three sharp questions and no design ideas.

Before you use it

If it starts suggesting solutions, it skipped the instruction. Say so and ask again.

Use it when: a request has arrived and you haven't spoken to anyone about it yet.

Here's the request as it came in: [paste]. List what it states, what it assumes, and what it leaves out. Then write the five questions I should ask the person who sent it before doing any design work. Rank them by how much each answer would change the work.

A good answer

Assumptions you hadn't noticed, and questions you would actually ask.

Before you use it

The "states" list should match the request word for word, with nothing added.

Use it when: you need to know what people are trying to get done, apart from any feature.

Based on the brief, describe the job people hire [product] to do. Write it as: When [situation], I want to [motivation], so I can [outcome]. Give three versions: the task itself, the goal behind it, and why it matters to them. Mark which parts come from my brief and which you inferred.

A good answer

Three versions that sit at clearly different levels.

Before you use it

The inferred parts are guesses. Take them into your interviews as questions.

Use it when: you're about to talk to real users.

Write a 30 minute interview guide for people who recently [started using / switched to / stopped using] [product or category]. Focus on the last time it happened: what set it off, what they tried first, what nearly stopped them, and what they did afterwards. Open questions only. No questions about features they would like. Add two follow up prompts under each question.

A good answer

Questions about things that happened, not opinions about what might.

Before you use it

Cut any question that starts with "Would you" or "Do you like".

Use it when: you have raw notes from several interviews.

Here are notes from [number] interviews: [paste]. Group what people said into four forces: what pushed them away from the old way, what pulled them toward the new one, what worried them about switching, and what habits kept them where they were. Quote the notes for each point and say how many interviews it came from. Put anything that came up only once in a separate list.

A good answer

Quotes you can trace back to a person, with a count beside each point.

Before you use it

Check three quotes against your notes. If one is reworded or made up, don't trust the rest.

Use it when: you're about to commit to a direction.

List every assumption in this brief and these findings: [paste]. For each one, say what has to be true, how confident we are (high, medium or low) and why, and what happens to the project if it's wrong. Put the least certain, highest impact ones first. Suggest the cheapest way to test the top three.

A good answer

A short list at the top that makes you a little uneasy.

Before you use it

The tests should take days, not months.

Use it when: you need to know what you're really competing with.

List how people get this job done today without [product], including workarounds, spreadsheets, other tools and doing nothing at all. For each one, say what it does well and where it breaks down. Don't compare feature lists. Say which points you're sure of and which I should verify.

A good answer

"Doing nothing" and "a spreadsheet" both make the list.

Before you use it

Check any product name or statistic yourself before it goes in front of anyone.

Use it when: the research is done and you need to say what the problem is.

Using these findings: [paste], write three different problem statements. Each one names the user, the situation, the problem and why it matters now. Then argue against each one: what evidence would contradict it, and what it leaves out. Finish by saying which one the findings support best, and why.

A good answer

Three statements that really are different, each with honest weaknesses.

Before you use it

The one it picks should rest on your findings, not on which sounds best.

Use it when: you have a problem statement and want to widen it before designing.

Turn this problem statement into eight "How might we" questions: [paste]. Make some narrow and some broad. Keep solutions out of the wording. Mark the two most promising and give one line on why for each.

A good answer

A mix of narrow and broad questions, none of which names the answer.

Before you use it

Rewrite any question that mentions a feature.

Use it when: before design starts, so everyone agrees what success means.

For this problem: [paste], suggest how we would know the design worked. Give one measure of what users do, one business outcome, and one thing we could check within two weeks of launch. For each, say what it would miss.

A good answer

Measures you could actually collect.

Before you use it

Ask engineering or analytics whether each one can be tracked.

Use it when: you need a first version of the scope document.

Draft a scope outline: the problem, who it's for, what's in, what's out, open questions, risks, and how we'll measure success. Use only what's in the brief and the findings. Where something is missing, write [needs input] instead of filling it in.

A good answer

Several gaps marked [needs input]. That's the honest result.

Before you use it

Nothing in it should surprise you. If something does, find out where it came from.

Use it when: the list of requirements is longer than the time you have.

Here are the requirements: [paste]. Sort them into must have, should have and later. Give a one line reason for each, tied to the problem statement. Flag any requirement that doesn't serve the problem, and any two that conflict.

A good answer

A short must have list, and at least one flag.

Before you use it

Each reason should point back to the problem, not to what sounds important.

Use it when: you're about to design and don't want to settle on your first idea.

Give me five genuinely different ways to solve [problem]. They should differ in approach, not in styling: at least one that removes a step, one that automates it, and one that changes who does it. For each one, give the idea in two sentences, what it does well, what it costs, and who it would fail.

A good answer

At least one idea you wouldn't have come up with.

Before you use it

If two are the same idea on different screens, ask for a replacement.

Use it when: you've picked a direction and need to lay it out step by step.

Map the flow for [user] trying to [task] using [approach]. For each step, list what the user sees, what they do, and what the system does. Then list every place the flow can branch: errors, missing data, permissions, going back, and leaving and returning later.

A good answer

More branches than you expected.

Before you use it

Walk through it yourself with a real example.

Use it when: a screen has only been designed for the ideal case.

For this screen: [describe or paste], list every state it needs besides the ideal one: empty, loading, partial data, error, no permission, offline, too much data, and first use. For each, say what the user needs to know and what they can do next.

A good answer

Every state gives the user something to do next.

Before you use it

Compare it with your file and design what's missing.

Use it when: you need labels, buttons, help text and error messages.

Write the interface copy for [screen or component]. Voice: [for example: plain, direct, no jargon]. Include labels, buttons, helper text and error messages. Buttons say what happens when you press them. Errors say what went wrong and how to fix it. Give two options for anything people will read more than once.

A good answer

Short and specific, and it sounds like the product.

Before you use it

Read it out loud. Cut anything that tries to be clever.

Use it when: before the design goes to engineering.

Here's the design: [describe]. Find the edge cases: long names, missing fields, very large numbers, other languages, slow connections, screen readers, keyboard only use, people using it for the first time and people who use it every day. Rank them by how likely each is to happen to a real user.

A good answer

The likely cases at the top, not the unusual ones.

Before you use it

Agree with engineering which of these the design has to handle.

Use it when: you have a prototype and want to watch real people try it.

Write a usability test plan for [prototype or flow]. The goal is to find out whether [user] can [task] without help. Include five tasks written as realistic situations rather than instructions, what to watch for in each, and three questions to ask at the end. Don't use the words on the buttons in the task wording.

A good answer

Tasks that read like things that happen in real life.

Before you use it

Try it on a colleague first and cut any task that gives away the answer.

Use it when: the design is going to engineering.

Write handoff notes for [screen or flow]: [describe or paste]. Cover what it does, every state and when it appears, the rules behind any logic, the copy, the accessibility requirements, and the open questions. Write for an engineer who wasn't in any of the meetings.

A good answer

Someone could build it without asking you anything.

Before you use it

Walk through it with the engineer. Every question they ask is a gap in the notes.

Use it when: you've looked at something too long to see it clearly.

Critique this [screen / flow / copy]: [paste or describe]. Judge it against this goal: [goal]. List the three biggest problems first, each with why it matters and a specific fix. Then list the smaller issues. Don't tell me what's working unless I ask.

A good answer

Problems tied to the goal, not to taste.

Before you use it

Ignore any fix that would undo a decision you made on purpose.

Use it when: before a review or a pitch.

Act as [an engineering lead / a finance lead / a head of sales] seeing this proposal for the first time: [paste]. Ask the ten hardest questions they would ask. Then tell me which three I'm least prepared to answer.

A good answer

Questions you would rather hear now than in the room.

Before you use it

Prepare answers for the three it picks.

Use it when: on any screen, before it goes to engineering.

Review this design for accessibility: [describe or paste]. Check contrast, focus order, keyboard use, screen reader labels, touch target size, motion, and anything that relies on colour alone. Cite the WCAG 2.2 criterion for each issue. Say which items you can't judge from a description and I need to test myself.

A good answer

Issues with the criterion named, and an honest list of what it can't judge.

Before you use it

Measure contrast with a tool. Don't take a model's word for colour values.

Use it when: the same decision needs explaining to different people.

Explain this design decision to [an engineer / an executive / a customer]: [paste]. Keep it to [length]. For an engineer, focus on behaviour and edge cases. For an executive, focus on the outcome and the risk. For a customer, focus on what changes for them.

A good answer

Versions that are genuinely different, not one version cut three ways.

Before you use it

Make sure no version promises something new.

Use it when: you've made a choice someone will question later.

Write a decision record for this choice: [describe]. Include the context, the options we considered, what we chose and why, what we gave up, and what would make us revisit it. Keep it under 300 words.

A good answer

An honest "what we gave up" section.

Before you use it

Keep it somewhere the team will find it.

Use it when: you feel finished.

Here's where the work stands: [summary]. What am I missing? Think about users I haven't mentioned, risks, dependencies, and anything from the brief I seem to have dropped. Only list things that would change a decision.

A good answer

A short list. A long one means your summary was thin.

Before you use it

Act on each point, or write down why you won't.

Use it when: answers are getting generic, drifting from the brief, or agreeing with everything you say.

Stop. Read the project brief again. List every place in your last three answers where you went beyond it, assumed something, or simply agreed with me. Then answer my last question again using only the brief.

A good answer

It names specific places where it drifted.

Before you use it

If it can't find any and you saw some, start a new conversation with the brief.

Use it when: you need something this page doesn't have.

Use the project brief.
[One clear task, in a sentence or two.]
Here is the material: [paste the real thing, not your summary of it].
Lay the answer out as [a list / a table / three options / under 200 words].
Leave out [what you don't want]. Mark anything you inferred rather than read in my material.