[ 4 ]

Apply UX Text Patterns

Pay attention to the intricate patterns of your existence that you take for granted.

—Doug Dillon, writer

A design pattern is a reusable, common solution to a design problem. The goal of this set of UX text patterns is to establish an easy, recognizable starting place to write consistently high-quality text. They are a tool to quickly and scalably write new UX text based on text patterns that have been successful in the past.

Like other good design patterns, these patterns don’t prescribe the words to use. They also shouldn’t create the impression that the pattern is necessary to solve any particular problem; sometimes, UX text isn’t the appropriate solution at all.

The UX text patterns included here are a basic set that almost every experience must use:

• Titles
• Buttons and other interactive text
• Descriptions
• Empty states
• Labels
• Controls
• Text input fields
• Transitional text
• Confirmation messages
• Notifications
• Errors

For each of the UX text patterns in this chapter, I provide three pieces of critical information: the pattern’s purpose, definition, and use. I also provide examples of each pattern using the book’s example experiences: The Sturgeon Club, ’appee, and TAPP. This way, you can see a variety of text patterns in different voices.

To help keep the examples clear, The Sturgeon Club screens are on the left side, ’appee screens in the middle, and TAPP screens are on the right side of their respective figures. Each experience is shown as a mobile app for illustration purposes, but the same UX text patterns apply to desktop and TV screen experiences.

Let’s begin with the first piece of content encountered in most experiences: the title.

Titles

Purpose: Provide immediate clarity of context and action to be taken.

A title is a label that indicates the top levels of hierarchy in the information architecture. Titles are frequently the first and only text a person reads in an experience. That means that for the person to be successful, the title needs to provide context.

There are at least four good ways to set that context, depending on where it occurs in the experience. Here are the four kinds of title I describe:

• Brand name
• Content name
• Ambiguous task
• Single task

Brand-Name Title

At moments in the experience that define the brand, the context to set is the experience itself. Use the name of the experience to set that context, as a brand-name title.

For example, the main screen of The Sturgeon Club uses the club monogram and name as the brand-name title (Figure 4-1). This is the screen each member of The Sturgeon Club experience would encounter most often, and it should convey the recognizable brand.

Figure 4-1

Brand-name titles on the main screen of The Sturgeon Club experience.

Many apps use the very top of the screen for a title relevant to the screen, but not The Sturgeon Club. Part of what the club provides for its members is the feeling of belonging to the club itself, so The Sturgeon Club has committed to having a persistent monogram, its brand, acting as a title for every screen.

On the body of the screen, The Sturgeon Club reinforces the information hierarchy with a second brand-name title. By including both titles on the main page, the experience subtly sets the expectation that each screen will set its own context within the page.

Content-Name Title

When a screen is based on content, such as a blog post, social media post, or image, the screen might use a title based on that content: the content-name title. These content name titles can be specified by the person who created the content, like the publisher of a blog, or it can be generated from the content itself, like the titles generated for single posts on social media.

For example, ’appee uses the name of the challenge as the title for every image submitted for that challenge. For the ’appee screen that shows the Grand Prize winner for the Bluster challenge, the appropriate title is “Bluster” (Figure 4-2).

Figure 4-2

’appee uses the name of the challenge as the title for every image submitted for that challenge. In this figure, the winner for the Bluster challenge has the content name title “Bluster” in the app bar.

Ambiguous-Tasks Title

On screens with multiple potential actions that the person can take, like a dashboard view of a person’s account, it’s helpful to use a title that covers the entire set of ambiguous tasks.

For these ambiguous-tasks titles, use a noun or noun phrase that names the person’s context, or a verb phrase that indicates the relevant category of actions that they can take. The title can reassure the person that they are in the right place to accomplish their goal, even though the experience doesn’t know which goal the person has in mind.

For example, there are many possible reasons a player might view their own profile screen in the ’appee experience. The person might want to browse their past photos, review their stats, or update their profile photo or other details. Therefore, the title (Figure 4-3) is the descriptive phrase “how you look.” Because the person could have more than one account, it’s also important to indicate who “you” is. ’appee solves that problem by using a content-name title on the screen.

Figure 4-3

When ’appee player Jemidux opens their profile in the ’appee experience, they encounter the ambiguous-tasks title “how you look” and their player name as the content-name title of the screen.

Single-Task Title

Single-task titles act as instructions for the person to take an action. Use an imperative verb phrase as a direction to reinforce the correct action.

For example, in Figure 4-4, the TAPP experience displays the code a person must scan when they get on the bus, to pay for their ride. The TAPP experience uses the single-task title “Pay Fare.” There is no button to use to take that action; the person must take the next action using the code-reader on the bus.

Figure 4-4

The Pay Fare screen in the TAPP experience has a single-task title in the app bar.

