Prompt Library

I am planning research for [product and the decision this research should inform].

My current plan:
[paste plan: goals, method, participants, questions]

Before suggesting improvements:
1. List the assumptions my plan depends on.
2. For each research question, say whether my method can actually answer it, and why.
3. Point out any question that is leading, double-barrelled or asks people to predict their own behaviour.

Then suggest changes, keeping to my timeline of [timeline] and [number] participants.

Do not write findings or guess what participants will say.

Below are notes from [number] user interviews about [topic]. Each note starts with a participant ID.

[paste notes]

Group the notes into candidate themes.

For each theme give:
- a neutral name
- the participant IDs that support it
- two or three direct quotes, copied exactly
- any participant who contradicts it

Rules:
- Use only what is in the notes. Do not add sentiment, motivation or frequency that is not stated.
- If a theme rests on one participant, label it "single source".
- List notes that fit no theme under "Unsorted".

Here is the proposed navigation for [product], used by [who].

[paste the structure as an indented list]

Their top tasks are:
[list 5 to 8 tasks]

For each task, say which top-level item a first-time user would most likely open, and how confident you are. Flag any task where two items are plausible.

Then list:
- labels that are jargon or internal names
- categories that overlap
- items a user might expect that are missing

Do not propose a new structure yet.

Here is a user flow for [task] in [product], for [user].

[paste the steps, numbered]

Constraints: [platform, sign-in state, permissions, anything fixed]

For each step, list what could go wrong or differ:
- missing, invalid or unusual input
- the user leaving and returning
- slow or failed network
- permissions and roles
- empty, very large or very long data
- going back or repeating the step

Mark each as "must handle", "should handle" or "rare". Do not redesign the flow.

Current flow for [task]:
[paste steps]

What the user is trying to achieve: [goal]
What the business needs from this flow: [need]
What cannot change: [constraints]

Propose three structurally different flows, not variations of mine. For each:
- the steps
- what it makes easier
- what it makes harder
- the assumption it depends on

Do not recommend one.

I am wireframing the [page name] page of [product].

The user arrives from [where] wanting to [goal].
After this page they should be able to [next step].

List:
1. The information the user needs to decide or act, in priority order.
2. The actions available, primary first.
3. The states this page needs: empty, loading, error, partial, no permission.
4. Content that is commonly added to pages like this but is not needed here.

Describe content and priority only. Do not describe layout, components or visual style.

Review this interface as a senior product designer.

Context:
- Product type: [e.g. enterprise dashboard]
- User and task: [who, doing what]
- Platform and viewport: [e.g. web, 1440 px]
- Design system: [name, or "custom"]

Do not redesign it immediately.

First evaluate: information hierarchy, alignment, spacing, typography, colour, accessibility, interaction states, information density, consistency and responsive behaviour.

Give every finding one type:
1. Standard requirement (name the standard and criterion)
2. Design-system issue (name the rule)
3. Industry convention
4. Craft guidance
5. Subjective preference

For every finding explain what you noticed, why it matters, its severity, and what I could try.

Where you cannot tell from the image, such as exact contrast or pixel values, say "verify" and tell me what to measure.

Do not invent WCAG requirements, design-system rules or research findings. If you are unsure whether something is a rule, say so.

Look at this screen for [product]. The user's main goal here is to [goal].

Without reading the text closely, list the first five things your attention goes to, in order, and say what draws it to each: size, weight, colour, position or contrast.

Then compare that order with the goal:
- Is the primary action among the first three?
- What is prominent but unimportant?
- What is important but quiet?

Suggest the smallest changes that would fix the order. Prefer reducing emphasis over adding it.

Do a first-pass accessibility review of this design against WCAG 2.2 Level AA.

Design: [attach or describe]
Platform: [web / iOS / Android]

Report in three groups:
A. Likely failures visible in the design. Cite the success criterion number and name.
B. Things that cannot be judged from a static design and must be tested: keyboard order, focus management, screen reader output, zoom and reflow.
C. Questions for the designer, where intent is unclear.

For contrast, do not estimate ratios from the image. List the text and background pairs I should measure.

This is not a conformance audit. Do not invent WCAG requirements, design-system rules or research findings. If you are unsure whether something is a rule, say so.

Write error messages for this form in [product].

Fields and validation rules:
[field: rule, for each]

Voice: [e.g. plain, direct, no apology]

For each rule give one message that:
- says what is wrong
- says how to fix it
- uses the field's own label
- is under [number] words

