CONVERSION
Inline validation and error recovery
Use when people start a form, hit an error, and never come back to finish it.
inline-validation-error-recovery.md
You are reviewing how a form behaves when the visitor gets something wrong. You are not redesigning the form or cutting fields.
FIELDS AND THEIR VALIDATION RULES: {{FIELD_RULES}}
ERROR MESSAGES EXACTLY AS THEY APPEAR: {{CURRENT_ERROR_TEXT}}
WHEN VALIDATION FIRES (on submit, on blur, on keystroke): {{VALIDATION_TIMING}}
FIELDS WITH THE MOST ABANDONMENT IF KNOWN: {{PROBLEM_FIELDS}}
Output a table: Field | Rule | Current message quoted from {{CURRENT_ERROR_TEXT}} | What the visitor actually did wrong | Can they fix it from the message alone? (Yes/No) | Rewritten message | Better timing.
Then answer:
- Which rules in {{FIELD_RULES}} reject input that is genuinely valid: spaces in card and phone numbers, apostrophes and accents in names, plus addressing in email, addresses outside the assumed country. List each as a defect, not a copy problem.
- Which messages blame the visitor instead of describing the fix.
- Where {{VALIDATION_TIMING}} punishes someone mid-typing, and what it should be instead.
- What happens to data already entered when a submit fails, and whether focus and scroll return to the first error.
Finish by ranking {{PROBLEM_FIELDS}} by how likely error handling is the cause, and say plainly where abandonment is more likely to be the field itself.
Do not invent error text I have not supplied. No exclamation marks and no em dashes.
Fill in before running
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
- {{FIELD_RULES}}
- {{CURRENT_ERROR_TEXT}}
- {{VALIDATION_TIMING}}
- {{PROBLEM_FIELDS}}
Getting a better result
-
1
Paste the messages verbatim, including the ones only a server response produces.
-
2
Test with a real card number containing spaces and a name with an apostrophe before you accept the rules are fine.
-
3
The rules marked as defects go to engineering, not to a copywriter.
Questions about this prompt
When do I look at errors rather than at the field list?
When people start the form, hit an error and never come back. This reviews behaviour on failure rather than which fields exist, so it complements the reduction prompt rather than replacing it. Its most valuable output is not copy at all: it separates rules that reject valid input from messages that are merely unhelpful.
What do I need in front of me before running it?
The validation rules, the error messages quoted exactly as they appear including the ones only a server response produces, when validation fires, and the fields with the most abandonment. It will not invent error text you did not supply, so a paraphrase gets you a rewrite of something your form never actually says.
What comes back, and which part is worth acting on?
A table per field ending in a rewritten message and better timing, then the rules that reject genuinely valid input, listed as defects rather than as copy problems. That defect list is the valuable part: spaces in card numbers, apostrophes in names and plus addressing in email are silent rejections nobody ever reports.
What is the mistake that costs me here?
Sending the whole output to a copywriter. The defects belong with engineering, and rewriting the message for a rule that should not exist leaves the rejection in place. Try a card number with spaces and a name with an apostrophe yourself before accepting that the rules are fine, since it takes two minutes.