Titles, however they are used, are just the starting place. The real action takes place when people interact with the text by tapping, clicking, or otherwise selecting it.

As the single-task title demonstrates, the title’s main purpose is frequently to introduce the action that the person can take. Most of the time, they will take that action by using a button.

Buttons, Links, and Other Commands

Purpose: Allow the person to advance toward or commit to action.

Buttons and other interactive text are any text that a person interacts with by tapping, clicking, or speaking to get to their next step. Sometimes they are called links, calls to action, or commands, but whether they are performing an action, taking the person to the next screen, or navigating elsewhere, we will consider them together in this pattern.

Buttons are some of the most important text in an experience. They are how the person makes their purpose known. Buttons (and to a limited extent, controls) are how people “speak” to the experience. The button must be used to enable the conversation between the person and the experience. Almost every other piece of text, from title, description, empty state, label, confirmation, error, and more, is the experience speaking to the person.

The challenge of buttons is that they work best when they are recognizable, specific, and only one or two words long. In experiences I have tested, buttons that are one or two words long were more frequently used than any buttons longer than two words. Similarly, buttons that used a word that the person would actually say in a conversation outperformed generic buttons and buttons with words the person wouldn’t have chosen.

For example, when someone wants to review and pay their club charges in The Sturgeon Club, they encounter the Folio screen (Figure 4-5). The button “Pay $308.48” is the button most important to the club because this is its revenue stream. The text is a clear verb-first indicator of action. Putting the amount to pay on the same button makes it even more specific. Because the member already has a payment method registered in the experience, the payment can be completed with this single, seamless action.

There are two other options available to The Sturgeon Club member: the verb-first command of Change Payment Method, and the back arrow. The order of the buttons is important: just like they would be in a conversation, the most common or primary action would be brought up first.

Figure 4-5

When reviewing and paying their charges in The Sturgeon Club, the person can use either the button Pay $308.48 or the button Change Payment Method, or use the Back button to leave this screen.

Sometimes, icons are used without words. Using an icon can also help reduce the number of words visible on screen. The Back button appears without words, but screen readers used by people with low vision or blindness will speak the availability of that button. In general, the same rules apply to these unseen words: the button will perform best if it maximizes clarity, is one or two words, and uses the same words the person would use in conversation.

Another type of button is an option in a menu or list. For these buttons, nouns are sometimes more appropriate. For example, the ’appee menu gives the player access to the images they saved, their friends, the settings for the experience, and help (Figure 4-6).

Figure 4-6

The ’appee menu is the way to access the player’s saves, friends, settings, and help, which are examples of noun-based buttons in a menu or list.

Each menu item can be considered as its own button, but they all need to be designed in context, the way they will be used. This way, the words can be selected to differ widely from one another so that they are easy to disambiguate. They can also be selected to make sense as a set of options, together. As ’appee shows, using only one or two words for each button enables the player to scan the options at a glance. This design consideration will make it easier for people to choose the right option, the first time, every time.

When paired with single-action titles, buttons are most effective when they match the words in the title. For example, when a person needs to create an account in TAPP, they encounter the title “Create an Account” (Figure 4-7). The button that lets the person take that action, labeled “Create Account,” matches the title. Because these two phrases match so closely, there is no ambiguity: the person is committing the single action specified by the title. If the button said “Save” or “Submit,” it would be less clear to the person that they were taking the intended action.

Figure 4-7

When someone needs to create a new account in TAPP, the title “Create an Account” intentionally matches the button “Create Account.” That symmetry reinforces the action to be taken.

In many cases, the button and title aren’t enough by themselves. The person might need additional information to be successful. They might need a reminder of the value of taking the action, and the space in the title and button is limited. To set expectations about how the experience will behave, or just to reinforce the brand, the experience can use descriptions.

Descriptions

Purpose: Help people move forward in the experience knowing what to expect, establish the brand, and reduce liability.

A description is an informational chunk of text, sometimes called body text. Descriptions can appear as phrases, sentences, or paragraphs. A description can also be hidden text so that screen readers can explain a heavily visual design. Interacting with the description (tapping, clipping, hovering, etc.) has no effect. (When a description has inline links or icons to tap, consider those links or icons as following the Buttons pattern.)

Most descriptive text can meet its purposes only if people read it. Descriptions are frequently ignored. Some designers despise them as “a wall of text.” People don’t come to the experiences to read the UX text.

If description text is necessary, we should make it as easy to use as possible. In English, people using an interface will rapidly scan lines up to about 40 characters wide, which is enough space for about three to six words. Similarly, people’s eyes will linger on a few of the words when a paragraph of text has three lines or fewer. Those few words are the description’s opportunity to catch their attention long enough for understanding to develop.

When a single chunk of text becomes longer than these rough guidelines, people’s eyes stop lingering on the individual words. They begin to feel more doubtful about it. Research participants and teammates will begin to remark about the “wall of text.” Keeping the text brief and separating ideas into scannable chunks makes people feel more confident about their own understanding and capability to use the experience successfully.

Avoid Asterisks (*)

Trust is essential. We reduce trust when we give people beautiful promises and easy paths forward, but take those promises away with asterisks and fine print. When we make clarifications and disclosures difficult to read, we communicate that we’re willing to work to hide things from them. Using asterisks indicates that the main text isn’t fully honest, and can’t be trusted.

If there are complex ideas that must be included while somebody is using the experience, include those ideas in descriptions. Use plain language, and include how it benefits the organization and the person using the experience, as necessary. This usually requires coordinating closely across the product owners, attorneys, privacy professionals, and business owners.

For example, The Sturgeon Club includes a messaging system within its experience, as shown in Figure 4-8. The Sturgeon Club uses a description at the end of the message list that sets expectations for members that the message system is secure, that it works only within the club, and that messages are deleted after 30 days. Although it can be useful information to the member, and certainly useful for The Sturgeon Club to have told them, the member doesn’t need to read the text to successfully use the messaging system.

Figure 4-8

This Sturgeon Club Messages screen has two read and two unread message threads. The description at the bottom of the screen sets member expectations about how the messaging system works and indicates that messages will automatically be deleted after 30 days.

When a player wants to play, ’appee uses descriptive text on its “basic rules” page (Figure 4-9). The person doesn’t need to read the description to be successful, unless they were planning on breaking the rules. The purpose of this descriptive text is to remind the player of the rules and to force acknowledgment of those rules before the person can play. This is a step that ’appee takes to reduce its liability for inappropriate images or claims of unfair votes or decisions.

Figure 4-9

The basic rules screen in ’appee mostly contains descriptive text to set expectations that inappropriate sexual, drug reference, and violent topics are not allowed, that the person can play only once per challenge, and that all votes and decisions are final. This screen mostly exists to protect ’appee from claims that their rules are unavailable or unremembered.

To satisfy people who want all of the rules, who will be reassured by that wall of text, or who need specific information to continue, ’appee includes an “all rules” button. This is one way to include additional information as an option instead of as a requirement to continue.

TAPP uses descriptive text in the first screen in the “Buy Fare” process (Figure 4-10). The screen includes various passes that can be purchased by the person currently signed in, but if the person is eligible for a reduced fare, the description provides a different path forward. The rider can continue and purchase at regular price, but if they read the description, and they are eligible, they can take the steps described to get the reduced fare.

Figure 4-10

The first screen to buy bus fare in the TAPP experience. The description tells people that to purchase a reduced fare, they can sign in with a “validated account” or go to the physical location of the TAPP service center.

This description might feel incomplete. For example, there is no information about what a reduced fare is, or what a validated account is, or how one might know whether they qualify. To keep the text brief, scannable, and on point, that information must be optionally available. The job of this screen is to allow the rider to purchase a fare, not to become informed about the fare. The TAPP experience must provide enough information elsewhere in the experience for people to make that choice.

One of the most elegant places for titles, descriptions, and buttons to work together is in an “empty state” in the experience. When the expected action or content isn’t available to the person, the experience can feel empty. Let’s examine this special case of titles, descriptions, and buttons next.

Empty States

Purpose: To set expectation and build excitement while indicating that the empty space is intentional.

In my experience, teams tend to start by designing the optimal case: a person is fully engaged in the experience, using it to its best potential. When that experience is designed to highlight the things the person has already done, the same experience can feel pretty empty when the person first opens it. UX writers can use empty-state text to indicate that the emptiness is not a mistake.

Empty-state text can be as simple as a single line of text, or as complex as a title, description, and button. In the simplest case, using the format “To do X, do Y” will efficiently move people forward while emphasizing the function available (X) and the action to take (Y).

For example, when a member isn’t signed in to The Sturgeon Club, no other action can be taken (Figure 4-11). The only way forward is to sign in. Even the menu is emptied to prevent people from taking any action. The empty-state text in the menu, therefore, helps members move forward: “To access your membership, sign in.” The “sign in” portion is interactive text that will begin the sign-in experience.

Figure 4-11

When nobody is signed in to The Sturgeon Club, empty state text directs people to sign in.

In some empty-state conditions, there is nothing the person can do to fill it. In ’appee, if you open another person’s profile and that other person has never submitted an image, there are no images to display. For example, the profile page for goldilox has no images to display because they’ve never submitted an image (Figure 4-12). The text tells the viewer “when goldilox plays, see their entries here.”

Figure 4-12

The view of a person’s profile in ’appee usually displays the images they have entered for different challenges. When that person hasn’t entered any images, other people viewing their page will understand how that space would be filled.

Empty states can get more complicated. For example, it might be impossible to give the person a one-step action to take, but they might be very interested in filling it. In TAPP, it’s very handy to save a commonly used bus route. But before any bus routes are saved, the screen has no information to show (Figure 4-13).

Instead of displaying simply “No routes saved,” TAPP uses the opportunity to educate the person about how to save those routes. The empty state provides the instruction “To save a route, tap Save when you find the route you want.” Then, it provides a button to find a route. Together, the instructions and the action move the person toward successfully saving a route.

Figure 4-13

When no routes are saved, TAPP instructs the person on how to save a route. Then, it provides them a way to take the first step in following those instructions: finding a route.

Descriptions, buttons, and titles are great tools for empty states. But when the experience is the opposite of empty—when it’s full of rich detail—we need a specialized form of description: labels.

Labels

Purpose: Minimize the effort required to understand the experience.

Labels are noun phrases and adjectives that name or describe things. They are used to indicate sections, categories, status, progress, quantity, or unit. Labels are ubiquitous where there is a lot of detail to convey, because they communicate a lot of information in a compact, no-nonsense format. But even labels deserve attention: they still need to be chosen, align to voice, and be translated and/or internationalized.

The difference between a description and a label, in these text patterns, is a matter of length and purpose. Descriptions are usually full sentences, regardless of punctuation. Labels are usually single nouns or noun pairs. Descriptions are frequently used with titles, buttons, or whole experiences. Labels are usually related to passive screen elements like icons or sections and limited to that local context.

To meet their purpose, labels must use specific terms and avoid unfamiliar jargon. If vague terms are used, or jargon that the person doesn’t understand, the labels can increase the effort to understand the experience. Labels are an important place to use usability testing and other user research to uncover the words a person would naturally use for these labels. The words that are already in their brain will be the easiest ones for people to read and understand.

Labels are frequently complicated by including dynamic elements. That is, the UX writer won’t know what the cost of an item might be, nor the date, nor the number of “Likes” a social media post might garner. To be successful, the writer will need to know the variables they are working with and choose words that will work with all possible values of those variables.

For example, on the Folio screen of The Sturgeon Club, the labels include the date label, section labels, the monetary labels that indicate the cost of each item, and the text label “No Charge” (Figure 4-14). When this Folio experience is created, the date label could be written as: “Prepared {date}”, where {date} represents the date that the folio was prepared for the club member. The format of the date needs to be further specified as the name of the month, then the number of the day, then a comma, and then the year. It’s often up to the UX writer to specify that date format, in partnership with design and engineering.

Engineers should use existing code libraries, when available, for number formats like dates and money, but those labels should be checked. For The Sturgeon Club Folio, the decision had to be made to use a minus sign, instead of putting the dollar amount in parentheses. Perhaps members were asked, in a research scenario, how they would expect adjustments or payments to be indicated. The Sturgeon Club charges in US dollars exclusively, so it makes sense to use “$” and “.” to separate dollars and cents, but an experience also available in Europe would need to consider how it would use “¤” and “,” to correctly represent the numbers.

Figure 4-14

The Sturgeon Club Folio screen, which uses labels to indicate date, sections, currency and quantity of money, and when there is no charge.

In the ’appee experience, when a person views an image, they can also see several labels that show statistics about that image (Figure 4-15). A row of icons acts as buttons, even though no visible button text is provided. This is usable only if the icons are instantly recognizable, but it is aligned with ’appee’s voice of using fewer words than strictly necessary. Instead, the labels provide context: the person can see (or hear, using a screen reader) that more than 12,000 other people have left comments, 593 people have made purchases related to this image, more than 102,000 people have “liked” the image, and more than 382,000 people have saved it. The ’appee decision to use a lowercase “k+” to indicate “more than … thousand” is another reflection of its voice to use sentence case when providing insights.

Figure 4-15

Labels on the ’appee view image screen indicate the quantity of comments, purchases, likes, saves, and winnings of the image and differentiate between the player and challenge.

The ’appee labels “by” and “for,” which indicate the artist and challenge, respectively, are in danger of not localizing well, because not every language uses prepositions the way English does. The content creator should work with their internationalization expert and designer to create alternate layouts, in case longer words are needed to convey the same meaning in other languages. For example, the alternate label “artist” or “player” could be used instead of “by,” if it could be placed vertically above the player’s name.

When a rider is buying bus fare in the TAPP experience, there is space designed to include localizable progress labels (Figure 4-16). The labels indicate the name of the steps to be taken, and after the step is taken, it changes to reflect the choice made.

Labels are a specialized form of description, in that they tend to be briefer and more technical, but they are still distinct from buttons because people merely read them. Now let’s go one level deeper into specialization: the unique names and statuses for controls.

Figure 4-16

The second step of buying bus fare in the TAPP experience. The icons and labels work together to indicate which decisions have been made and which steps will be taken next.

Controls

Purpose: Inform people of the extent and state of possible customizations.

To write for controls, I find it helpful to acknowledge that any of our controls use as their core metaphor the analog dials, switches, sliders, and indicator buttons of early electronics and mechanical devices. In most meaningful ways, the use of the physical and software switches is the same. At its best, the categories and labels make the possible range of customization clear.

There are usually at least two pieces of text to consider for any particular control: name and state. The name should be the noun or verb phrase that names or describes the control in a way the person using the experience will recognize. The state of the control is, for example, whether a checkbox is checked, the position of a slider, or whether a toggle is flipped left, right, up, or down.

The UX text that is paired with the control needs to match the possible states of the control. For example, a checkbox indicates the affirmative when checked, and the negative when not checked. If we don’t choose a name that has a clear meaning in the affirmative and in the negative, it won’t work with its checkbox.

The setting state text can be visible or invisible, but a screen reader will still read it out loud. Checkboxes will be read as “checked” or “unchecked.” Toggle switches have implied states of on or off, but might be labeled with a similarly opposite pair of states: Red/Green (with differentiation for people who are red/green colorblind), Enable/Disable, or other. Sliders and dials can use state text to establish the endpoints of the range, or use the implied text of Maximum and Minimum.

We also need to consider grouping controls together in a list. The Settings page from The Sturgeon Club demonstrates how much work a group name does to set context for the controls (Figure 4-17). Each control could be listed separately: “Show Today’s Events on home screen,” “Show New Messages on home screen,” and so on. But grouping them together makes the whole list easier to understand, with less reading. This parallel construction makes it easier for the reader to understand not only each list item, but also how the whole set of items works together.

Figure 4-17

The Sturgeon Club settings allow members to switch notifications on or off by type. They can also choose which kind of content to show on their view of the home screen.

Another consideration for the name of a control is how the person will be directed to it when they need help. For this reason, having a unique name for each control can be important, even if those controls appear in different sections of the same page. Category names can be verb phrases, like “Show on home screen” in The Sturgeon Club, and they can be noun phrases, like “Account” and “Notifications” on the TAPP settings page (Figure 4-18).

Figure 4-18

TAPP uses parallel construction at the category level, with nouns “Account” and “Notifications” setting context for those sections. The control names in the Account category are verb phrases that are related to the person’s account. In Notifications, each control is named with a descriptive phrase.

The usability of the control depends on the person recognizing the purpose of the control and understanding how that matches to their own needs. Similarly, people need to recognize what kind of text to enter in text input fields, whether it’s there for a message, number, password, or other kind of text. Next, we examine text field labels, hint text, and default text.

Text Input Fields

Purpose: Help people enter accurate information.

Form fields use UX text as labels, hints, and prefilled text for entering text, email addresses, numbers, dates, and other information.

The best way to help people enter accurate information is to prefill the text field with correct information. Using that information to prefill the text field will save the person time and give them the opportunity to correct it. But this works only if the experience already knows that information and knows that it is very likely to be correct.

When we can’t prefill the text field, we use labels outside of the text field as well as hints within the text fields to indicate what content the person should enter.

With hint text, we need to be careful. Some research indicates that people can interpret hints as prefilled text. When we do decide to offer hint text, the label and hint can work together to provide more guidance than either one could provide separately.

For either the label or hint text, there are four good options for the text:

• Name of the information to be entered
• Example of the information to be entered
• Verb-first instructions about entering information
• Guidance for how the person can be successful

Using these options consistently can help build a person’s confidence that they are entering text correctly. But even more important than consistency is clarity. If you can make the path forward clearer and make people more successful, it’s better to use inconsistent options for the UX text pattern on the same screen.

For example, the Change Password overlay in The Sturgeon Club experience contains a New Password entry field (Figure 4-19). The hint provides guidance of what will work in that field: “At least 8 numbers or letters.” In the same screen, the other two text fields have their own pair of label and hint designed to support the success of the member.

Figure 4-19

For The Sturgeon Club, when a person wants to change their password, they need to enter their current password, then their new password, and then their new password again to confirm it. The design uses pairs of labels and hints to help the member change their password successfully.

In some cases, a team might choose to use only hint text and avoid using labels. In many cases, this can help the design “look clean” and minimal. In those cases, the hint text must do all of the work of informing the person what text they should enter. When the person begins to enter information, there will be no label for the text box, so it’s not a design pattern that maximizes usability.

For example, signing in to ’appee requires the person to use their phone or email address and their password (Figure 4-20). The hints are the names of the information to be entered: “email or phone” and “password.” ’appee relies on the player’s recognition of this common pattern to successfully sign in.

Figure 4-20

The ’appee sign-in screen uses the names of the information to be entered (email or phone along with password) in its two text fields. Note that ’appee is making a decision that is counter to best practices for usability: when the person begins entering information, there is no label to indicate what should go in either input field.

The Request Help screen in the TAPP experience provides an example for default text field entries (Figure 4-21). TAPP has an email address for this signed-in TAPP rider, so their email address is entered for them by default when they come to the page. The person might enter a different email address, but they don’t need to.

Figure 4-21

On the Request Help screen in TAPP, the email or phone number associated with their TAPP account appears in the text field by default.

When a person has successfully used a set of text fields, there’s often a pause while the system transmits and/or validates those inputs. That pause can be stressful for the person, especially if the information they entered is sensitive, like a credit card number, or complex like an online job application, or emotionally fraught such as a message sent to a romantic interest. A kind, easy step for the experience to take is to make that pause visible. Although a spinner or other animation is usually enough for a person with full vision, we can provide text on the screen or for the screen reader to help with that transition.

Transitional Text

Purpose: Confirm that an action is happening.

When an experience “hangs,” or is delayed while an action is processed, it’s courteous to inform the person that their waiting is not in vain. Just as a person at a help counter will say, “Just a moment while I get that from the back,” a digital experience can use transitional text to indicate that it has received a request, and the person will need to wait for a moment.

In general, transitional text shouldn’t require any additional action or taps from the person. If the action is in progress, use the present continuous tense of the verb, like “is uploading” or “are sending.” Ellipses help to indicate that the delay will be brief.

For example, after a person updates their payment method in The Sturgeon Club, they get an overlay message that the updating continues (Figure 4-22). They can feel confident that they have done what they intended to do, and that if they wait, the process will complete. Showing this message also prevents the club member from using the old payment method accidentally before the process is complete.

Figure 4-22

Transitional text in The Sturgeon Club helps build the club member’s confidence that they have successfully done their part to update their payment information, while setting the expectation that the process of updating will be complete in a few moments.

If it’s appropriate in the experience, a sense of excitement can be heightened by a delay. In ’appee, it can take a few moments between when a person agrees to the rules and when the current challenge is retrieved from the service. That delay can even be extended to build anticipation further to ensure that even if the database responds quickly, the player has a few moments for anticipation to build. The transitional text in Figure 4-23 emphasizes that the challenge is being prepared, and that there’s “no turning back now.”

Figure 4-23

When a player agrees to the rules, there is a delay while ’appee retrieves the current challenge and registers this person for this challenge. The transitional text helps to build excitement with the phrase “no turning back now ~,” even as it confirms that progress is happening with the more common phrase “getting ready ~.”

Generic verbs like “getting” work well for many ambiguous circumstances, but in most cases, specific words work better. When a rider taps a “Map” button for a particular route, they expect a map of the route and possibly details about its closest stop. When TAPP experiences a delay in retrieving those details, it still responds to the “Map” button the person used in the transition text (Figure 4-24).

Figure 4-24

When TAPP has a delay retrieving route map and data, it displays the transitional text “Mapping Route {number}...” to build confidence that it is working on performing the action that the person requested.

After the transitional text, the changing of the experience can be its own confirmation. In the example in Figure 4-24, when the map appears, the transition clearly is complete. But when the effect is more subtle, it’s a good idea to provide a confirmation message.

Confirmation Messages

Purpose: Reassure the person that the progress or results they expect are complete.

Confirmation messages reassure the person that otherwise invisible processes are complete. These are especially useful when the result of an action is delayed. These confirmations can appear passively in the experience while the person continues forward, or they can appear in sequence in the experience as a momentary pause or step.

The basic pattern for confirmation messages is to use the past tense of the verb or verb phrase that best describes the action. In English, using one verb in the present continuous tense for transition (submitting), and the same verb with the past tense for the confirmation (submitted) can provide a sense of completion. Similar verb pairs include sending/sent, removing/removed, deleting/deleted, and posting/posted.

Confirmation messages allow the experience to continue while other systems work. For example, The Sturgeon Club provides the transitional text “Saving…” while a person is entering text, and the confirmation “Draft Saved” when a person pauses as they enter a message in the secure messaging system (Figure 4-25). Similar messages can be seen in Google Docs and Microsoft Word Online when the document is being saved online in real time.

Figure 4-25

When someone is composing a message in The Sturgeon Club and then pauses, a message of “Draft Saved” appears to confirm that their message is saved as a draft.

The confirmation text can be a single word when the context and action to be completed is the person’s sole focus. When a person submits an image to ’appee, the transition text “submitting your entry ~” is replaced by the single word “submitted!” (Figure 4-26).

