Microcopy Generator Guide for Mobile Apps

A microcopy generator workflow starts by rewriting one mobile screen’s buttons, errors and empty state around the next user action. Use verb-first button labels such as “Save changes” instead of “Submit” or “OK”; keep labels to roughly 20–25 characters before they risk wrapping; and use sentence case. Write every error as one sentence that names both the cause and the fix, such as “Enter a valid email address to continue.” Draft the empty state before the populated screen so its message, action and recovery path are deliberate.

Key takeaways

•Keep a mobile button label to roughly 20–25 characters before it risks wrapping.
•Use verb-first labels such as “Save changes” to name the action’s outcome.
•Replace “OK” with a label that describes the next action or result.
•Write each validation error as one sentence containing the cause and fix.
•Material Design uses sentence case for buttons, labels and text fields.

This guide is for mobile product designers, UX writers, founders and engineers who already work with iOS or Android screen flows.

Time: 25 minutes · You'll need: One iOS or Android screen with buttons, an error and an empty state, A copy inventory in FigJam, a text document or a spreadsheet, A device preview or platform design file for checking line wraps

What's on this page

•Inventory every decision on one screen
•Write verb-first button copy UX
•Write errors with cause and fix
•Apply sentence case for ux writing mobile
•Draft the empty state before the populated state
•Reference table

•Common mistakes
•FAQs

Rewrite mobile microcopy, step by step

1. Inventory every decision on one screen

Pick one screen that contains at least one primary button, one possible error and one empty state. A saved-items screen works well: it has a “Create list” action, a failed-name validation message, and an initial state with no lists. Copy each visible string into three columns: current text, user situation, and next user action.

Do not start by polishing individual words. Identify the state that triggers each string. For example, “No items yet” is not enough information to write useful app microcopy; the situation is “the user has opened Saved items for the first time,” and the next action may be “save an item” or “browse products.” This distinction prevents a button from saying “OK” when it should say “Browse products.”

Include system-controlled states too. On iOS, alert and action-sheet wording must fit the system presentation. On Android, use the component’s available action pattern rather than adding a second primary action inside a small error message.

Tip: If a string has no identifiable user situation, remove it or define the missing product state before writing.

2. Write verb-first button copy UX

Replace generic button labels with a verb-first phrase that names the outcome. Change “Submit” to “Send request,” “Done” to “Save changes,” and “OK” on a permission explanation to “Open Settings” when that is the actual next step. Apple’s Human Interface Guidelines advises using clear, concise labels that describe the action a button performs. Material Design’s writing guidance similarly treats labels as direct instructions for action.

Set a working budget of roughly 20–25 characters for a button label before it is likely to wrap in common mobile layouts. Check the real component width at the largest supported text size, because a 24-character English label can still wrap when Dynamic Type or Android font scaling is active. If it wraps, do not reduce the type size below the platform’s intended text scaling behavior. Rewrite “Continue to payment details” as “Review payment,” provided the destination still matches the label.

Keep destructive consequences explicit. Use “Delete photo,” not “Remove,” when deletion is permanent.

Tip: When a button opens a new screen rather than completing work, name the destination or task: “Choose delivery” is clearer than “Continue.”

3. Write errors with cause and fix

Write each error as one sentence that states the cause and the fix. Use the pattern: “[Cause]; [fix].” For example: “Your password needs 8 characters or more.” Or: “Enter a valid email address to continue.” The first tells the user what failed and the second tells them exactly what to change.

Avoid vague alerts such as “Something went wrong,” “Invalid input,” or “Try again.” They force the user to infer the failed condition and often cause repeated failed attempts. WCAG 2.2 Success Criterion 3.3.1 Error Identification requires input errors that are automatically detected to be identified and described to the user in text. When the correction is known, WCAG 3.3.3 Error Suggestion requires suggestions unless that would jeopardize security or the purpose of the content.

Place a field-specific error next to its field and preserve the user’s entered value where the product can safely do so. For a network failure with no known user fix, say what happened and offer the available recovery action: “Couldn’t refresh orders. Try again.”

Tip: Do not tell users to “contact support” for a validation error that the screen can explain and correct.

4. Apply sentence case for ux writing mobile

Change Title Case interface strings to sentence case: “Add payment method,” “Couldn’t load orders,” and “No saved items yet.” Material Design 3’s writing guidance specifies sentence case for UI text, including buttons and text fields. Sentence case gives small controls fewer visually dominant capital shapes, which makes groups of labels easier to scan at mobile sizes.

Preserve proper nouns, branded product names, acronyms and the first word of a sentence. Write “Sign in with Apple,” “Enable Face ID,” and “Upload PDF.” Do not mechanically lowercase a legal name or a platform feature. Apple’s platform names also retain their documented capitalization.

