UI/UX

<context>
Problem: [problem, e.g. overdue invoices get buried in a list]
Product: [product, e.g. an invoicing web app for freelancers]
I'm not a designer.
</context>
 
<task>
Interview me the way a product designer would before
designing the screen or flow that solves this problem. Don't
design anything yet.
</task>
 
<requirements>
- At most 10 questions, grouped: users and task; content
  and data; platform and design system; constraints and
  success.
- For each: why the answer changes the design, and 2-3
  typical answers I can pick from.
- Ask what evidence I have (research, analytics, support
  tickets) and what to do if I have none.
- Define each design term the first time (state, breakpoint,
  design system).
</requirements>
 
<output_format>
Numbered questions under the four group headings, each
followed by "Why:" and "Typical answers:".
</output_format>
 
<process>
Ask all the questions, then stop. When I answer, write the
brief back as bullets, with the open questions that need
research.
</process>

<materials>
[paste the brief from stage 1]
[paste evidence: research notes, tickets, analytics]
</materials>
 
<task>
Propose 2-4 materially different design directions for this
screen or flow, and recommend one.
</task>
 
<requirements>
- Directions differ in structure or interaction pattern, not
  styling: e.g. a prioritized list, a task inbox, summary
  cards, a guided wizard.
- For each: a one-paragraph description; the primary
  action; the Nielsen heuristics it serves or risks; how it
  handles empty and error states; mobile behavior; build
  effort with our components; the main risk.
- Low fidelity only: structure and behavior, no visuals.
- Recommend one for the user's main task, say what would
  change your mind, and what a five-user test should check.
</requirements>
 
<output_format>
A table: Direction | Primary action | Strengths | Risks |
Mobile | Effort. Then the recommendation in 3 sentences.
</output_format>
 
<process>
Stop after the recommendation and wait for my choice. Don't
spec screens yet.
</process>

<materials>
Brief and chosen direction: [paste from stages 1-2]
Design system: [paste components and tokens, or "none"]
Real content: [paste sample records and the longest strings]
Evidence: [paste research findings, tickets, analytics]
</materials>
 
<context>
Task: [task, e.g. freelancers checking weekly who owes them]
Platform: [platform: responsive web | iOS | Android | desktop]
Breakpoints: [widths, e.g. 375, 768 and 1280 px]
Stack: [stack, e.g. React + Tailwind]
Success metric: [metric, e.g. reminders sent within 7 days]
</context>
 
<examples>
[paste or describe 1-2 reference screens, with what to borrow]
[paste or describe 1 you dislike, with why, e.g. vanity KPIs]
</examples>
 
<task>
Write the prototype spec for the chosen direction: enough
to build a clickable prototype and test it with five users.
</task>
 
<requirements>
- Flow: numbered steps (screen, user action, system
  response); decision points; error branches (invalid input,
  network failure, no permission, going back, leaving
  halfway); a Mermaid flowchart.
- Per screen at [fidelity: wireframe | mockup]: regions top
  to bottom with purpose, real content, component, priority
  and column span; one primary action; what changes on
  mobile.
- Component states: default, hover, focus-visible, active,
  disabled, loading, empty, error, success, with triggers.
- 8-point grid: spacing only from 4, 8, 12, 16, 24, 32, 48,
  64 px; smaller gaps inside groups than between them.
- WCAG 2.2 AA: text 4.5:1 (large text 3:1), non-text 3:1,
  targets at least 24x24 CSS px (44x44 on touch), reflow at
  320 px, visible focus, nothing by color alone; list every
  color pair to verify.
- Microcopy: buttons as verb + object; errors say what
  happened and how to fix it.
