Write interface copy that matches the real system state

Interface wording should tell people what happened and what they can do next. A polished message is harmful if it describes a success the system has not confirmed.

Prepare the input

Provide the user task, actual states, available next actions, and character constraints if relevant. Include what is known after a timeout. Do not ask the assistant to invent product behavior to make the messages feel complete.

Run the workflow

Ask for one message per state with a purpose and next action. Keep tone consistent while preserving technical meaning. Distinguish a saved draft, submitted request, pending approval, and completed operation.

Prompt to copy

User task: [task]. Actual states and actions: [details].
Draft concise labels, confirmations, and error messages.
For each give state, message, next action, and factual basis.
Do not describe pending or uncertain work as completed.
Do not promise retries, notifications, or recovery that do not exist.
Flag missing behavior decisions separately.

Review a worked example

Illustrative booking system has accepted a request but has not reserved a slot. “Request received; confirmation is pending” matches that state. “You're booked” does not. After an uncertain timeout, “Try again” may be unsafe if it can duplicate the reservation. Check wording against the actual recovery path.

Read every message with its available action. A helpful sentence that directs users to a nonexistent button creates another failure. Check retry language against duplicate-operation behavior. For translations, compare meaning state by state: a polite version must not sound more certain than the original about whether the operation completed.

Use it again

Review messages with the product owner and test them in context. Translation should preserve the state, not merely the tone. Explore Bot for copy preparation or contact Golub about the underlying workflow.