How to rewrite UI text with AI — step by step, with a ready-made prompt

Ask a model to "write text for a button" and you get "Submit", "Continue" and "Oops! Something went wrong". Technically correct, practically useless: those are the same placeholders you were trying to escape.

It's not the model's fault. Good interface text is impossible to write without knowing what happens on that screen before the click and after it. And that's usually missing from the prompt.

Here are six steps that turn a generator of polite placeholders into a decent editor. Ready prompt at the end.

Step 1. List the screen's strings

Don't describe the screen in prose and don't expect the model to "look for itself". Build a three-column table as plain text: where the string lives, what it says now, how many characters fit.

form submit button   | Submit          | max 22 chars
email field label    | Email           | max 30 chars
empty-field error    | Required field  | max 60 chars
empty request list   | No data         | max 80 chars

The limit isn't nitpicking. Without it the model returns a lovely phrase that gets cut off mid-word on a phone.

Step 2. Give it the context it can't have

Three things, without which the text stays generic:

1. Who's reading. "Small business owners, non-technical, mostly on phones" already narrows the vocabulary a lot.
2. What happened before. "They filled in the form and are waiting for a callback" — otherwise the model writes about abstract submitting.
3. What happens next. "We charge $19 and email a receipt" — that's what turns "Continue" into "Pay $19".

The third one matters most: the consequence is exactly what separates a useful button from a meaningless one. More on the material itself in microcopy.

Step 3. Set hard constraints

Constraints save more time than edits do. The minimum set:

• address the reader directly, and pick one register — stick to it;
• buttons are action verbs, not nouns: "Save draft", not "Saving";
• errors follow "what happened + what to do";
• banned words: "Oops", "Whoops", "Something went wrong", "Please try again later";
• no exclamation marks or emoji unless you have a reason.

Step 4. Ask for three options and a reason, not one answer

One answer has nothing to compare against. Three is a choice — and a one-line "why" shows whether the model understood the task (and catches the times it didn't).

The weak prompt sounds like this: "write the button text for my form". Here's the strong one — take it whole and adapt:

You are a UI copy editor. Product: booking a haircut; audience is
ordinary people on phones; address the reader directly and informally.

Screen context: the person has filled in name and phone and is pressing
the last button. After the click the request goes to the stylist, no
money is charged, and the stylist calls back the same day.

Rewrite the strings. For each one give 3 options plus a one-line "why".

STRINGS:
- submit button | "Submit" | max 22 chars
- empty phone error | "Required field" | max 60 chars
- post-submit screen | "Thank you!" | max 90 chars

RULES: button = verb + result; error = what's wrong and what to do;
banned: "Oops", "Something went wrong", "Please"; no emoji; never
exceed the character limits.

Step 5. Run the result through a checklist

A model tends to miss in the same places. Check by hand:

• The button answers "what will happen", not "what am I doing".
• The error says what to do next. "Invalid format" doesn't. "Enter the phone as +1 555 123-4567" does.
• The field label is still a label and hasn't slid inside the field as grey text (why that's bad: placeholder vs label).
• The empty screen offers the next action instead of announcing "No data".

A typical fix after this step looks like this. Before: "Error. Invalid data format." After: "Phone needs a country code — add +1." The first one tells you you're wrong. The second fixes the problem in one move — and it's even shorter.

Step 6. Paste it in and look at it on a phone

Text doesn't live in a chat window. Paste the options into the code and open it on a narrow screen: a long button wraps to two lines, an error pushes the field down, a label gets truncated. If it doesn't fit, go back to step 1 and tighten the limit — don't stretch the layout.

A separate trap if your interface is bilingual: the same meaning is usually longer in Russian than in English. A button that fit the mockup perfectly in English wraps once translated. So set character limits by the longest language, not the one the mockup was drawn in.

What you end up with

Instead of "Submit → Required field → Thank you!", you get a chain like "Book this stylist → Enter your phone so the stylist can call back → Request sent, they'll call today". No new screens, no new logic: only the words changed, and support tickets drop.

The second effect is less obvious: while you're assembling context for step 2, you start noticing holes in the flow itself — like the fact that nowhere do you say when they'll call.

The model still writes too politely — how do I stop it?

Add a length cap and a ban on filler: "max 8 words, no polite openers, don't explain the obvious". With models, politeness is length; you cut it with a limit, not with "write simpler". General technique: how to write a good prompt.

Should I give it a screenshot instead of a string list?

A screenshot helps with layout, but it doesn't solve the real problem: an image doesn't show what happens after the click, and it doesn't show your limits. Best case, give both. If you only give one, give the list.

How do I know it got better?

The cheapest test is a person who's never seen your product. Show them the screen for ten seconds and ask: "what happens if you press this button?" If they paraphrase it correctly, the text works.