Don’t Make Me Read
Hederis marketing team member Tiffany Watson penned a piece about automobile maintenance, our brains and attention spans in the age of digital reading, and how the Hederis app’s documentation aims to reach both the Jennifers (readers) and the Tiffanys (skimmers) of this world.
Preamble: An Illustrative Story
When my mom bought a new car, the very next day she offered her friend a lift to work. This may appear at first glance like a normal carpool, but oh no — based upon my twenty-seven years of lived experience with my mom, I could see through all that: she was bragging.
Her friend, let’s call her Jennifer, took a great deal of interest not in the car itself, but the car manual, which was stuffed in the glove box and otherwise destined to collect dust. Jennifer spent the entire car ride reading each section and pointing out every new feature, practically training my mom on how to use her own car and stealing any opportunity for bragging.
As a writer, I spend a great deal of time imagining how readers might respond to words, from a single sentence to an entire novel. As an editor, I pretty much do the same. So I can comfortably proclaim that Jennifer is the ideal reader for car manuals based on the mere fact that she actually reads them — she may even be the ideal reader for all manuals (I have even seen her interest piqued by appliance literature).
But the world is not made up of Jennifers. So how do the rest of us read?
Preamble Pt. 2: A Contrasting Illustrative Story
Well, fast-forward seven months and picture this scene:
I am in the car, frantically pressing buttons, trying to see what percentage of oil is left in the engine. A supposedly simple task. Why, then, am I so flustered? Well, you see, I failed to make an appointment with the mechanic for an oil change last month, which I was enlisted to do because my mom was on bed rest after having surgery, but I didn’t make the appointment, because my mom just had surgery, for goodness sakes! I brought all of my emotion, guilt, and desperation into the car with me, which was fueling this frustrated troubleshooting.
An impossible task masquerading as easy.
After incorrectly pressing many buttons and pressing them all again for good measure, I finally leaned over the gears and pulled out the manual, hunted down the maintenance section, and flipped through pages scanning for one word: oil. Once I saw that little oil can icon, I then scanned the images — not bothering with words — and found out which button I had needed — but failed — to press. (This is how I learned I had 60% oil left and could put off my panic for another day, because panic is really reserved for anything below 35%.)
Introduction: Jennifers vs. Tiffanys (or Readers vs. Scanners)
At this point you may be asking yourself, What can this irresponsible, impatient person tell me about writing documentation that I don’t already know?
From what I can tell, most documentation is written for the Jennifers of the world. As I said before, she is the ideal reader: she reads the documentation in advance, cover to cover — not just scanning, but truly reading. However, the odds are that for most people, especially if you find yourself looking at the documentation for something, you’re dealing with less-than-ideal conditions and you don’t have an even-headed Jennifer at the wheel.
Think of the last time you were scanning through documentation. Were you diving into the details so you’d be fully prepared should an issue ever arise, or were you frustrated and looking for a quick solution to your immediate problem?
Were you a Jennifer, or a Tiffany?
I am willing to bet there are many more Tiffanys out there than just me.
It’s a fairly common first name.
In fact it was a very popular name in the late 80s to mid 90s. I am a painfully common archetype among the millennial reading demographic, who for the most part grew up online with different reading conventions than those of earlier generations. Digital reading has changed our reading brains (check out the excellent book Reader, Come Home by Maryanne Wolf for more on this topic).
I am a painfully common archetype among the millennial reading demographic, who for the most part grew up online with different reading conventions than those of earlier generations. Digital reading has changed our reading brains.
With so many Millennial and Gen Z workers entering new or first-time jobs while training remotely during Covid, it’s as good a time as ever to consider how we communicate instructions to people and most importantly think about how they read them…if they do at all.
Part 1: A Dearth of Digital Attention Span
To frame my philosophy about documentation, I’ll start out by referring to a text that I (and a lot of other people) kinda read.
Don’t Make Me Think by Steve Krug was a book I encountered as a graduate student. It outlined the ways in which websites can be designed for optimal usage, and it’s popularity has influenced many digital reading conventions. I dabbled in user testing once and my main task was detailing how many clicks it took to find the answer to a specific question. Find the page on youth programming. Two clicks. Find the page to make a donation. One click. Find the page for the upcoming festival calendar. Three clicks. The quicker a user can find information on your website, the better the user experience.
The same can be applied to digital reading as well: Skimming, scrolling, and keyword searching are all ways we read digitally. For many people who grew up collecting and reading information online this is how they read most information, even in print.
These conventions can be summarized in a title Steve Krug might be a fan of: Don’t Make Me Read.
Think I am wrong?
The average reading time on a previous post I wrote on this here platform is 47 seconds. This could of course just be me (maybe my prose is uninspiring?). However, Jim Woods’ article “How Much Is a Reader’s Time Worth In The Medium Partner Program” is cited as having an average 50 second reading time. A writer with a larger platform writing about an important topic to said platform and still — you spent only 3 seconds more on his article than on mine.
If all of us content creators have less than a minute of your attention, how can I convey important information to you in that short span of time?
Part 2: Do As I Say, Not As I Do
Early on in this article I told you two stories about two different reader experiences with a car manual. The first one illustrates the basis from which most documentation at present is written. We all like to think that someone is taking the time to carefully read each section. We all want Jennifers. The second illustrates how people more commonly use documentation: scanning, skimming, and keywording for a specific solution to their most immediate problem.
If all of us content creators have less than a minute of your attention, how can I convey important information to you in that short span of time?
I used a narrative to direct you to the most important information in this article: the experience of how users “read” documentation. But as a Tiffany through and through, I would have read to the end of that line, got the point I needed, and clicked right out. It would have taken a little more than 47 seconds (I am a slow skimmer!).
However, no one really wants to read a story to learn about how they can find the solution to their problem. Yet, plot is all about progression, we all need to go somewhere even if we are stuck at home. Movement is important to plot, and when you’re looking for answers, you want to move fast (think about how quickly you flew through the pages of The Hunger Games or The Da Vinci Code when you read it for the first time).
Visual elements like headings, bulleted lists, illustrated steps, bold text, and images can move a reader through a document as easily as a plot.
The use of images, keywords, and icons can also help to direct the reader’s gaze to the most important information.
And finally, when it comes to supplying that information, doing it in as short a span of words as possible is ideal.
Part 3: Putting the Philosophy into Practice
At Hederis, we offer a new and innovative book design platform, and many features in our product are unlike anything else available on the market. This means we need to teach our user how to get the most out of the app, and as much as we’d like to be writing for Jennifers, many of our users are stressed-out Tiffanys, with way too many projects on their plates and little time to hunt for answers.
Problems and solutions are abundant in book design, so our documentation is based on specific issues, and we write our explanations with quick steps to the solutions in mind. Take hanging indents, a common feature in books that is addressed with hackneyed solutions in most design software.
“Hanging indents” are something most book publishers have some familiarity with (making for a highly scannable keyword that we can use in our documentation table of contents). Hanging indents are a design convention applied to certain kinds of paragraphs; you are probably familiar with them from bibliographies (I am sure if you are this far into the article you have at least glanced at a bibliography in the past). The first sentence is always unindented, but the following ones are indented so they appear to hang from the first line (get it?).
To create this type of paragraph style in Hederis, you click on a paragraph, restrict the edits as needed (Only this paragraph? All paragraphs like this? Paragraphs like this that follow a heading? etc…), then toggle the margin to your heart’s content.
Three easy steps.
When it came to documenting this feature, we framed it within these three easy steps and wrote them out in a numbered list, with each list item accompanied by an image that users can quickly scan.
These images show users exactly what their screen will look like at each step of the process, so whether you read the section or scan the images, you still come to the same solution, which is what we all really want; both Jennifers and Tiffanys can rejoice.
Conclusion (Scanners, Stop Here!)
So to wrap this all up in a bow (and to give all the Tiffany’s of the world some obvious highlights to scroll for), here’s a quick summary of Tiffany’s documentation philosophy:
- Documentation needs to be written in a problem-to-solution-based formula. Describe the problem with keywords that the reader can latch onto, and move them to the solution as quickly as possible via the next rule…
- Highlight the actions one can take to get to a clean resolution. Use headings, bulleted lists, bold text, and more, to move the reader through the text, and,
- Include accompanying images or key phrases of each step making it possible for readers to scan.
So you made it to the end one way or another, and I have to say, I am impressed. (We are nearing five pages here!) But I wanted to make the most of my 47 seconds with you, and so I did exactly what I told you not to do: Made you read.
