“Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”
― Douglas Adams, Last Chance to See
Calling someone “ignorant” should not be a value judgement. There’s no shame in being ignorant, as long as you acknowledge it and are willing to learn when given the chance. As a tech writer, I love giving my users that chance.
“Stupid”, on the other hand, is willful ignorance. Stupid is refusing to learn.
Users are stupid. They refuse to invest even the tiniest effort to educate themselves. Sometimes, users are so stupid that they act contrary to their own self-interest, sometimes in spectacularly dangerous ways.
Stupid comes in many varieties. You might recognize some:
- Risk Blindness
“My buddy and I were on a hike. The sign said ‘Do not enter. Slippery rocks.’ so my buddy stepped around the sign, slipped, fell, and died.”
- Straight-up Blindness
“I found the keyboard shortcuts in the doc, but I don’t see the shortcut for this specific operation. I particularly don’t see the big, red IMPORTANT note at the top of this page with the keyboard shortcut I’m looking for.”
- Pride
“I’m an expert in the field and I’ve been using products like this for years. The documentation is not going to tell me anything I don’t already know.”
- Distraction
“I’m too busy to learn how to use this product that is key to my livelihood and the success of my organization.”
- Sloth
“I can’t be bothered to learn about this mission-critical product in any other way other than diving in and pushing buttons.”
How can we stay effective users’ advocates in the face of such stupidity?
Simple. Don’t be stupid back.
In my early days as a writer, almost all user questions and complaints that reached us were stupid. We would roll our eyes and gnash our teeth and mutter “RTFM” (Read The F*cking Manual) disdainfully, because we worked like fiends, we documented everything exhaustively, and we knew the issue could easily be resolved with Figure 14-9 on page 452 of the programmer’s guide. Stupid, lazy users! These moments only spurred me to work harder and to document everything more thoroughly.
I cultivated megabytes of Javadoc. I hand-tooled HTML help systems. I contributed to impressive paper manuals that thunked solidly when you dropped them on a table. We worked our brains out under intense deadlines and production schedules to lay out a gourmet banquet of content. We were proud of the work we’d done and when users asked questions that made it obvious that they hadn’t even cracked the books, my wounded pride soured to resentment.
I’m better now.
How did I get it so wrong?
RTFM has roots in an early, pedagogic model of the user/writer/technology relationship developed during World War 2 and the Cold War under wartime pressure to prepare literal armies of users to wield complex new weaponry and countermeasures transformed by advancing technologies.
In this model, the user (such as a soldier) is expected both to learn the technology and use it. The writer acts as an intercessor and translator, preparing the content for the user’s consumption. If the writer did their job thoroughly then the user had no excuse: RTFM.
I was ignorant that the old model no longer applied.
Now I understand that my success is my users’ success. “Stupid” user moments are opportunities. Users are not stupid. They have foibles and motivations that I need to account for so that they succeed.
The Risk-blind User
Safety issues are best resolved by design before users are set loose with the product, but writers often have to work with what we’re given. Sometimes the nature of a product makes user risk unavoidable (for example, a hiking trail at a waterfall or an application that allows users to deal in tens of millions of dollars in a single trade). Users can be very bad judges of what is dangerous. This doesn’t make them stupid. It makes them human. Either their usual activity is mundane (hiking) and they aren’t equipped to recognize the risk in context (slippery rocks, a long fall, and death), or they regularly do dangerous work (multi-million-dollar trades) and they grow insensitive to the risk (financial loss).
So what do the users’ advocates do? Dire consequences must be clear and unequivocal to shock users out of their complacency. For example, the trailside signs along Yosemite’s rivers and waterfalls clearly state that walking, a normally safe activity, is not safe there: “Stay out of water! Powerful hidden currents will carry you over the fall. Stay back from the slippery rock at the water’s edge. If you go over the fall, you will die.” In some locations, posted signs included names, pictures, and dates of victims for even greater impact.
For those high-flying traders dealing millions with a click, just use the magic words: “If you trade with market safeties off, you can lose money.”
The Unseeing User
Recently, one of my users apparently went blind. I know the user. She is not stupid. On the contrary, she is smart and experienced. She consulted the doc and found the relevant topic. How did she miss that big, red IMPORTANT note?
After some thought, I recognized my mistake. Users see what they expect to see. My doc presented the keyboard shortcuts by associated UI element. The offending shortcut had no associated UI element, so I made an exception in a note at the beginning of the topic, hoping that this would be enough. But my content organization set the user’s expectations and I failed her with an exception. I should have made the exception consistent with my organization or, better yet, reorganized altogether.
The Prideful, Know-it-all User
The solution can be as simple as a breezy “What’s New” peel-off sticker on hardware or a tap-though in an app—a small, conventional step at the start of a user’s experience with the product that has a chance of breaking through the hubris. For example, I just bought a new bathroom scale. I’ve been using bathroom scales for decades now. You might consider me an expert bathroom-scale user. I don’t feel like I need to read a manual to use a bathroom scale. Anticipating my attitude, a slick peel-off sticker on the scale told me where to get info if I did have any questions or issues.
The Distracted User and the Slothful User
Your users’ attention is fragmented. Their time is limited. I hope I’ve made it clear that you are not a good advocate for these users if your solution is a fat manual. I could say a lot about ditching that manual and gracefully inserting easily apprehended, unobtrusive instruction, alerts, and tips into the user’s interface and workflow, but other folks have said more on this subject than I have space for here. (Aurora Harley (@aurorararara) does a good job here: https://www.nngroup.com/articles/mobile-instructional-overlay/).
So now the users’ failures are not evidence of their stupidity, but proof that they are human beings and that the product (including the documentation, of course) has failed. Instead of invoking “RTFM” as facile and impotent absolution for our sins as tech writers, we’re finally acknowledging that no one is reading the f’ing manual because often there shouldn’t even be an f’ing manual to read.
I have a small confession. Despite my big talk of user-focused doc innovation and alternatives, I produce lots of traditional manuals in PDF. When I crowed about a recent cross-functional triumph, collaborating with my Support team to refactor 50 pages of dense content to 13 customer-focused pages, a good friend nicely summed up prevailing attitudes: “13 pages is still probably too many.” Sure, I maintain single-source repositories. I build all sorts of help and user assistance in a variety of formats for integration with various technologies, I also build thousands of pages of book-paradigm PDF manuals. Why do I do it? My users demand them. Customers ask for them. Contracts stipulate them. Sales, Support, and Technical Account Managers beg for them. Why would I stop providing PDFs? Why would I confound all these users and their expectations? That would be stupid.