- Mark undecided product questions [DECISION NEEDED].
- Never invent numbers, names, quotes or sources: write
  [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- The user's main question is answered in five seconds; the
  primary action is the most prominent element.
- Every screen has empty, loading, error and success states;
  every flow has its error branches.
- No Nielsen heuristic violation you'd rate 3 or 4.
- Accessibility is specified with numbers, not "accessible".
- Only our components and tokens, on the spacing scale.
</quality_bar>
 
<output_format>
Markdown: 1. Flow, then Mermaid. 2. Per screen: a table
(Region | Purpose | Content | Component | Priority |
Columns) and ASCII sketches for desktop and mobile. 3. State
matrix: Element | State | Trigger | Visual change (tokens) |
Copy | Screen-reader text. 4. Microcopy. 5. Color pairs to
verify. 6. Open questions.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. Spec the flow first and
stop for my OK, then the screens. End with a list of the
assumptions you made.
</process>

<materials>
Brief: [paste]
Prototype spec or screenshots: [paste]
</materials>
 
<context>
This is a fresh chat. The spec was written in another chat;
I want a design review before I build and test it.
</context>
 
<task>
Review the spec as a heuristic evaluation plus an
accessibility and states check, and rank the fixes. Don't
redesign or rewrite it.
</task>
 
<requirements>
- Nielsen's 10 heuristics by name; each finding with its
  location, severity 0-4 (0 not a problem, 4 catastrophe)
  and the effect on the user.
- WCAG 2.2 AA: contrast pairs (say which need measuring;
  don't estimate from images), target size, focus visible
  and not obscured, keyboard path, reflow at 320 px, color
  alone, status messages.
- States: any screen or component missing empty, loading,
  error, partial or success.
- Consistency: one-off components, values off the spacing
  scale, two terms for one concept.
- Rank fixes by severity, then effort; say what each fix
  must achieve, not the new design.
</requirements>
 
<output_format>
A table: # | Location | Problem | Heuristic or WCAG criterion
| Severity | What the fix must achieve. Then the top 3 fixes,
then what to test with five users.
</output_format>
 
<process>
End with a list of the assumptions you made and what you
couldn't judge without the running prototype.
</process>

Plan research to answer
[question, e.g. why trials don't send a first invoice]: 3-5
learning goals with a method each, a 6-question screener and
a 45-minute interview guide about past behavior. Check: no leading or hypothetical questions.

<materials>
[paste what we know: analytics, tickets, past research]
</materials>
 
<context>
Product: [product, e.g. an invoicing web app for freelancers]
Users: [users, e.g. trial users in their first week]
Budget: [budget, e.g. 2 weeks, 8 participants, no incentives]
Methods we can run:
[methods: interviews | usability test | survey | card sort]
</context>
 
<task>
Plan research to answer
[question, e.g. why trial users don't send a first invoice],
so we design from evidence.
</task>
 
<requirements>
- 3-5 learning goals, each with its method and why.
- A recruiting screener of 6-8 questions that excludes
  people outside the target without revealing it.
- A 45-minute interview guide: warm-up, questions about the
  last time they did the task (past behavior, not opinions),
  probes, wrap-up.
- No leading or hypothetical questions; flag any that could
  bias answers.
- Never invent numbers, names, quotes or sources: write
  [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every learning goal maps to a design decision.
- Interview questions ask about specific past events ("the
  last time you…").
- The screener doesn't reveal what we're looking for.
- The plan fits the time and budget.
</quality_bar>
 
<output_format>
A table: Goal | Method | Decision it informs. Then the
screener, the interview guide with timings, and a
note-taking template.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. End with a list of the
assumptions you made.
</process>

Affinity-map these notes into themes: per theme a one-line
insight, participant IDs, two verbatim quotes and the design
implication. Use only the notes. Check: every quote appears
word for word in the notes. [paste notes, labeled by ID]

<materials>
[paste notes, each labeled with a participant ID]
</materials>
 
<context>
Study: [study: interviews | usability test | survey free text]
Research question: [question, e.g. why trials stall]
Participants: [count, e.g. 8 trial users, 2 churned]
</context>
 
<task>
Synthesize the notes into themes we can design from.
</task>
 
<requirements>
- Affinity mapping: group observations into themes; per
  theme, a one-line insight, the participants it came from
  (by ID), two verbatim quotes, the design implication.
- JTBD statements ("When…, I want to…, so I can…") only
  where the notes support them.
- Surprises, contradictions between participants, open
  questions.
- Don't generalize beyond the notes. Never invent numbers,
  names, quotes or sources: write [NEEDS SOURCE] where
  support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every quote is verbatim and attributed.
- Counts are participants, not mentions.
- Each implication could be tested in a prototype.
</quality_bar>
 
<output_format>
A table: Theme | Insight | Participants | Quotes |
Implication. Then the JTBD statements, then surprises,
contradictions and open questions.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. End with a list of the
assumptions you made.
</process>

Build one self-contained HTML file prototyping
[screen, e.g. the invoices list] with Tailwind's CDN script:
real content from my data, a toolbar to switch states,
semantic HTML, keyboard support. Check: list every color
pair so I can verify contrast. [paste data]

<materials>
Spec: [paste the prototype spec or wireframe description]
Data: [paste records, including the longest name and a zero]
Tokens: [paste color, spacing and type tokens]
</materials>
 
<context>
For: [use: usability test | stakeholder demo | dev handoff]
Viewport range: 320 to 1440 px.
</context>
 
<examples>
[paste or describe 1-2 reference screens, with what to borrow]
[paste or describe 1 you dislike, with why, e.g. generic SaaS]
</examples>
 
<task>
Build a single self-contained HTML file prototype of
[flow, e.g. recording a partial payment].
</task>
 
<requirements>
- Tailwind from its Play CDN script; no other dependencies.
- Real content from the data; no lorem ipsum.
- A small toolbar to switch states:
  [states, e.g. default, empty, loading, error, long content].
- Semantic HTML (button, a, label, nav, main, table), a full
  keyboard path, visible focus rings, a label on every input.
- Spacing only from 4, 8, 12, 16, 24, 32, 48 px; colors only
  from the tokens.
- WCAG 2.2 AA: text 4.5:1, borders and focus 3:1, targets at
  least 24x24 px, reflow at 320 px.
- Never invent numbers, names, quotes or sources: write
  [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every state in the toolbar renders and is reachable by
  keyboard.
- No div used as a button or link.
- No value off the spacing scale or outside the tokens.
- The primary action is the most prominent element in every
  state.
</quality_bar>
 
<output_format>
One HTML file in a code block. Then a table of every text and
UI color pair: foreground hex | background hex | estimated
ratio | "verify".
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. End with a list of the
assumptions you made.
</process>

Spec a [component, e.g. file upload field]: every state
(default, hover, focus-visible, active, disabled, loading,
error, success) with trigger, visual change in tokens, copy,
screen-reader text and keyboard behavior. Check: no state
relies on color alone.

<materials>
Design: [paste the description, tokens or a screenshot]
</materials>
 
<context>
Component: [component, e.g. file upload field]
Platform: [platform: web | iOS | Android]
System: [system: our own | Material 3 | Apple HIG | none yet]
Content: [limits, e.g. file names up to 120 characters]
</context>
 
<task>
Write a component spec an engineer can build from without
asking me questions.
</task>
 
<requirements>
- Anatomy, variants, sizes.
- Every state with its trigger: default, hover,
  focus-visible, active, disabled, loading, empty, error
  types, success, read-only, plus any the component needs
  (e.g. drag-over, uploading with progress).
- Tokens per state, not raw values; motion tokens and
  reduced-motion behavior.
- Accessibility: native element or ARIA pattern (WAI-ARIA
  APG), keyboard behavior, accessible name, announcements.
- Content rules: max lengths, truncation, room for strings
  about 30% longer in translation.
- Edge cases; acceptance criteria as testable statements.
- Mark undefined behavior [DECISION NEEDED]. Never invent
  numbers, names, quotes or sources: write [NEEDS SOURCE]
  where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every state has a trigger and a visual change in tokens.
- Focus is visible at 3:1; no state relies on color alone.
- Every acceptance criterion can pass or fail in a test.
</quality_bar>
 
<output_format>
Sections: purpose, anatomy, variants and sizes, state matrix
(State | Trigger | Visual change | Copy | Screen-reader text |
Keyboard), accessibility, content rules, edge cases,
acceptance criteria.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. End with a list of the
assumptions you made.
</process>

Write microcopy for [screen, e.g. the invoices list]: empty,
no results, load failure, offline, no permission. Each: a
heading, one sentence on why, a button as verb + object.
Check: every error says what happened and how to fix it.

<materials>
Current strings: [paste labels, buttons and error messages]
Voice guide: [paste, if you have one]
</materials>
 
<context>
Screen: [screen, e.g. the invoices list]
Users: [users, e.g. freelancers checking money between jobs]
Tone: [tone: plain | friendly | formal]
</context>
 
<examples>
[paste 1-2 messages you like, with why, e.g. names the fix]
[paste 1 you dislike, with why, e.g. "Oops!" and no fix]
</examples>
 
<task>
Write the microcopy deck for every state of this screen and
rewrite the current strings.
</task>
 
<requirements>
- States: first-use empty, no results (with the user's
  query), cleared, load failure, offline, no permission,
  success.
- Buttons as verb + object; errors say what happened, then
  how to fix it, without blame; empty states say what goes
  here, why it helps, and give one action; confirmations
  name the consequence.
- Labels in sentence case; one term per concept.
- Length: [limit, e.g. buttons under 20 characters]; leave
  room for translations about 30% longer.
- Never invent numbers, names, quotes or sources: write
  [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every button names its action.
- Every error has a fix the user can do.
- One term per concept across the deck.
- Every string fits the length limit.
</quality_bar>
 
<output_format>
A table: State | Heading | Body | Button | Screen-reader
text. Then the rewritten strings: original | new | rule.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. End with a list of the
assumptions you made.
</process>

Write a moderated usability test script for
[prototype, e.g. the payment flow]: intro, 2 warm-up
questions, 5 task scenarios that don't use the UI's labels,
success criteria, neutral probes, SUS. Check: no task gives
away the answer.

<materials>
Prototype: [paste the spec or a link description]
Research goals: [paste the learning goals]
</materials>
 
<context>
Format:
[format: moderated in person | moderated remote | unmoderated]
Participants: [users, e.g. 5 freelancers who invoice monthly]
Session length: [length, e.g. 30 minutes]
</context>
 
<task>
Write the test script and observation sheet so that I can
run five sessions and compare them.
</task>
 
<requirements>
- An intro that says we're testing the design, not them,
  and asks them to think aloud.
- 2 warm-up questions about past behavior.
- 5 realistic task scenarios that don't use the UI's own
  labels, each with a success criterion.
- Neutral probes ("What did you expect to happen?").
- A SUS questionnaire and a wrap-up.
- Never invent numbers, names, quotes or sources: write
  [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- No task names the button or menu the user must find.
- Every task maps to a research goal.
- Probes are neutral; none suggests an answer.
- It fits the session length with time to spare.
</quality_bar>
 
<output_format>
The script with timings. Then an observation sheet: Task |
Success | Time | Errors | Quotes.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. End with a list of the
assumptions you made.
</process>

Critique the attached screenshot for [user, e.g. a freelancer]
trying to [task, e.g. find who owes money]. Table: location,
problem, Nielsen heuristic, severity 0-4, fix. Check: don't
guess contrast ratios from the image.

<materials>
[paste or attach the screenshot]
Hex values and sizes: [paste the ones you know]
</materials>
 
<context>
User: [user, e.g. a freelancer between client calls]
Task: [task, e.g. find who owes money this week]
Platform: [platform: web | iOS | Android]
The screen should make [action, e.g. sending a reminder]
obvious.
</context>
 
<examples>
[paste or attach 1-2 screens that do this task well, with why]
</examples>
 
<task>
Critique the screen as a heuristic evaluation and rank what
to fix first. Don't redesign it.
</task>
 
<requirements>
- First, one sentence on what you think the screen is for
  and its primary action; if that's wrong, it's finding 1.
- Findings tied to Nielsen's 10 heuristics by name, with
  location and severity 0-4.
- Visible accessibility concerns: labels, color-only
  meaning, target sizes, text size. Say which need
  measuring; don't estimate contrast from the image.
- Comment on taste only where it affects the task.
- Never invent numbers, names, quotes or sources: write
  [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every finding has a location and a named heuristic.
- Severities are consistent: 3-4 only for task blockers.
- No contrast ratio is stated without hex values.
</quality_bar>
 
<output_format>
A table: # | Location | Problem | Heuristic | Severity | Fix
direction. Then the three changes with the biggest impact.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. End with a list of the
assumptions you made.
</process>

Audit this HTML/CSS against WCAG 2.2 AA: semantics, names,
keyboard and focus order, focus visible and not obscured,
contrast pairs, target size, status messages, reflow at
320 px. Table: issue | criterion | element | fix.
Check: cite the success criterion number. [paste code]

<materials>
[paste the HTML and CSS]
</materials>
 
<context>
Prototype of [screen, e.g. the invoices list]
Users include keyboard and screen-reader users.
Target: [target: WCAG 2.2 A | WCAG 2.2 AA]
</context>
 
<task>
Audit the code and give me the fixes, most severe first.
</task>
 
<requirements>
- Check: semantic elements and landmarks; heading order;
  labels and accessible names; keyboard operability and
  focus order; focus visible (2.4.7) and not obscured
  (2.4.11); contrast of the colors in the CSS, showing the
  pairs; target size (2.5.8); status messages (4.1.3);
  reduced motion; reflow at 320 px (1.4.10).
- Native HTML before ARIA.
- Say what only a manual test with a keyboard and a screen
  reader can confirm.
- Never invent numbers, names, quotes or sources: write
  [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every issue cites a success criterion by number.
- Every fix is code, not advice.
- Contrast pairs come from the CSS, with hex values.
</quality_bar>
 
<output_format>
A table: Issue | Success criterion | Element | Fix (code).
Then the corrected code.
</output_format>
 
<process>
End with a list of the assumptions you made. This doesn't
replace testing with assistive technology.
</process>

Design a dashboard for my SaaS app.

<materials>
Support tickets: [paste the tickets about overdue invoices]
Components: [paste our component list]
</materials>
 
<context>
The home screen of an invoicing web app for solo freelance
designers. They open it about once a week, often on a laptop
between client work, to answer one question: who owes me
money, and what should I chase today? Data per user: 0-400
invoices; statuses draft, sent, viewed, paid, overdue;
amounts up to $250,000; client names up to 60 characters.
Current pain: overdue invoices are buried in a long list.
</context>
 
<task>
Write a low-fidelity wireframe spec for the home screen, so
we can test its structure before any visual design.
</task>
 
<requirements>
- One primary action, and why.
- Regions in priority order with real labels and sample
  data; overdue invoices surface without alarming people
  who have none.
- States: new account (no invoices), all paid, 12 overdue,
  loading, failed to load.
- Desktop (1280 px, 12 columns) and mobile (375 px).
- Our components only; WCAG 2.2 AA; no charts unless they
  answer the weekly question better than a list.
- Never invent numbers, names, quotes or sources: write
  [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- The weekly question is answered in five seconds.
- Every state above is specified.
- No Nielsen heuristic violation of severity 3 or 4.
- Status is never shown by color alone.
</quality_bar>
 
<output_format>
A table: Region | Purpose | Content | Component | Priority |
Columns. ASCII sketches for desktop and mobile. Then the
states, then 3 alternative layouts in one line each.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. End with a list of the
assumptions you made.
</process>

Primary action: "Send reminders" in the overdue banner. The
weekly job is chasing overdue money, so one click reminds
every overdue client.
 
Region          Content (sample)                   Priority
Overdue banner  "3 invoices overdue - $4,180"       1
                [Send reminders]
Needs action    client, invoice #, amount, days     1
                overdue; sorted by days overdue
Recent          last 10 invoices, all statuses      2
Summary         paid this month, outstanding        3
 
Desktop: banner across 12 columns; list 8, summary 4.
Mobile: banner, then the list as cards; summary collapses.
 
States
- New account: "No invoices yet. Create one to start getting
  paid." [Create invoice]
- All paid: banner hidden; "Nothing overdue" in the summary.
- 12 overdue: banner shows count and total; list pages at 10.
- Loading: skeleton rows the height of real rows.
- Failed to load: "Couldn't load invoices. Check your
  connection and try again." [Retry]; last data kept, dimmed.
Overdue rows: clock icon + "12 days overdue" text + red.
 
Alternatives: a single sorted list with no banner; a weekly
"chase list" checklist; a calendar of due dates.
Assumptions: reminders are emails; one currency per account.

Change only the primary action. Replace bulk "Send reminders"
with "Review reminders": a panel listing each overdue client
with amount, days overdue and last contact, a checkbox per
client (all checked), an email preview, and a confirm button
that names the count ("Send 3 reminders"). Add a 10-second
undo after sending. Spec its states (none selected, sending,
sent, failed for one client) and keep everything else.

Check this design against Nielsen's 10 heuristics with
severity 0-4. Which states are missing? Which elements could
go with no loss for the user's main task?
[paste the design or spec]

List every text and UI color pair in this design with its
hex values. I'll verify contrast; mark any pair you think is
close to 4.5:1 (text) or 3:1 (borders, icons, focus).