How to write mobile content for Android and iOS

Looking for writing guidelines for mobile devices?

With one third of all content now appearing on mobile devices. let’s look at how to develop content that works well on small screens, encourages users to perform tasks, for example, buying something on your website, and also ensures that they come back looking for more!

Let’s start at the top – keep it short. but not too short!

android-content

Concise

  • When writing text that appears on an app or small device, keep it concise, simple, and friendly.
  • Get to the point. Describe only what the user needs to know. Only is the word to watch here. Write only what they need to know. Remove fluff.
  • However, don’t pare down the text so it’s choppy, harsh to read, or if the tone become severe.
  • Give the reader enough information to perform the current task, and then direct them to other screens, if appropriate.

Remove redundant text

  • Eliminate redundancy, such as titles that restate what’s displayed in the body of an information box.
  • Redundant text is often found in instructions. If the page title is: Printing your invoice, you don’t need to add an introductory line that says: To print your invoice, do the following. You can remove this sentence without affecting the procedure.
  • Of course, you could also refine Printing your invoice to Printing Invoices, or even Print Invoice.
  • Get a sense for what feels right.

Short

  • Keep text as short as possible but not so short that the user is left guessing what to do next.
  • Refine the text until it’s clear what options are available to them.
  • There should be no ambiguity. Should I go left or right? Never makes them guess.
  • Highlight the impact of performing specific actions, for example, that they will lose data permanently if they click Delete.

Don’t be Verbose, i.e. long-winded and boring

  • Avoid wordy, stilted text.
  • Don’t try to impress readers with big words. They have a dictionary too.
  • Instead, be precise and helpful

Tone

  • Be friendly.
  • Remember you’re talking to a real person.
  • Be polite, courteous, and helpful.
  • Try to get the balance between being friendly but not too matey.
  • Avoid talking down to them or implying that they should know what to do next.

Orient

  • Help the user understand where they are in the application.
  • Provide snippets of text that help them find their way back and forwards in the app as discretely as possible.

User v You v End User

  • Try not to refer to the user as the user.
  • Remember the person reading your text is a real person holding the device, looking at your app.
  • Your aim is to connect with them though the words. So where possible, use ‘you’ phrasing when discussing the application, how it works, and what they can do if it doesn’t work as they expect.

Write to be helpful

  • The exception is error messages.
  • Here you highlight the issue with the application and deflect any blame or criticism away from the user.
  • The only things worse than an error message is when the error message blames you for something you’ve done.
  • Rephrase the text so the blame is not pointed at the user but the performance of the application.

Examples

Don’t

Consult the documentation that came with your device for further instructions.

Do

Read the Getting Started guide. You can find Help at [your website URL].

Avoid Wordiness

Don’t provide unnecessary information. Look at the following example:

Before

From a Login screen

Signing in…

Your phone is attempting to communicate with our secure servers to sign in to your personal account.

This may take up to five minutes depending on your connection.

After

From a Login screen

Signing in…

Your phone is contacting us.

This can take up to 5 minutes.

Use Active Verbs

Why? Using active verbs makes your content sound sharper, more confident, and it’s easier to read.

Before

The page is printed by clicking the Print button

After

Click the Print button to print the page.

Or you could write:

Click Print to print the page.

Or

Click Print.

Sometimes that’s all you need to say.

Use your judgment. You don’t have to blindly follow writing conventions and industry style guides to the letter. Most users are smart. They know the Print button is a button, so you don’t have to say this. However, if you feel there may be any confusion, you can bold it to make the word stand out. That way you save space and identify what button they need to click.

Note – you can also say Press instead of Click as, if they’re using a tablet, for example, they’ll be pressing with their finger, not using the virtual keyboard.

Sentence Summary

  • Summarize the page into a single sentence.
  • Put this first, then follow with the rest of the content.
  • By summarizing the page first, the user can determine immediately if this is what they’re after.
  • You should also consider frontloading the headlines so the subject matter is highlighted to the indexing agent.
  • Another suggestion is to write using the inverted pyramid style. It’s the format journalists use in newspapers. It works very well on the web and even better on mobile devices where you need to distill information into as few words as possible.

Focus on needs

  • Needs are what the user wants to do right now!
  • Avoid explaining complex subject matter, technical concepts, or subtleties regarding how the technology works. These are above the head of most readers. They have a problem, a pressing need, or some issue they want resolved.
  • Put yourself in their shoes. Keep asking yourself: what’s the one thing they want to achieve on this page?
  • Focus on what they’re trying to achieve. Help them get there.