Avoid "invalid", "illegal", "oops" and blaming the user. Give the same message for the inline error and the summary.

If a rule is ambiguous, ask me instead of guessing.

Draft copy for the empty state of [screen or list] in [product].

It can be empty because:
1. [first use: nothing created yet]
2. [filters or search returned nothing]
3. [the user lacks permission, if applicable]

For each cause write:
- a heading of five words or fewer saying what is true
- one sentence on what will appear here
- the label for the action that fills it

Voice: [describe]. No jokes, no exclamation marks.

You are working inside an existing design system. Follow it; do not extend it.

Tokens:
[paste spacing, radius, colour and type tokens]

Components available:
[list components and their variants]

Task: [what to design or build]

Rules:
- Use only the tokens and components above.
- If the task needs something the system lacks, stop and tell me what is missing. Do not invent a colour, radius, spacing value or component.
- After the output, list every token and component you used.

Here are the styles used in [file, page or stylesheet]:
[paste values, or a list of colours, radii, spacing and font sizes with counts]

Here are our tokens:
[paste tokens]

List:
1. Values that match no token, with how often each appears.
2. Values within 2 px or a near-identical colour of a token, and which token they probably meant.
3. Tokens that are never used.

Do not suggest new tokens. Sort by frequency.

This screen is designed at [width] px. It must work from 320 px to [max] px.

[attach or describe the layout: regions, columns, fixed elements]

List what is likely to break as the width narrows, in the order it would break:
- content that will wrap, truncate or overflow
- side-by-side regions that will not fit
- tables and comparisons
- fixed or sticky elements that will cover content
- touch targets that become too small or too close

For each, give the approximate width where it fails and two ways to handle it. Do not choose for me.

Here are the components and screens in this design:
[list them, with the states I have already designed for each]

For each one, list the states that are missing from: default, hover, focus, active, disabled, loading, empty, error, success, read-only, selected.

Only list a state if it applies to that component. For each missing state, say in one line what would trigger it.

Sort by the states users are most likely to hit.

Write behaviour documentation for [component or screen] for the developers building it.

What I have designed:
[describe, or attach frames with annotations]

Write:
1. Purpose, in one sentence.
2. States, and what triggers each.
3. Interactions: click, keyboard, touch.
4. Content rules: limits, truncation, wrapping.
5. Responsive behaviour at each breakpoint.
6. Open questions, where my design does not say.

Only document what I have described. Put anything you would have to assume under Open questions, not in the spec.

Draft acceptance criteria for this feature.

Feature: [name]
User story: [as a..., I want..., so that...]
Design behaviour: [paste the behaviour documentation]

Write criteria in Given / When / Then form covering:
- the main path
- each error and empty state
- keyboard operation
- the smallest supported screen width

One behaviour per criterion. Do not add behaviour that is not in the design; list it as a question instead.

Here is a product brief:
[paste]

As the designer who has to act on it, list:
1. What the brief states clearly.
2. What it assumes without evidence.
3. Decisions it leaves open that design cannot proceed without.
4. Requirements that conflict with each other.

Then write the five questions I should ask the product manager first, most blocking first.

Do not fill the gaps yourself.

Help me explain a design decision to [audience: e.g. engineering lead, marketing director].

The decision: [what I chose]
The alternatives I rejected: [list]
My reasons: [evidence, constraints, principles]
What they care about: [their goal or worry]

Write a short explanation that:
- leads with what it means for them
- gives my reasons in my order of strength
- names the trade-off honestly
- states what would change my mind

Use only the reasons I gave. Do not add research, statistics or standards I did not mention.

Here is a draft case study:
[paste]

Read it as a hiring manager with three minutes.

Tell me:
1. What you understood my role and decisions to be, in two sentences. If you cannot tell, say so.
2. Where I describe process without saying what I decided or why.
3. Claims of impact with no evidence.
4. What I could cut.

Do not rewrite it. Do not add outcomes, numbers or praise.

Review this flow for a Singapore government digital service.

Flow: [paste steps or attach screens]
Users: [who]

Use only the guidance I paste below. Do not rely on your memory of Singapore standards.

Baseline Design Practices:
[paste the BD controls that apply, from the official catalogue]

SGDS guidance:
[paste the relevant component and foundation guidance]

For each control, say whether the flow meets it, does not meet it, or cannot be judged from what I gave you. Quote the control text you are applying.

Then list SGDS components the flow could use in place of custom ones.