AI in your workflow

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.

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.

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.

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.

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 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.