Don’t

Manually control GPS to prevent other apps from using it

Do

To save power, switch Location mode to Battery saving

Put the user’s goal first

Don’t

Touch Next to complete setup using a Wi-Fi connection

Do

To finish setup using Wi-Fi, touch Next

It’s ok to use contractions

  • Talk directly to the reader. Use “you” to refer to the reader.
  • Keep your tone casual and conversational, but avoid slang.
  • Avoid being confusing or annoying

Don’t

Sorry!

Activity MyAppActivity (in application MyApp) is not responding

Do

MyApp isn’t responding

Do you want to close it?

Some Words to avoid

Instead of

one, two, three, four, …

Use

1, 2, 3, 4, …

 

Instead of

Application

Use

app

 

Instead of

cannot, could not, do not, did not will not, you will

Use contractions:

can’t, couldn’t, don’t, didn’t won’t, you’ll, and so on

 

Instead of

okay, ok

Use

OK

 

Instead of

please, sorry, thank you

Attempts at politeness can annoy the user, especially in messages that say something has gone wrong.

Exception: In Japanese, “please” is mandatory and imperative verbs should be localized accordingly (turn on -> please turn on).

 

Instead of

there is, there are, it is

Use a noun as the subject

 

Instead of

abort, kill, terminate

Use

stop, cancel, end, exit

fail, failed, negative language

Use

In general, use positive phrasing

For example, ‘do” rather than ‘don’t.” Exceptions are ‘Don’t show again,” ‘Can’t connect,” and so on.

 

Instead of

me, I, my, mine

Use

you, your, yours

 

Instead of

Warning!

Use

Highlight the consequences, for example, ‘You’ll lose all photos and music”

Capitalization

Use sentence-style capitalization for all user interface strings: ‘Words to live by.”

Capitalize all important words in:

  • App names (Google Drive)
  • Named features (Android Beam, Face Unlock)
  • Proper nouns (Statue of Liberty, San Francisco Giants)
  • Punctuation

Don’t use a period (fullstop) after a single sentence or phrase used in isolation, such as in a toast, label, or notification.

If two or more sentences run together, use a period for each sentence.

Ellipsis

Use the ellipsis character (…) to indicate that something is

  • Incomplete
  • In progress (‘Downloading…”)
  • For truncated text
  • Menu items (such as Print… or Share…) that lead to further choices.

The exception is commands that imply further but limited actions, such as Pick a date.

Labels

Some guidelines for the Android Developer site:

  • Space is limited. You only get one line, and it’s incredibly short on the smallest of devices.
  • Make labels brief, meaningful, and scannable:
  • Write each label in sentence case (i.e. only the first word and proper nouns are capitalized).
  • Don’t start a label with an instructional verb like “Set”, “Change”, “Edit”, “Modify”, “Manage”, “Use”, “Select”, or “Choose”. Users already understand that they can do these things to settings.
  • Likewise, don’t end a label with a word like “setting” or “settings”. It’s already implied.
  • If the setting is part of a grouping, don’t repeat the word(s) used in the section divider or subscreen title.
  • Avoid starting a label with a negative word like “Don’t” or “Never”. For example, “Don’t allow” could be rephrased to “Block”.
  • Steer clear of technical jargon as much as possible, unless it’s a term widely understood by your target users. Use common verbs and nouns to convey the setting’s purpose rather than its underlying technology.
  • Don’t refer to the user. For example, for a setting allowing the user to turn notifications on or off, label it “Notifications” instead of “Notify me”.

Follow these guidelines to write checkbox setting descriptions:

  • Keep it to one sentence and don’t use ending punctuation.
  • Convey what happens when the setting is checked, phrased in the form of a command. Example: “Allow data exchange”, not “Allows data exchange”.
  • Avoid repetition by choosing words that don’t already appear in the label.
  • Don’t refer to the user unless it’s necessary for understanding the setting.
  • If you must refer to the user, do so in the second person (“you”) rather than the first person (“I”). Android speaks to users, not on behalf of them.

Writing examples

Here are some examples of changes they made to labels and secondary text.

Before

Use tactile feedback

After

Vibrate on touch

In this checkbox setting, we eliminated the throwaway word “Use” and rephrased the label to be more direct and understandable.

Before

Screen timeout

Adjust the delay before the screen automatically turns off

After

Sleep

After 10 minutes of inactivity

