We are writers. Whether we’re writing for developers or end-users, we’re writing for readers who want to be doing something else. Whether it’s saving a document, watching a movie, playing a game, implementing an API, or saving the world, their experience doesn’t end when they stop reading.
In this article, we introduce the Content Continuum––six reasons people read words written by corporate writers, from our developer documentation to marketing copy or labels in user interfaces. When we start from one of these six reasons, we are able to choose words that feel more trustworthy, are easier to understand, and avoid creating unintentional bad feelings.
Understanding customer intent isn’t new. By putting those intents on a continuum (see Figure 1), we get something different: we find out not just what words to use, but what words to exclude. We get a specific list of what to leave out because it won’t meet our reader’s need.
The Content Continuum shows six reader intents. The first is Study for which we write Documentation. Then Investigate for which we write Explanations. Third is Verify using Reassurance, then Learn How using Instruction. Fifth is Do using Indicators, and finally Be Done for Me for which we write Notifications.
For example, when someone wants to play a game, they primarily need indicators and may need notifications or brief instructions. They don’t need the terminology, explanation, and examples from the other end of the continuum—so we shouldn’t interrupt their game with it!
The reading is not the experience they are looking for. Our readers have some larger purpose in mind. Our job isn’t to enthrall readers with compelling prose, it’s to solve their problem so they can continue with whatever they were doing. It can still be enjoyable, even delightful; but if our writing doesn’t solve their problem and then get out of the way, it’s not doing its job.
Intent 1: They Read to Study, so We Write Documentation
The first technical writing most people read is in school. It’s the language of textbooks and resource manuals. It can be a good starting point to someone new to the subject. Textbooks are generally dense with knowledge, structured around the expert’s deep understanding of the domain.
Experts in a subject seek out documentation when it will help them answer the questions why and what. For example, in software, the reader might be a developer figuring out what methods, APIs, or architectures are available. The documentation won’t help them solve a particular problem, but it should help them understand how to identify categories of problems that might all be solved the same way. Documentation prepares the reader to choose the right strategies to create their own new path forward without reinventing what has come before, yet building on a foundation they know they can trust. To write documentation then, we need to use a structure dictated by the framework of ideas, communicate the ideas precisely, and do it in a way that inspires trust.
We also need terminology. Our brains can latch onto an idea better if we give it a name. Terminology is where a particular word is invested with a very precise idea regardless of what that word means elsewhere. For example, by saying “let’s explore using an affordance,” UX pros can shorthand the conversation of “let’s create a method for the user to navigate or be aware, which could be or include an image, word, movement, sound, haptic response, or other detectable phenomenon.” Using terminology makes it possible for experts to communicate precisely what they mean among themselves and create their own precise processes and mental frameworks to achieve their next solutions.
Intent 2: They Read to Investigate, so We Write to Explain
Investigation is tactical, whereas studying is strategic. For the reader, investigation is about seeking to understand and solve problems with particular solutions and learning the why and wherefore about those solutions (see Figure 2). It’s more in-depth than “how to,” and but less specific than “documentation.” It’s for people faced with several possible solutions where they need to choose the one right for them. People need to know what the solutions could do and get enough information to compare them to each other.
For example, it’s not enough for many gamers to push a few buttons in sequence or use random gear they pick up in a game—they want to know what each button does, where to find good gear, and which tactics to use in battle. The proliferation of dedicated websites for any particular game attest to this need. When gamers want to investigate, they don’t need to know the backstory for every bit of gear, nor do they just want a button sequence. They want to work out the best combination of attributes to be successful in their game. For instance, in World of Warcraft, a gamer might look up which stats to prioritize for a Balance Druid or what the best talents and gear are for a Restoration Shaman.
Given this, Figure 2 shows that our central strategy should be Explanation. To write for people who want to Investigate, we need to zero in on specific solutions and explain them according to the perspective of the person investigating. The important thing is to build trust: what does a trusted explanation sound like in this domain? Even if we, the writers, are subject matter experts, we need to consider avoiding the use of the high-falutin’ framework of ideas we’d use in documentation. Instead, we might use a timeline of the work being investigated or other more tangible or actionable organizational strategies.
Intent 3: They Read to Verify, so We Write to Reassure.
Say someone is worried about their kids’ online behavior. They’ll read blogs, forums, and the marketing promises of products designed to show parents what kids are browsing and searching for. Or when someone is choosing between one computer and another and reading online reviews, they’re trying to make sure—to verify—that they have enough information to make the right decision. In both of these cases, the reader wants confidence that they have the information they need, so it’s our job to reassure them.
For example, Microsoft has known for years that our customers care deeply about how their data is used. That’s why a set of documents were created for Windows 10 that would answer a customer’s questions, broken out by different features (see Figure 3).
People came to the Windows 10 privacy page to verify they’d be okay, so we should have reassured them. Instead, we presented them with a list of more reading to do. Each feature did reassure, but the reader’s core concerns could have been addressed on that landing page. Since then, we’ve updated the Windows 10 and privacy page to address readers’ concerns immediately, and we created additional articles with the examples and promises* that readers are looking for.
On shopping sites, customer and expert reviews perform that “verify” function (see Figure 4). They are precise about what works and doesn’t work for them and that’s exactly why those reviews drive sales. Even less-positive reviews can help build confidence by letting the reader assess whether it will work for them.
*The asterisk rule: Make promises only when they are true and can be stated simply. If a promise is only true when you use a bunch of very specific adjectives or with an asterisk that leads to small print, it’s not going to build confidence.
Intent 4: They Read to Learn How, so We Write to Instruct
The how-to article is what most people are looking for when they look for help. How do I change my password? What ports do I need to open on my router to connect to this service? How do I change the bulb in my car’s dome light? Our readers may look for help before they begin a task or may get stuck and need help. They aren’t here to ponder why, or understand the concepts—they just want to get in, get going, and get out.
Instructions, then, are as brief as possible: include a little context, then provide the shortest path to victory. As Figure 5 shows, give the reader visual markers so they understand where they are and where they are going (labels and images work great for this), and use uniform and concise language to prod them on their way. We’re precise when it comes to describing what they’re seeing and what they need to look for, but not at the expense of helping them to understand what needs to be done.
When we stray into explanations or include various routes to complete the same (or similar) objectives, we’re just keeping them from completing their task. Ask yourself, what is the one thing the reader is trying to do? Beware of trying to address multiple issues at once. This may be necessary in some cases, but the more you ask the reader to make decisions, the less likely they are to be successful.
Intent 5: They Read to Do, so We Write to Indicate
Indicators are the words that help the user do what they want to do as close to the “doing location” as possible. That means the right text, with the right weight, at the right time. For something like saving a document on a PC, it’s a simple “Save” on a menu or toolbar. For hardware, it’s a clear label on a switch or button. In more complex situations, like an error, it’s a prompt to let them know what to do to work through the problem and get on their way.
When we write the UX for a product, we write the voice of that product. We’re defining the conversation: how the product talks to the user and how they can talk back. Social media and other new apps even have personality—even when the app fails, the error message can be clever.
In the case of software user interfaces, it’s often not enough to just write labels and descriptions that show up on the screen. Good user interfaces are about the absence of words as much as they are about the use of right ones. Use the Continuum to help: if a screen needs explanation in-line for the user to continue, that’s an indication that something’s wrong with the user experience. There is some truth to the saying, “words won’t fix your feature.”
Intent 6: They Want it Done for Them, so We Write to Notify
As I type these words, I sometimes see UPLOADING TO ONEDRIVE flicker along the bottom of my screen. It disappears when it’s done. Even though I forget to tell it to save my work it’s doing it for me and letting me know. Auto-save was revolutionary in 1990 and still has things to teach us about content at this end of the Continuum.
Notifications also come in the form of disclosures. When you install a new app on a smartphone (see Figure 6) or sign up for a new service, there’s usually a block of text you must agree to. It carries the weight of legal acceptance and until recently, they mostly went unread. Today, more and more people are reading the privacy disclosures closely.
Here we come back to the Continuum: the reader is trying to get an app installed, not study the intricacies of privacy law. If we use the legal terms from the professional world of privacy we won’t serve the need of this reader. Instead, when someone just wants it done for them, we need to tell them what’s being done using words they’ll understand even if they aren’t experts. Any disclosures or notifications should be based on the most-likely assumptions, on their behalf.
To write for Notification, use only the words necessary, like a verb and a noun or maybe a preposition. Something has already been done for them, or is being done for them, and they’re not being asked to intervene. Note that the auto-save message mentioned earlier didn’t tell me what filename, what folder, what file size, how long it’s been since last saved—there’s a wealth of metadata that’s simply not necessary here. The same is true for most notifications; if there’s no action or decisions for the reader, don’t clutter their experience.
Bottom line: Write What They Need and Leave the Rest Out
This article also falls along the continuum. You’re investigating content strategies, so we’re explaining.
When we write to meet the reader’s intent, even intrinsically difficult topics become more trustworthy and better understood.
