Prompt library

AI design sprint prompt library

Prompts for every stage of an AI design sprint, plus a set by function. Replace anything in [SQUARE BRACKETS], then paste into ChatGPT, Copilot, Claude or Gemini.

From the AI Design Sprints workshop.

Replace anything in [SQUARE BRACKETS] with your own details. Do not paste confidential data into a public tool. Treat every output as a draft a person has to check.

A sprint works when you pick a real process, map it as it actually runs, and redesign the work before you add a tool. Start with the four prompts below. The rest of the library opens when you leave your name, email and company.

#01

Score three candidate processes

Pick

When to use: You have a few messy ideas for a sprint and need to pick one that is worth the room's time.

Help me choose which process to take into an AI design sprint.

Organisation: [ORGANISATION]
Team: [TEAM]
The processes in contention:
1. [PROCESS 1]: what it produces is [OUTPUT], it runs [HOW OFTEN], and it is owned by [OWNER]
2. [PROCESS 2]: what it produces is [OUTPUT], it runs [HOW OFTEN], and it is owned by [OWNER]
3. [PROCESS 3]: what it produces is [OUTPUT], it runs [HOW OFTEN], and it is owned by [OWNER]

Constraints:
- Tools we already have: [TOOLS ALREADY LICENSED]
- Data or policy limits: [LIMITS]
- The person who has to say yes: [SPONSOR]

Score each process on:
- Pain: how much time, rework or waiting it burns
- Frequency: how often it runs
- Clarity of output: whether we can tell if a change worked
- Access: whether the people who do the work can be in the room
- Risk: data sensitivity, and what happens if an output is wrong

For each process, tell me:
- The score and the reason
- The one assumption that would kill it if it were false
- Whether the work should be redesigned before any AI is added
- A first prototype we could try with the tools we already have

Then recommend one process, and say what I should leave out of scope so the sprint stays tight.

Rules:
- Do not invent volumes, costs, times or percentages. If a number is missing, say so and name what should be measured.
- Do not recommend a tool or vendor that is not already listed.
- Flag assumptions, and flag anything a person still has to decide or sign off.
- Treat the output as a draft, never a final decision.
- If the work should be simplified before any AI is added, say that plainly.

Tip: Pick the process people already complain about, not the one that sounds impressive on a slide.

#08

Map how the work actually runs

Map

When to use: You need a picture of the current process as it is really done, not as it is documented.

Help me map how this process actually runs today, including the unofficial steps.

Organisation: [ORGANISATION]
Process: [PROCESS]
What a finished piece of work looks like: [OUTPUT]
The official steps, if we have them: [OFFICIAL STEPS]
What people say they actually do:
[WHAT PEOPLE ACTUALLY DO]

People involved and what each one thinks they own: [PEOPLE AND OWNERS]
Systems and documents they touch: [SYSTEMS]
Typical request or case I can describe: [EXAMPLE CASE]
Known workarounds: [WORKAROUNDS]
Known exceptions: [EXCEPTIONS]

Give me:
1. A step-by-step map of the real path, from trigger to done
2. The official path beside it, with the gaps named
3. Handoffs, waits, and places work gets copied from one system to another
4. Decision points (a person has to judge) versus grind (a person is moving information)
5. Where work loops back or is redone
6. Questions I should take back to the people who do this, to close the remaining gaps

Mark every step I have not actually confirmed as a guess. Do not tidy the mess. The mess is the map.

Rules:
- Do not invent volumes, costs, times or percentages. If a number is missing, say so and name what should be measured.
- Do not recommend a tool or vendor that is not already listed.
- Flag assumptions, and flag anything a person still has to decide or sign off.
- Treat the output as a draft, never a final decision.
- If the work should be simplified before any AI is added, say that plainly.

Tip: Ask what happens when it goes wrong. The official path rarely includes the workarounds.

#15

Find where time and rework hide

Friction

When to use: You have a process map and you want the few points where a change would actually matter.

I have a map of this process. Help me find the friction that is actually worth fixing.

Organisation: [ORGANISATION]
Process: [PROCESS]
The current map:
[PROCESS MAP]

What people complain about: [COMPLAINTS]
Rework they described: [REWORK]
Handoffs: [HANDOFFS]
Places they copy between systems: [COPYING]
Judgement calls: [JUDGEMENT CALLS]
A typical case and a messy case: [TYPICAL AND MESSY]