In this multiple choice setting, we changed the label to a friendlier term and also replaced the description with status. We put some descriptive words around the selected value, “10 minutes”, because on its own, the meaning could be misinterpreted as “sleep for 10 minutes”.

Before

Change screen lock

Change or disable pattern, PIN, or password security

After

Screen lock

Pattern

This setting navigates to a sequence of subscreens that allow users to choose a type of screen lock and then set it up. We eliminated the throwaway word “Change” in the label, and replaced the description with the current type of screen lock set up by the user. If the user hasn’t set up a screen lock, the secondary text says “None”.

Before

NFC

Use Near Field Communication to read and exchange tags

After

NFC

Allow data exchange when the phone touches another device

In this checkbox setting—although it’s technical jargon—we kept the “NFC” label because: (1) we couldn’t find a clear, concise alternative, and (2) user familiarity with the acronym is expected to increase dramatically in the next couple of years.

We did, however, rewrite the description. It’s far less technical than before and does a better job of conveying how and why you’d use NFC. We didn’t include what the acronym stands for because it doesn’t mean anything to most users and would have taken up a lot of space.

Checklist

  • Make sure each item in Settings meets the criteria for belonging there.
  • If you have more than 7 items, explore ways to group related settings.
  • Use design patterns wherever applicable so users don’t face a learning curve.
  • Choose defaults that are safe, neutral, and fit the majority of users.
  • Give each setting a clear, concise label and use secondary text appropriately.

Controls

Let’s look at how to prepare text for user controls, such as buttons, text boxes, and other parts of the user interface.

The iOS Human Interface Guidelines suggest that we:

Give controls short labels or use well-understood icons. People should be able to tell at a glance what a control doe

Here’s some common controls and the phrasing and terms to use in your technical documents.

Button

You press or click a button to perform an action. Note that while you might click a button on your PC (with your mouse), you will probably press it with your finger on a smartphone. It gets trickier as you can do both on a tablet, such as an iPad. So, there’s no ‘right’ term to use.

Text field

This is a text field you can edit. On a desktop computer you ‘type’ text in a text field. But, if they are using a tablet, it might be more accurate to say Enter as you may not use a keyboard to enter text. Of course, there is a built-in virtual keyboard which you could use. Saying that, Enter is probably the most practical term to use.

  1. Checkbox- an on/off switch that you can toggle. Use checkboxes when presenting users with a group of selectable options that are not mutually exclusive. Note that some style guides write this as two words: check box.
  2. Radio button- similar to checkboxes, except that only one option can be selected.
  3. Toggle button – an on/off button with a light indicator.
  4. Spinner- a drop-down list that allows users to select one value from a set.
  5. Pickers – lets you select a single value for a set by using up/down buttons or via a swipe gesture.
  6. Activity indicator – shows that a task or process is progressing (shown here with text labels).
  7. Info Button – provides configuration details about an app, sometimes on the back of the current view.
  8. Label – displays static text. Use a label to name or describe parts of your UI or to provide short messages to the user. A label is best suited for displaying a relatively small amount of text.
  9. System Button – performs a specific action. When you supply a title for a system button, follow this approach:
  10. Text Field – A text field accepts a single line of user input. Use a text field to get a small amount of information from the user.

Text Field Guidelines

  • Use a verb or verb phrase to describe the action the button performs. An action-specific title shows users that the button is interactive and tells them what will happen when they tap it.
  • In general, use the left end of a text field to indicate its purpose and the right end to indicate the presence of additional features, such as bookmarks.
  • Use title-style capitalization. Capitalize every word except articles, coordinating conjunctions, and prepositions of four or fewer letters.
  • Customize a text field if it helps users understand how they should use it. For example, you can display custom images in the left or right sides of the text field.
  • Avoid long titles. These may be truncated, making it difficult for users to understand its purpose.
  • If appropriate, add a border or background to a button. Also, consider creating a clear call-to-action title, defining a tint, and providing contextual clues. In some content areas, you can bring attention on a button by adding a border or background appearance.

Dialog box phrasing

Use these terms when describing user actions in dialog boxes:

  • Click – you click commands, buttons, option buttons, and options in a list, gallery, or palette.
  • Select and clear – you select and clear check boxes. Not deselect, tick, or untick.
  • Type – use this when you type in the accompanying text box. Use enter if there is no possibility of confusion.
  • Select – use select, for example, when selecting an option from a drop-down list. If you think about it, you don’t click on an item, you click to see the options, then select one.