Review each screen as a set. A single title-case button among sentence-case labels looks like a different control family, even if its color and size match. For an existing product with an established editorial system, follow that system only where it does not contradict platform conventions or accessibility requirements. The immediate task is consistency within the one screen you are rewriting.

Tip: Sentence case does not mean casual case: retain punctuation when it makes an error’s cause and fix unambiguous.

5. Draft the empty state before the populated state

Write the empty state before you write the populated-state helper text. An empty state is the user’s first explanation of what this area contains, why it is empty, and what action creates the first result. Draft three parts: a factual status, a short benefit or explanation, and one next action. For example: “No saved items yet. Save products to compare them later. Browse products.”

This order exposes unclear product logic early. If you cannot name the first action, the populated state may also lack a clear creation path. Do not use “Nothing here” or “No data” when the user needs to know whether content is loading, filtered out, unavailable, or simply not created yet. Those are four different states and require different app microcopy.

Use one primary action in the empty state when there is one obvious next step. If the user can create content in more than one way, explain the default route in the body and keep the primary button focused on the most common route. Verify that the button label matches the destination screen exactly.

Tip: A search result with zero matches is not a first-use empty state; write “No results for ‘trail shoes’” and offer a search refinement instead.

Reference table

Mobile microcopy checks for one screen

Element	Working spec	Example
Button label	~20–25 characters	Check real width and scaling
Button wording	Verb first	Name the outcome
Validation error	Cause + fix	One sentence
UI capitalization	Sentence case	Material Design guidance
Input error rule	WCAG 2.2 SC 3.3.1	Identify and describe errors

Common mistakes

Using “Submit,” “Done,” or “OK” for actions with a specific result.

Name what happens next: “Save address,” “Send message,” or “Open Settings.” Keep “OK” only where acknowledging information is genuinely the only action.

Writing “Something went wrong” for field validation.

Name the failed condition and correction in one sentence. For example, “Enter a postcode in the required format.”

Treating every zero-content screen as the same empty state.

Distinguish first use, zero search results, active filters and unavailable content. Each state has a different cause and next action.

Shortening labels by hiding the consequence.

Prefer “Delete account” over “Delete” when the object is not obvious. Reduce surrounding helper text before making a destructive action ambiguous.

Frequently asked questions

What should button copy say in a mobile app?

Mobile button copy should start with a verb and name the action’s outcome, such as “Save changes” or “Add card.” Avoid “Submit,” “Done,” and “OK” when they hide what the tap will do. Use roughly 20–25 characters as a working pre-wrap budget, then test the actual component with platform text scaling.

How do I write an error message for an app form?

Write an app form error as one sentence that states the cause and the fix, such as “Enter a valid email address to continue.” WCAG 2.2 SC 3.3.1 requires automatically detected input errors to be identified and described in text. Put field-specific feedback adjacent to the relevant input.

Should mobile UX writing use sentence case or title case?

Mobile UX writing should use sentence case for buttons, labels and text fields under Material Design’s writing guidance. Write “Add payment method,” not “Add Payment Method,” while preserving proper nouns and named platform features. Apply the same capitalization pattern across the screen so controls scan as one system.

What belongs in an empty state in an app?

An app empty state should explain why the area has no content and give the user one clear next action. Write it before the populated state so the first-use path is defined rather than treated as leftover UI. Separate a first-use state from no search results, active filters and unavailable content.

Can a microcopy generator replace UX writing review?

A microcopy generator can produce alternatives, but a UX writing review must verify the product state, action outcome, component width and accessibility requirement. Check every generated label against the screen it controls, especially destructive actions and validation errors. The final copy must match what the app actually does after a tap.

Where this leaves you

A good mobile string removes one decision at the moment a user needs to act. The rewritten screen should now show a verb-first outcome on every button, a cause-and-fix sentence for each foreseeable error, and an empty state that explains the first useful action. Keep labels short enough to survive the component’s real width and text scaling, but do not make a destructive or consequential action vague to save characters. Open the screen in an iOS and Android preview now, trigger its empty and error states, and replace every remaining “OK,” “Submit,” and “Something went wrong.”

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

•Color Picker from Image — Pull a palette out of any image, assign it to screen roles, and export it as tokens or native code.
•Aspect Ratio Calculator — Work out the missing width or height for any ratio, with the common phone and store ratios one click away.
•Type Scale Generator for Mobile Screens — Create a type scale generator workflow for iOS and Android: choose a base, calculate six r
•Font Pairing Tool: Pair Fonts for Mobile Apps — Use a font pairing tool to select two mobile app fonts, test 13pt text on iOS and Android,
•Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery