글쓰기에서 작은 변화로 큰 영향 미치기

Hi, I'm Liv Huntley.

And I’m Jennifer Bush. We’re UX Writers here at Apple. And when we’re asked about how to improve the writing in apps, the advice we give most often is to simplify.

While you’re thinking about how Apple’s new design system will affect the look and feel of your app, it’s a perfect time to also consider the writing.

In this session, we’ll help you get started with four small writing changes you can make that will have a big impact on your app. Liv will get us started.

First I’ll cover one of the most common pitfalls I see in apps: adding too many filler words, and how to tighten up your writing by removing those unnecessary adverbs, adjectives, interjections, and pleasantries.

Then I’ll talk about avoiding repetition, and how to cut redundant phrases and ideas to help you clearly deliver your message.

Later, Jen will show you how to lead with the why by doing some hands-on editing to give your sentences more impact.

And she’ll conclude by talking about how a word list makes it easy to keep consistency in your app.

I'll start by talking about filler words. A common misconception in UX writing is that we need to fill all the empty space. Think about it this way. Remember when you were a kid in school and you had to write a thousand word essay? You’d make sure that essay was very, extra, overly descriptive. Fortunately, your app doesn’t have a minimum word count. In fact, usually the opposite is true and it's best to remove words. I’ll show you some of the most common types of fillers, starting with adverbs and adjectives.

Adverbs are words that describe actions like “easily” and “quickly”. And adjectives describe nouns. Those include words like “fast” and “simple”. Of course, there are many more, and when you notice words like these, it’s worth a pause to see if they’re needed. I'll give you an example.

I was recently on vacation and parked my rental car in a garage that required an app to pay. I didn’t have the app, so I had to walk toward the exit where I’d have enough cellular signal to download it. Once I did, I saw this message inside the app.

“Simply enter your license plate number to quickly pay for parking.” But I was in a rental car and I didn’t know the license plate number, so I had to walk back to the car to get the number. And because I didn’t have any signal, I had to walk back up to the exit before I could pay. It wasn't that simple or quick after all.

If I remove the words “simply” and “quickly” from this message, It now says, “Enter your license plate number to pay for parking.” I haven't lost any clarity, and I don’t make assumptions about the context of the person using it.

The final message is very similar to the one I started with, but the small change of removing those unnecessary descriptive words makes the message more impactful.

Of course there are times when using some descriptive text can be useful. Consider an example of an app that connects to a pet food dispenser. You can use the app to feed your pets automatically.

When describing this app, I might write a sentence like this: “Feed your pets when you’re away.” But that leaves out a key feature that sets this app apart: the convenience of being able to automatically feed them every day according to a schedule.

By adding the word “automatically” to the sentence, I can clarify the behavior so people understand how the app works.

When you're writing for your app, resist the urge to fill space by saying too much. If you see descriptive language in your app, pause and ask yourself: Does each word add value? I find that more often than not, those adverbs and adjectives are used as fillers and can be removed.

Two more types of fillers are interjections and pleasantries. Interjections are abrupt words or phrases like “oops,” “oh no,” and “hooray.” These are remarks used in polite conversation like "sorry," "thank you," and "please." While it might seem like these words make your app feel more personal, it’s best to remove them when they don’t add any meaning to the message. Let’s look at an example using these types of fillers.

In this example, someone is waiting for a delivery and they get a notification. The headline says, “Uh oh. We’re running late,” and the rest of the message says, “We’re sorry, your delivery driver won’t make it on time. They’ll be there in 10 short minutes! Check the app for your driver’s location.” To improve this message, I’ll look at the fillers.

First, I see the word “uh oh” in the headline. Words like “uh oh, “oops” or “oh no!” in error messages can make it sound like you’re not taking the problem seriously.

In the main body of the message, the words “We’re sorry” aren’t necessary. When something doesn’t go smoothly, of course we’re inclined to apologize, but in an alert like this, it sounds insincere and takes away from the primary purpose of the message. The body also mentions “10 short minutes!” While 10 minutes may not seem like a very long time, for the person waiting for the delivery, it might be critical, and the exclamation point further makes light of the situation. Try to avoid unnecessary punctuation disguised as a kind of filler.

Here I’ve taken out those filler words and already the message is much improved. “We’re running late. Your delivery driver won’t make it on time. They’ll be there in 10 minutes. Check the app for your driver’s location.” I see a few more things I might edit on this message, but before I do that, I want to tell you about another small writing change.

Avoid repetition. Repetitive language in your app is also a form of filler. Resist the urge to fill empty space by saying the same thing in different ways. I’ll go back to the previous example of an alert about a delivery driver running late. The headline “We’re running late” says basically the same thing as “Your delivery driver won’t make it on time” and the new time of arrival “in 10 minutes.” I can combine those thoughts by changing the headline to “Delivery delayed 10 minutes.” In one sentence, I explain both that there was a delay and by how much.

I can keep the rest of the message as “Check the app for your driver’s location.” The final alert is not all that different from the one we started with. But by removing repetition, I was able to simplify quite a bit, and it only took a minute or so to do. UX writing is all about economy of language. Resist the urge to fill all available space with repeated information.

Another small change you can make I like to call “lead with the why”. Messaging is most effective when you tell the people using your app why taking that next step will be fun, or interesting, or beneficial to them. I'll give you an example. I love crossword puzzles. I do them every day and can be a little competitive. So when I got a notification from Apple News+ Puzzles that said, “Keep your streak going by solving today’s crossword,” I went straight there. One reason this is an effective notification is because it leads with the why.

You can think about this as, “To do or get one thing, first do another thing.” This shortcut applies in a lot of places, but I see it often in error messages, push notifications, or instructional copy, like tips.

Going back to that crossword notification, the “why” in this case is “Keep your streak going.” And you do that by “solving today’s crossword.” I'll show you another example, this time for a fictional restaurant app that lets people get updates about their upcoming reservations. To get those updates, people have to enter their phone number. The first draft of this instructional copy might say something like what I’ve written here: “Enter your phone number to get reservation updates.” That's pretty good. There are clear instructions, and I even included the benefit: to get reservation updates.

But it could be better. All I need to do is take the second part of the sentence, “to get reservation updates”, and move it to the front.

“To get reservation updates, enter your phone number.” Now, the benefit of getting those updates is right at the front of this sentence, where it’s easiest to see and has the most impact. Take a look at the messaging in your app, and if you’re leaving the benefit for the end of the sentence, try moving it to the front. It only takes a moment to do, but really improves the impact of your message.

The last small change is a little different because it’s something you do because it’s something you do outside of your app, making a word list. Once you have one, you use it to give the language in your app more consistency. Think of the words you would use in your app, and the ones you wouldn’t, and write them down. This is a great exercise to do at the start of development, but you can really do this at any stage. Your word list can take any format that works for you, but I find a table works well.

In your first column, you’ll put any words you do plan to use in your app. For example, if I'm working on a game, the first thing players might have to do in that game is choose their in-game name. This game calls that an alias.

I’ll add that to the first column.

Then, in the second column, I’ll put in the words I don’t plan to use to refer to the same thing.

In this case, words like Handle, User Name, and Title.

And if it’s helpful, you can also add a simple definition.

I’ll add one that says “The player’s in-game name, shown to other players, Not used to sign in.” Now, when I need to give an instruction or refer to this name in the app, I know to always call it an “alias” and not something different.

That consistency helps provide clarity for the people using the app.

Similarly, I might add the word “health” and avoid the words “lives”, “hearts”, “energy”, and “stamina” with a definition of “Measure of player longevity.” I’ll keep going in a similar way. Whenever I add a new term or think of one already in the app, I'll add it to the list. As this word list grows, it becomes a resource that anyone working on this app can use to know how it should sound. Don’t let the idea of creating a comprehensive word list overwhelm you. This session is about small changes, so just think about adding a word at a time.

Once you have even a partial word list, you can start to use it for the UX writing in your app.

For example, when someone first sets up the game, the app might tell them: “Choose your alias.” For the description, I was even able to refer to the definition I wrote, that this is the name that is shown to other players.

Similarly, to find someone to play with, I might give the instruction to “Find an alias.” This helps people know they aren’t meant to search for, say, an email address or user name.

Notice also I chose the word "find." That’s another word I could add to my word list.

So I'll do that now.

Finally, a player might receive a notification letting them know about a requested “Match-Up”. The message says, “A player with the alias, “ExampleAlias”, wants to play.” Looking at these three examples together, you can see that I was consistent about using the term “alias”. I never called it a “user name” or “player name” or anything else, so people using the app would always know what I was referring to.

If you’re not sure what to use for some of the terms in your app, the Apple Style Guide, available to anyone, is a good place to start.

We’ve talked about four small changes you can make that will have big impact on the writing in your app. Remove fillers, avoid repetition, lead with the why, and make a word list to help with consistency. I'll put it all together.

I recently got some AirPods Pro. And as part of the setup flow, you can take a hearing test.

This intro screen is longer than some of the other types of screens I've talked about today, but the same principles apply.

Notice the headline of this intro screen is “Test Your Hearing.” It doesn’t say “Take a quick and simple hearing test” or "Easily test your hearing." There are no filler words.

The two paragraphs give you reasons to take this test.

First, that “Hearing loss is common and can get worse over time.” And second, that “If you have mild or moderate hearing loss, AirPods Pro can provide hearing assistance.” Both of these paragraphs lead with the why.

The test then proceeds through a series of screens, a couple of which are shown here.

Notice the Next button at the bottom. Using the same button name for the same action, in this case, moving to the next screen, helps build trust through consistency. Button labels are a great thing to add to your word list.

And taking a closer look at just one of these screens, there's also no repetition. The headline gives a clear instruction to “Find a quiet place where you can focus and take the test.” And the description gives new information explaining why that’s important. “Too much background noise can cause inaccurate results in your test.” By applying all four small changes, these screens deliver clear and consistent instructions that make it easier and more enjoyable to move through the experience, keeping you informed and engaged throughout. We hope you find the ideas we’ve given you useful. These small changes have immediate impact on the clarity in your app. With practice, it becomes easier to spot the places in your app’s language that you can simplify. Set aside an hour or two and see how much progress you make.

In previous writing sessions, we have concluded with a piece of advice that I think is worth repeating.

Read your writing out loud. It makes it easier to hear those filler and repetitive words and know where to tighten up your writing.

And if you’re looking for other ways to improve the writing in your app, refer to our previous talks about UX writing. And for more information on how Apple’s new design system might affect the writing in your app, check the Apple Style Guide and our Human Interface Guidelines.

Thanks so much for joining us. Now it’s your turn to put these tools to work. A few small changes can make a big impact in your app, and we can’t wait to see how it all comes together.