Figure 4-26

After a player submits an entry for an ’appee challenge, “submitted!” appears to confirm the image has been safely sent to the service.

In the case of a long delay, which could be several minutes to several days, providing clarity for the person might avoid additional support or operational costs for the organization. For example, when a person sends a comment and requests a response in TAPP, there can be a delay of up to 10 business days before TAPP responds. Therefore, after the person leaves the comment, they get confirmation text of “Comment Sent” and additional information about the expected response time (Figure 4-27).

Figure 4-27

When a person sends a comment to TAPP, they get an immediate message that confirms that the comment was sent and sets expectations that any response should come within 10 business days. Adding a button to close the dialog, instead of having it disappear after some amount of time, requires the person to acknowledge the confirmation.

Confirmation messages are essential tools at the end of some journeys in the experience. But when there is more that the person could be doing or critical information they could act on, we need a special, interrupting kind of message to encourage or engage a person into the experience: notifications.

Notifications

Purpose: Inform or remind a person to engage with the experience.

Notifications interrupt people to get them to pay attention to a part of the experience that they aren’t paying attention to at the moment. They are reminders or information that should always have value and be urgent (or at least time-appropriate) for the person receiving them. Notifications must communicate that value and their timeliness at a glance, and include the first action the person needs to take to realize that value.

People can get notifications on the lock screen of their mobile device, in a notification center, or as a banner. Notifications can be temporary or persistent. There are different controls for these views on mobile devices, desktop and laptop computers, and in browsers and browser extensions. In general, a writer can investigate the variety of ways a notification can be displayed for their experience and should consider if and how the same text might appear in all of them.

A notification is made of at least one but frequently two pieces of text, similar to other title and description patterns. The title can usually begin with the verb that relates to the action they need to take, and convey any information necessary to create success. The description adds “nice to have” information that isn’t necessary to the person’s success.

For example, members of The Sturgeon Club receive a notification when there are new messages waiting for them (Figure 4-28). In the title, the person gets the instruction “View a new message” with the additional information “from a Club Member.” Messages from the concierge would presumably say “View a new message from the Concierge.” Because the club doesn’t want to reveal the contents of the message in a notification, the description could have been omitted, but The Sturgeon Club chooses to emphasize its brand by including “Message details secured within The Sturgeon Club.”

As long as the information is present, there is room for humor and even obfuscation, if it is part of the voice and entices the person to interact. For example, ’appee challenges are time-based, and are not revealed to the player until they commit to play. But ’appee can hint at the challenge to entice the player (Figure 4-29). The essential context is given by the app name that appears with any notification, so the notification is only one piece of text. Using ’appee voice, it’s difficult to understand: “what’s both (a lollipop) and (a rocketship) but never (candy)? new challenge! (alarm clock).”

Figure 4-28

A notification from The Sturgeon Club indicates that the person has a new message from a fellow member of the club.

Figure 4-29

When a new challenge is available in ’appee, players receive a notification designed to pique their curiosity. In this example, emoji are used to create a riddle preceding the key information: “new challenge!”

Sometimes, notifications aren’t enticing or interesting; rather, they are delivering bad news. That bad news should still have intrinsic value to the person. Because notifications are interruptions, even bad news should still be time sensitive and/or time appropriate. For example, when a person has saved a route in TAPP, they will receive notifications when that route is interrupted (Figure 4-30). In this example, the key information is the detour of a route. If the person is trying to ride that route at that moment, the description directs the person to take action: “Tap to find alternate stops.”

Figure 4-30

When detours happen on a particular route, TAPP notifies riders who have saved that route. In this case, the notification indicates the bus route and direction, and that tapping the notification will provide alternate stops.

Notifications are useful to drive engagement, which is a key success metric for most digital experiences. Because it is so useful, it is easy to overuse them, which can lead to people turning off those notifications entirely. Therefore, when planning notifications, plan them as part of the entire experience. For example, the team should consider how many notifications a person could receive in a day and at what times. By providing controls to customize notifications, you enable people to limit the notifications to the ones they are actually interested in.

Many organizations reserve the use of notifications for positive interactions: getting deals in a shopping app, unlocking prizes in a game, receiving messages from friends. But that leaves out an important class of messages that are critical to the brand: errors.

Errors

Purpose: Help people get where they want to go and, if necessary, indicate that there’s a problem getting there the way they intended.

Error conditions are what happens when the person can’t get where they’re going in the experience. Error messages are often the first way we repair the break in the virtuous cycle (Chapter 1, Figure 1-7). Our purpose is to help people move forward, and error conditions are no exception to this rule. When errors occur, text can create detours and provide maps for the person to navigate where they want to go.

