Keep the reader at the center of your writing.

Just as we develop user-centered designs, our communication should place the reader at the center of what we do. Three key ways to apply this is to:

• Lead with the summary and key point you aim to convey
• If you provide context that is not absolutely necessary, place it towards the end
• Provide jumping off points for your reader to save them time

These ideas come from the book Smart Brevity, which covers the mechanics of the concept in great detail, from the structure of a message, the use of axioms to highlight the important details, and how to apply it to various mediums, including presentations. Check out the book to learn more.

My three key lessons from Smart Brevity

I’m striving to apply these three key ways to improve how I write. The overarching aim of each is to put the reader at the center of the message. This makes the writing less about what I want to say and more about what the reader needs to hear and understand on the topic.

First, when I’m writing for others, I pause to make certain I know what it is that they truly need to know about what I’m sharing. I try to boil down the message to the one take-away they need from the message. As shared in Smart Brevity, if you can’t identify the key take-away, how can you expect the reader or listener to? As the writer of the message, I am the expert on what I need to convey; if I can’t convey it succinctly, then have I not done my job. In these cases, I need to put in more work.

Second, I aim to put the key take-away at the top, explain why it matters clearly and providing clear exit points for the reader. With shortening attention spans, it’s important to lead with the important message up front. Additional context can be shared, but it should be at the end, so those who do not need or care about the context can skip it.

Finally, my blog posts now contain a tag line along with the title. While the titles aim to be catchy, the tag line summarizes the key point of the post. This ensures that each post has a tight focus and gives the reader the option to decide if they want to continue or not. For those who skim messages, the headings give them an indication on which areas of the messages they should read and which they can ignore.

Are you writing for you or are you writing for the reader?

In software, we say that software is written once and read many times. As such, we strive and reiterate that software should first be functional and second be readable by the humans who have to maintain the code. Many of a developer have come across poorly written code, cursed at the complexity of it, struggled to identify what it is doing, and then only discover that they wrote the code.

Concurrently, we strive to build and deliver user-centric solutions. These solutions aim to put the user at the forefront of our design, so that we produce solutions people actually want to use, not what we think they would like.

Both of these concepts seem simple; ensure that what we write and build is done for others benefit and needs above our own. Yet the emergence of user-centric design in the last decade and popularization of models, tools, and training programs to teach this style of design show that while the concept is simple simple, it doesn’t mean it’s obvious nor easy to do.

In the book Smart Brevity, the authors identify a similar pattern with communication. When writing a message for others, how often do we consider the needs of the reader when we draft a message? How much time do they have available? What is the bare minimum they need to know about this topic? Why is this message important?

As with any skill, writing reader-centric messages takes time. This post itself went through MANY edits to land at its current state and I’m still questioning the length and brevity of the message. But I believe just as iteration is the key to user-centered design, iteration is a key part of crafting and learning to craft reader-centric messages.