Interface content helps people decide what to do and understand what happened. Write it alongside the interaction, including the states that appear before, during, and after an action. Liquidify renders the content supplied by the application; it does not infer product terminology or complete the task behind a label.

Name the task and outcome

Use familiar words consistently. A page heading identifies the task or subject; a control label describes an action or value. Prefer sentence case and concise phrases that retain enough context to predict the result.

Use the recovery message only if the application actually preserves entries and supports retrying. Do not claim that data was saved, sent, or deleted before the operation completes.

Give each piece of text a purpose

A description should add information that the title and controls do not already provide. Put essential consequences near the decision. Avoid repeating a button label in a paragraph that only tells people to choose that button.

For a confirmation, identify the affected item and explain whether recovery is possible. Keep routine success feedback in context when no interruption is needed. Dialogs covers when a focused decision justifies a modal.

Write the complete state sequence

1. Before an action, explain required information and any meaningful consequence.
2. While waiting, identify the operation in progress and prevent accidental repetition where needed.
3. On success, confirm the actual result in the relevant context.
4. On failure, explain what remains unchanged or retained and offer a valid recovery action.
5. On cancellation, return people to a clear point in their task.

Button's loading prop displays a busy state and suppresses activation. It does not generate a product-specific progress message or a success announcement. Dialog action callbacks request closure after activation; plan subsequent feedback in the application instead of expecting the dialog to await a save.

Make labels accessible

Keep a persistent label for a field or setting. Placeholder text can illustrate a format but should not be its only name. Match an accessible name to the visible wording where possible, so speech input and visual instructions refer to the same control.

Use Text's semantic as option for paragraphs and headings when composing content. Do not use a large variant alone to imply document structure. Review label and description wiring in the relevant component catalog.

Prepare content for translation

Keep messages as complete units, with named placeholders where the application needs values. Avoid assembling sentences from fragments whose order depends on English. Leave space for longer labels, different scripts, and locale-specific dates and numbers. The application owns translation, pluralization, and formatting; the components do not supply a general localization service.

Use neutral, direct language. Avoid idioms, unexplained technical terms, or humor in errors that could obscure the recovery action. Review terminology with the people who use the product.

Related implementation

• Typography covers hierarchy and readable text.
• Text, TextField, and Button provide the relevant APIs and examples.

Further reading

• Apple: Writing
• Apple: Inclusion