Error messages are possibly the most important place in any experience to empathize with the person trying to use the experience, and to maintain the voice. To do this, the UX writer needs to stay focused on helping the person do what they were trying to do. Grammatically, this frequently means using verb-first, brief instructions, the same way titles and descriptions work when there is no error.

To maintain trust, avoid assigning blame to the person. Even if the error is their fault, blame won’t help. When moving forward isn’t possible, make that clear. If an apology is appropriate in the conversation and in the brand, apologize for the delay, loss, inconvenience, or disappointment to the person.

For an experience that people depend on for work—like most people who work in offices, engineers, designers, writers, IT professionals, and more—additional details about the error condition can help. Beyond satisfying their sense of curiosity, we need to satisfy their sense of responsibility. They want to make sure they didn’t do anything wrong and that there is nothing more they could or should do. Giving them more detail will help give them a sense of the circumstances they could use to identify or predict the error in the future.

For general audiences, sometimes called “consumer” audiences, add details or links to more information from errors only if those details will help the person move forward or feel more confident or reassured about the experience, their data, or your organization. Note that everybody, in some aspect of their life, is a member of the general audience—even engineers, designers, and IT pros. The example experiences in this book anticipate general audiences, so these error text patterns do not include professional-level details.

There are three main categories of errors in software experiences, organized by how much they interrupt the person:

• Inline error
• Detour error
• Blocking error

The least intrusive interruption is an inline error, where the person is advised to make a correction before they can move forward. The text can be very short and, in general, can clarify, remind, or instruct an ongoing conversation between the person and the experience instead of stopping their actions.

For example, if someone enters something that isn’t a 10-digit number when signing in to The Sturgeon Club, they receive an error message that instructs them to enter a 10-digit phone number (Figure 4-31). This way, the club can avoid telling the member they did something wrong. They can also satisfy the member’s intent more rapidly if they just instruct them on how to do the right thing.

In cases like these for which the experience is working to validate the contents of the field before continuing, it might seem natural to the engineering team to call any incorrect contents “invalid.” That entry has, after all, failed validation. But most organizations will prefer to avoid such emotionally laden words: people rarely want to be told that they have failed, and it’s rarely the best way to encourage them to move forward. Also consider that “invalid” has been used in the United States to describe people with disabilities and is viewed as an ableist word. When we’re working with words, we are always working with the history of those words. It’s worth the work to provide a positive way forward instead of making people feel bad.

Figure 4-31

When signing in to The Sturgeon Club, if a person doesn’t enter a 10-digit number in the phone number field, they receive instruction about what to enter.

When an experience can’t be corrected inline, we can hang a virtual “detour” or “out of order” sign using error messages. These errors occur when the person can’t get where they want to go in the way they anticipated, but they can still get there.

Detour messages should have the main instruction in the most prominent spot. For a real-life example, when there is construction on a road, the DETOUR signs should be more prominent than the explanation for the detour. In ’appee, when a payment method is declined, the error message provides instruction first, then explanation, and then the single action to take to move forward (Figure 4-32). Following the title and button patterns described earlier, the button matches the words in the title; even if the description is never read, the person can continue and be successful.

Sometimes, the way forward is blocked until the person takes an action that is outside of the scope of the experience. Whether the error is an outage (planned or unplanned) for the entire experience or a missing web address (404 error), make it clear that they’ve reached the end of the road. If possible, specify when or under what conditions the experience will be available again.

Figure 4-32

For whatever reason a payment is declined, ’appee presents a way forward: add a new way to pay. By focusing on the solution, ’appee stays out of the person’s relationship with their financial institution, and helps them complete the task that both the person and ’appee are most interested in.

For example, an experience that relies on an internet connection can’t govern that connection any more than a vending machine can fix bubblegum in its coin slot. In Figure 4-33, the device needs to connect to the internet before a person can use TAPP to buy bus fare or find a route. Therefore, the error is unambiguous, starting with the title, “Connect to the Internet.”

Figure 4-33

When WiFi is turned off, TAPP provides an error message that begins with why they might want to connect and then instructs them on what they will need to do to proceed.

Then, TAPP reinforces the value it could be providing—buying bus fare and finding routes—and repeats what the person needs to do: connect to the internet. This pattern of instruction in the title, then the value, then a repetition of the instruction can support people who are tentative users of the experience.

Summary: Use Patterns as a Place to Start

The UX text patterns in this chapter are supported by the proprietary research I conducted and consumed at Microsoft, Google, and OfferUp while creating experiences for people to use at work and at play.

All of these patterns are models, so like any model, they will be wrong in some circumstances. Just because these patterns have worked for millions of people doesn’t mean that they are the best options in all circumstances. Instead, I hope they provide a guideline to draft usable text. Then, you can edit that text into the best possible options for your experience.