Before Google–yes, I’m dating myself–RTFM (or Read the F***ng Manual) was the stock answer to many “how-to” questions. What’s the command for testing the network? RTFM. How do you configure the server? RTFM. We had sets of product manuals — literally, credenzas full of them. Remember credenzas? Along with being a fun word to say, credenzas were the hulking home to these bound volumes of techdocs that would make your eyes bleed if you stared at them too long.
Nobody reads product manuals anymore. Our phones don’t have them. They don’t collect dust on shelves somewhere. And nobody even knows what a credenza is! “Google it” is the common way to answer questions and figure out how to do shit. (Or, if you’re feeling really snarky, “let me Google that for you” is a great resource).
In these bygone years, product teams often had technical documentation or technical publication sub-teams. I’ve managed these teams. I still meet many teams with these functions. Enterprise customers expect “manuals” or documentation when they spend hundreds of thousands and millions of dollars in software. Whether or not we read the manuals doesn’t matter as much. There is a built-in expectation and it’s part of the experience.
Some teams have modernized, leveraging more rich media assets like video, but there’s still a lot of text being slung as part of each software release. “Don’t forget to update the documentation.” “Where’s the Jira ticket for updating help?”
Can we just stop the madness?
Software Shouldn’t Be Hard
Here’s the thing: manuals existed in response to the fact that software was hard to use. What if we just shifted our mindset from believing that software is supposed to be hard to use, to designing it to be simple in the first place? What if we changed the expectation that every product needs a manual to the expectation that every product needs to be simple and intuitive and designed to anticipate and fulfill user needs? Your product itself should be your biggest marketing asset.
Sure, removing documentation may be a risk; but I’d rather field support tickets and learn why a user got stuck than allow documentation to act as a crutch, perpetuating mediocre product experiences.
Does that mean that users have to fend for themselves completely? Not necessarily. Users need a helping hand when they are being onboarded, when the interface changes, or when something new is introduced. But that experience should be interactive. Forcing me to read three pages or spend 10 minutes watching a video is an unacceptable alternative. In fact, if you ask me, it’s soul-sucking. Show me how to do it. Get me doing it. Give me positive feedback when I do it properly — that makes me (the user) feel good about myself. And that makes me like you (the product) more.
In short, make the manual part of the overall experience.
Recasting Tech Writers
The push-back, of course, on this is around the job displacement. What do we do with all the tech writers? It’s fair question and I understand the fear that this idea would strike in the tech pubs community.
But I think that there is a way to reimagine what tech writing actually means – words still matter. A lot more, arguably. Because now you can just write indecipherable jargon, you should be able to write copy that fits into products in an intuitive and seamless way. Good product experiences now mean not only good microcopy and guides but also broader content pieces. Those can walk users through use cases that are similar to their own, give them inspiration for ways to use the product, and help them troubleshoot in ways that are easily accessible.
The manual may be dead, but good product guidance isn’t. Thoughtful product leaders recognize this trend, built simpler products, and arrange their teams in a way that brings good content into the fold.
