ECOMMERCE

Checkout microcopy and error messages

Use when checkout drop off is high and the labels, helper text and errors were written by whoever built the form.

checkout-microcopy-and-errors.md

Download .md

You are rewriting checkout interface strings. You are not redesigning the flow and you are not adding steps.

Current strings, one per line with the field or state they belong to:
{{CURRENT_STRINGS}}
Checkout steps in order: {{CHECKOUT_STEPS}}
Validation rules the code actually enforces: {{VALIDATION_RULES}}
Where people drop off: {{DROPOFF_DATA}}

Output a table: Step | Field or state | Current string | Rewrite | Type (label, helper, error, button, reassurance) | Why it changed.

Then two lists:
A. NOT A COPY PROBLEM - strings where the rule in {{VALIDATION_RULES}} is the fault. Say what the code should do instead.
B. MISSING - points in {{CHECKOUT_STEPS}} with no message at all where a shopper would expect one.

Rules:
- Every error must state what happened, which field, and the exact next action. An error with no recovery step is unfinished.
- Never blame the shopper. No "invalid", no "you entered".
- Do not promise anything about cost, delivery, security or data handling that the current strings do not already promise.
- Order rows so the steps named in {{DROPOFF_DATA}} come first.
- Labels and buttons stay under 60 characters. Show the count on those rows.
- Rewrite only strings present in {{CURRENT_STRINGS}}. No em dashes, no exclamation marks.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{CURRENT_STRINGS}}
{{CHECKOUT_STEPS}}
{{VALIDATION_RULES}}
{{DROPOFF_DATA}}

Getting a better result

Export the strings from the codebase rather than reading them off the screen. Half the error states never render in a happy path walkthrough.
List A is usually the shorter list and the bigger win. A copy fix cannot rescue a postcode validator that rejects real postcodes.
Test the card decline messages with a real test card. That is the state that costs the most and gets written the worst.

Questions about this prompt

When is this better than redesigning the checkout flow?

When drop off is high and the strings were written by whoever built the form. A redesign is a quarter of work. This changes only the words inside the existing steps, and it separates out the places where words are not the problem, which is worth knowing before anyone scopes the redesign.

Where should the current strings come from?

The strings exported from the codebase rather than read off the screen, the steps in order, the validation rules the code really enforces, and where people drop off. Half the error states never render in a happy path walkthrough, so a screen based list misses the messages that are costing you orders.

What comes back besides the rewrites?

A rewrite per string with its type and reason, ordered so your drop off steps come first, then list A of strings where the validation rule is at fault and list B of points with no message at all. List A is shorter and worth more: no wording rescues a postcode validator that rejects real postcodes.

What gets edited back out of an error message?

Trimming an error message back to the problem and dropping the next action. The prompt treats an error with no recovery step as unfinished, and editors reinstate short ones for consistency. Watch too for a rewrite that adds reassurance about security or delivery that your current strings do not already promise.