Search results

So People Don't RTFM? Write a FM That's Worth R'ing — Guest post by Marcia Riefer Johnston

by Marcia Reifer Johnston on Feb 24, 2016
categories: technical-writing

The following is a guest post by Marcia Riefer Johnston exploring an alternative view towards the RTFM argument. In this post, Marcia argues that it's the writer's care and interest in the product and users that leads to producing help content worth reading versus content that is mechanical, dry, and lifeless.

Long-time technical communicator Larry Kunz recently wrote an article — Rethinking RTFM — that, as Larry’s articles do, got me thinking. He’s the first person I’ve heard articulate feelings about this initialism with nuance and respect for all. Yes, RTFM (which, as you probably don’t need to be told, means “read the f*ing manual”) makes us smile. Yes, it captures the underappreciation that all technical communicators endure at one time or another. Yes, it makes for a punchy rallying cry.

At the same time, Larry points out, RTFM conveys a double whammy of negativity: self-pity coupled with disdain for customers. As I commented on Larry’s blog, I’ve been on both sides of TFM: the writing side and the reading side. (Let’s define TFM to be not just an old-fashioned manual but any form of user instruction.) In my opinion, a FM worth R’ing comes down to — this may sound odd — love.

Did the creator of TFM feel enough love for the product, and for the users of the product, to provide information that’s valuable?

When the answer is yes, R’ing TFM can be a satisfying, worthwhile experience. Too often, unfortunately, the answer is no, in which case, even the most eager and forgiving of readers will find R’ing TFM, at best, a time-wasting disappointment.

As an example of the latter type of experience, my husband and I recently bought a vacuum cleaner. For the first time in my life, I own a vacuum that does more than spit dirt back out. (Really. In case you haven’t seen it for yourself, I can attest that some vacuums do that.) Our new vacuum is an engineering marvel. It’s a thing of beauty. You could frame it in a giant shadowbox and hang it on a wall with pride — if it weren’t so useful as a tool.

Owners of this brand of vacuum describe this marvel of airflow technology using terms of endearment. The demonstration I witnessed in the showroom left me eager to get home to our carpets.

In addition, as a long-time tech writer, I couldn’t wait to RTFM. I love a good FM. Give me a good FM over a spy novel any day. Surely, this vacuum’s FM would be a joy to R. Surely, TFM would enable me to do all the wondrous things the sales guy had demonstrated.

Surely, TFM would be as top-of-the-line — as affection-worthy — as the machine it described.

You’re way ahead of me.

TFM was far from R’able, let alone satisfying or worthwhile. I couldn’t find most of the cool features in TFM that the sales guy had so enthusiastically shown us.

The sales guy would have married that vacuum. I was ready to marry that vacuum. The writer of TFM, on the other hand, apparently did not share our sentiments. The writer apparently saw the task of creating TFM as a matter of fulfilling requirements:

  • Warnings: Check.
  • Basic functions: Check.
  • Illustrations created and tucked into the back of the manual, where they don’t disrupt the layout when TFM is translated but where they’re disconnected from the text and people might not even find them: Check.

TFM was done, ready to go in the box. Who, the writer must have have thought, would RTF anyway?

Here’s a typical page from that FM:

A typical manual

What an opportunity missed. No wonder people don’t RTFM.

So what kind of FM would people find satisfying and worthwhile to R? Here’s an example that I find inspiring:

Out of the box from Special Projects on Vimeo.

Hat tip to Robert Rose, who shared this video in his keynote talk at the 2015 Intelligent Content Conference.

Granted, producing the two books shown in the video might cost more than a business can justify. The books would turn into waste paper each time the device’s interface or form factor changed. And who knows whether these books ever met the needs of an audience. As Mark Baker points out in a reply to one of my comments on Larry’s article, these books may be “a case of being too much in love with our own craft.”

Still, this example inspires me. It expands my sense of what’s possible. I appreciate the obvious empathy that went into the approach. I’ll probably never create anything like those two books, but they may spark an idea that prompts me to create a FM that delights someone.

If you write FMs (instructions of any kind), why not write them as if people will R them — as if people can’t wait to R them. First, of course, do what you can to help make the product more self-explanatory so that less needs to go into TFM. Then, do what you can to raise expectations of what TFM can be.

Go ahead. Put a little love in your craft. TFM can make the world a better place. If we, the creators of TFM, don’t believe that, who will?

About Marcia Reifer Johnston

Marcia Riefer JohnsonMarcia Riefer Johnston is the author of Word Up! How to Write Powerful Sentences and Paragraphs (And Everything You Build from Them) and You Can Say That Again: 750 Redundant Phrases to Think Twice About. As a member of the Content Marketing Institute team, she serves as managing editor of content-strategy-related topics. She has run a technical-writing business for … a long time. She taught technical writing in the Engineering School at Cornell University and studied literature and creative writing in the Syracuse University Masters program under Raymond Carver and Tobias Wolff. She lives in Portland, Oregon. Follow her on Twitter @MarciaRJohnston. For more, see Writing.Rocks.

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.