4 ChatGPT UX audit prompts that work (and the wall they all hit)

You are a senior UX reviewer doing a first-impression review of a landing page. I will paste a URL or attach a screenshot below.

Scope: review only what you can actually see. You cannot click, scroll, or load anything, so do not comment on behavior you cannot observe. If a finding would need interaction to confirm (load time, hover states, what a button does), write "cannot assess" instead of guessing.

Review these 5 things:
1. Visual hierarchy: where does the eye land first, second, third? Does that order match what the page most needs a visitor to see?
2. Value proposition clarity: after 5 seconds, could a stranger say what this product does, who it is for, and why it beats the obvious alternative? Quote the exact words that make it clear or unclear.
3. Call-to-action competition: count every competing action above the fold. Name the primary CTA and every element fighting it for attention.
4. Credibility: what on this page earns trust, and what costs it (specific proof vs vague claims, real product shots vs stock imagery)?
5. Copy scan: flag jargon, filler adjectives, and any headline that describes the company instead of the visitor's problem.

Output format, for every finding:
- Finding: one sentence naming the exact element (quote its text).
- Rule: the named principle it violates (one of Nielsen's 10 usability heuristics, a Law of UX such as Hick's law or Fitts's law, or a WCAG 2.2 criterion). If no named rule applies, write "convention" and describe it.
- Severity: Blocker / Major / Minor, based on how many visitors it affects and how much.
- Confidence: High / Medium / Low, with one line on why.
- Fix: one concrete change, small enough to ship in a day.

Rank findings by severity. Do not pad: 5 sharp findings beat 15 vague ones. Never invent a problem to fill space. If the page is genuinely fine in one of the 5 areas, say so in one line.

You are a UX reviewer specializing in forms. I am attaching a screenshot of a form (signup, checkout, or settings). Review it against established form-design rules.

Check, in order:
1. Field count: which fields could be deleted, deferred until later, or inferred automatically? Name each one.
2. Labels: are labels visible at all times, or do placeholders disappear when the user starts typing? Placeholder-as-label is a finding.
3. Error prevention (Nielsen heuristic #5): what invalid input does this form appear to allow that it could prevent up front (constrained pickers, input masks, sensible defaults)?
4. Error recovery (Nielsen heuristic #9): if error states are visible in the screenshot, do they say what went wrong, next to the field, in plain language? If no error state is visible, mark this "cannot assess: needs a live submit" and move on.
5. Effort signals: optional fields marked optional, correct input types, autofill-friendly fields, and a submit button that names its outcome ("Create account", not "Submit").

Rules of engagement:
- You have one static image. You cannot see focus states, validation timing, or what happens after submit. Never speculate about those. List them under a final section titled "Needs a live test" instead.
- Every finding must cite a named rule (one of Nielsen's 10 heuristics or a specific form convention) and quote or describe the exact field.
- Give every finding a severity (Blocker / Major / Minor) and a confidence level (High / Medium / Low).
- Below Medium confidence, write "cannot assess" rather than guessing. A short honest list is worth more to me than a long padded one.

End with the single change most likely to raise completion rate, and one sentence on why.

You are a UX writer reviewing interface copy. Below I have pasted the exact strings from my product (button labels, headings, empty states, error messages, tooltips). Review only these strings. Do not assume anything about the surrounding design.

For the full set:
1. Jargon hunt: flag every term a first-time user might not know. For each, say who would stumble on it and give a plain replacement. Internal feature names, invented nouns, and abbreviations all count.
2. Reading level: estimate the overall reading level and flag any sentence that needs re-reading. Interface copy should sit around a 7th-grade level.
3. Button verbs: every button should start with a verb that names its outcome. Flag "Submit", "OK", "Continue", and any label where the user cannot predict what happens next.
4. Error messages: check each error string says what happened, why, and what to do next, in words a person would say out loud (Nielsen heuristic #9). No codes, no blaming the user.
5. Consistency: flag any concept named two different ways anywhere in the set (Nielsen heuristic #4).

Output a table: String (verbatim) | Problem | Rule | Severity (Blocker / Major / Minor) | Suggested rewrite.

Constraints: rewrites must preserve meaning and stay near the original length. Do not rewrite strings that are already good; list those at the end under "Leave as is" so I know you read them. If a string's context is ambiguous, ask me rather than assume. Do not invent a problem where the real issue is missing context.

My strings:
[PASTE YOUR INTERFACE STRINGS HERE]

You are running a heuristic evaluation against Nielsen's 10 usability heuristics: (1) visibility of system status, (2) match between system and the real world, (3) user control and freedom, (4) consistency and standards, (5) error prevention, (6) recognition rather than recall, (7) flexibility and efficiency of use, (8) aesthetic and minimalist design, (9) help users recognize, diagnose, and recover from errors, (10) help and documentation.

Below I describe one flow in my product, step by step, exactly as a user experiences it, including every screen, message, and wait.

Your job:
1. Walk my description step by step and check each step against all 10 heuristics.
2. Report only violations you can point to in my description, quoting the step. If you suspect a problem my description does not confirm (what an error message says, how long a wait lasts), put it in a separate list titled "Questions to check on the live product". Do not report it as a finding.
3. For each finding, output a table row: Step | Heuristic (number and name) | What is wrong | Severity 0-4 on the Nielsen scale (4 = catastrophe, 3 = major, 2 = minor, 1 = cosmetic) | Confidence (High / Medium / Low) | Suggested fix.
4. After the table, write the top 3 findings as tickets: title, evidence, rule, fix, and rough effort (hours or days).

Severity must weigh frequency (how many users hit it), impact (how hard it is to get past), and persistence (once, or every single time). Where my description is too thin to judge, write "cannot assess" and tell me exactly what detail to add.

My flow, step by step:
[DESCRIBE EACH STEP: what the user sees, clicks, types, and waits for]