Do this:
1. List the friction points you can see (waits, handoffs, rework, copying, unclear ownership, judgement asked too late or too early).
2. For each, say who feels it, what it does to the work, and whether I have enough evidence or only a story.
3. Rank them by likely impact on the finished work, not by how noisy the complaint is. Do not invent a score out of ten that pretends to be precise.
4. Flag friction that looks tempting for AI but is really a process design problem (unclear "done", missing owner, two sources of truth).
5. Pick the three points a sprint should take on, and the ones it should park.
6. For the top point, write the riskiest assumption, and a cheap way to test it before we build.

Be blunt where the map is thin. Guessing is how sprints pick the wrong fight.

Rules:
- Do not invent volumes, costs, times or percentages. If a number is missing, say so and name what should be measured.
- Do not recommend a tool or vendor that is not already listed.
- Flag assumptions, and flag anything a person still has to decide or sign off.
- Treat the output as a draft, never a final decision.
- If the work should be simplified before any AI is added, say that plainly.

Tip: Friction that happens on every case beats a dramatic one-off.

#22

Redesign the work before adding a tool

Redesign

When to use: You have a map and a target, and you want a cleaner process first, with AI only where it earns a place.

Help me redesign this process first, and only then decide where AI belongs.

Organisation: [ORGANISATION]
Process: [PROCESS]
Current map:
[PROCESS MAP]

The friction we want to fix: [FRICTION]
The output that must still be true at the end: [REQUIRED OUTPUT]
People and what they should own: [PEOPLE]
Constraints we cannot move in this sprint: [CONSTRAINTS]
Tools we already have: [TOOLS ALREADY LICENSED]

Give me:
1. A redesigned path, step by step, from trigger to done. Cut, combine or clarify before you add any tool.
2. A side-by-side of "today" and "proposed", with the reason for each change
3. Owners for each step, and a clear definition of "done"
4. The human checkpoints (where a person must review, decide or sign off)
5. Only then: the one or two places a tool could help, what it would take in, and what it would produce
6. What we are not changing, and why
7. A thin prototype of the new path we could try with a real case

If the honest redesign does not need AI, say so. A cleaner process is a valid sprint outcome.

Rules:
- Do not invent volumes, costs, times or percentages. If a number is missing, say so and name what should be measured.
- Do not recommend a tool or vendor that is not already listed.
- Flag assumptions, and flag anything a person still has to decide or sign off.
- Treat the output as a draft, never a final decision.
- If the work should be simplified before any AI is added, say that plainly.

Tip: If a step exists to fix an earlier mess, repair the earlier mess. Do not give the cleanup a chatbot.

#02

Write a sprint brief from a messy complaint

Pick

When to use: Someone has vented about a process, and you need a brief the room can work from.

Turn this complaint into a tight AI design sprint brief.

Organisation: [ORGANISATION]
Team: [TEAM]
The complaint, in the person's own words:
[COMPLAINT]

What I already know:
- Who feels the pain: [WHO]
- When it shows up: [WHEN IT SHOWS UP]
- What a good outcome looks like, if we know: [DESIRED OUTCOME]
- Tools we already have: [TOOLS ALREADY LICENSED]
- Limits: [LIMITS]

Write a brief with:
1. The problem, in one plain sentence, from the point of view of the person who does the work
2. The user: who they are, and what they are trying to finish
3. What we think happens today, marked clearly as a guess where I have not confirmed it
4. The decision this sprint must produce (proceed, change, or stop)
5. What is in scope, and what is out
6. The evidence we still need, and the cheapest way to get it
7. A first question we should ask the people who run this process

Do not tidy the complaint into corporate language. Keep the specific, awkward details. They are usually the brief.

Rules:
- Do not invent volumes, costs, times or percentages. If a number is missing, say so and name what should be measured.
- Do not recommend a tool or vendor that is not already listed.
- Flag assumptions, and flag anything a person still has to decide or sign off.
- Treat the output as a draft, never a final decision.
- If the work should be simplified before any AI is added, say that plainly.

Tip: Keep the original complaint in the brief. Cleaning it too early hides the real pain.

#03

Is this even a sprint candidate?

Pick

When to use: A leader has already named a process, and you want an honest view on whether a sprint will help.

Tell me honestly whether this process is a good candidate for an AI design sprint, or whether we should leave it alone.

Organisation: [ORGANISATION]
Proposed process: [PROCESS]
Why it was nominated: [WHY IT WAS NOMINATED]
Who nominated it: [NOMINATOR]
Who does the work today: [OPERATORS]
What I know about volume, time or cost (leave blank if unknown): [KNOWN FIGURES]
Known blockers: [BLOCKERS]
Tools we already have: [TOOLS ALREADY LICENSED]
Sponsor and what they want: [SPONSOR AND ASK]

Assess:
- Is the problem real, or is it a slogan ("we should use AI") looking for a home?
- Can a mixed team produce a tested concept and a decision in a short, focused sprint?
- Is the work too big, too rare, or too dependent on a system we cannot change?
- Is the real block a process design issue, a policy, a missing owner, or a data problem?
- What would have to be true for a sprint to be worth running?

Give a clear recommendation: sprint, narrow it first, or do not sprint. If you recommend narrowing, say exactly what to cut. If you recommend not sprinting, say what we should do instead.

Rules:
- Do not invent volumes, costs, times or percentages. If a number is missing, say so and name what should be measured.
- Do not recommend a tool or vendor that is not already listed.
- Flag assumptions, and flag anything a person still has to decide or sign off.
- Treat the output as a draft, never a final decision.
- If the work should be simplified before any AI is added, say that plainly.

Tip: If the real block is a policy, a vendor contract or a missing owner, a sprint will not fix it. Say so.

#04

Separate 'we should use AI' from the real problem

Pick

When to use: The brief you were given starts with a tool, and you need to find the underlying problem.

The brief I was given starts with a tool. Help me find the real problem underneath it.

Organisation: [ORGANISATION]
Team: [TEAM]
What I was asked to do: [ORIGINAL ASK]
The tool or approach someone already has in mind: [PROPOSED TOOL]
The work this is supposed to help: [WORK]
Who does that work today: [OPERATORS]
What "done" looks like for them: [DONE LOOKS LIKE]
What has already been tried: [ALREADY TRIED]

Do this:
1. Restate the original ask, then set the tool aside.
2. Name the job the person is trying to finish, in their language.
3. List the plausible problems that could sit underneath (time, errors, handoffs, waiting, judgement, missing information).
4. For each, say what evidence would confirm or kill it.
5. Recommend the problem we should take into a sprint, and a problem statement that does not mention a tool.
6. Say under what conditions the proposed tool might still be the right answer, after the work is redesigned.

The output should make it easy to walk back to the person who asked and change the brief without embarrassing them.

Rules:
- Do not invent volumes, costs, times or percentages. If a number is missing, say so and name what should be measured.
- Do not recommend a tool or vendor that is not already listed.
- Flag assumptions, and flag anything a person still has to decide or sign off.
- Treat the output as a draft, never a final decision.
- If the work should be simplified before any AI is added, say that plainly.

#05

Find a process from a typical week

Pick

When to use: The team cannot name a process, but they can describe a messy week.

We cannot point to a single process yet. Here is how a typical week looks. Help me find a process worth taking into a sprint.

Organisation: [ORGANISATION]
Team and roles in the room: [ROLES]
A typical week, as described by the team:
[TYPICAL WEEK]

Recurring meetings: [RECURRING MEETINGS]
Tools they live in: [TOOLS]
Things they say take too long: [COMPLAINTS]
Things that break or get redone: [REWORK]
Work they take home or do after hours: [AFTER HOURS WORK]

From this, extract:
- The repeating processes hiding in the week (name them plainly)
- Where time seems to go, without inventing hours I did not give you
- Which processes have a clear output, and which are just motion
- The two or three strongest sprint candidates, with a one-sentence problem for each
- One process we should ignore, and why

Ask me five sharp follow-up questions that would confirm the best candidate. Prefer questions the people in the room can answer from memory.

Rules:
- Do not invent volumes, costs, times or percentages. If a number is missing, say so and name what should be measured.
- Do not recommend a tool or vendor that is not already listed.
- Flag assumptions, and flag anything a person still has to decide or sign off.
- Treat the output as a draft, never a final decision.
- If the work should be simplified before any AI is added, say that plainly.

Tip: Calendars and inboxes are a better starting point than a process catalogue.