This was a thread on the TECHWR-L listserv that I responded to … I thought it’d make a good blog post.
A little bit of context — a writer had posted to the list saying he’d felt a lack of meaning and purpose in his job, since he was positive that customers were neither finding nor reading his documentation. This is a common refrain among technical writers; in the ~9 years I’ve been in the industry, I’ve heard it a lot from other writers and felt it a lot myself.
There are several reasons that we feel this way, but in my response, I focused on one: users expect answers to individual questions but are forced to read chunks of user manuals (that technical writers put out) instead.
Here is my reply:
+++
What does Tech Comm mean to me? As someone who can easily put single-page help topics on the web as soon as they’ve been reviewed, I have come to see myself as a support rep who can answer customers’ questions with an authoritative voice — by virtue of my experience with our product, skill at choosing words and explanations and graphics, skill at anticipating customers’ questions/issues, and proximity to those with the answers to questions that customers have.
I emphatically [recommend] reading the blog Every Page is Page One. For those who haven’t read it, it’s immensely relevant and insightful to anyone who is posting help content on the web. The title of the blog refers to the fact that you (as a writer) can no longer control where users will land in your collection of content — because it’s highly likely that they will have Googled to find the answer, and Google will deposit you on page 55 of a user manual if that has the answer, or on page 45, or on page 102.
Modern help content benefits by taking this information-gathering strategy into account, where “taking into account” means every “page” of your help system needs to be “page one” — because it could be the first page a user will see. If your content isn’t delivered in this way, customers may turn elsewhere for information, because with your content isn’t designed to answer questions. It’s designed to communicate ideas and teach. If they looked at your content, customers would be forced to read several paragraphs, or parts of a chapter, or click a bunch of links — all of which take more time and energy than simply asking someone.
EPIPO’s premise is that if you don’t facilitate quick entry into (and navigation of) your content, someone else will. Either someone will start a user forum, or devote a StackExchange section to you, or something else. Seeing that kind of info out there is what led to me having my own identity crisis as a TW.
The posts on EPIPO are all about how to write and structure your content so that it turns up in, and is easily consumable as, Google search results. Yes, your help topic will be just another Google result — but it’ll be from you, helping give meaning to your job. And the topic itself will have the company’s stamp of approval, lending credibility to it (and being backed by actual customer support, and warranty, vs. a forum).
Note that writing like a Google search result (instead of a user manual) doesn’t imply a short topic or shallow depth to one. Many concepts require in-depth explanations that are several pages long and full of technical illustrations. Many answers are complex and nuanced. We can include as much depth and background in each topic as we feel is helpful to our users. We can answer users’ questions directly instead of asking them to follow a narrative thread to find their answer.
Anyway, I’m a big fan of the blog and its precepts, as you can tell 😉 Not all companies grok the difference, and obviously we as writers don’t always have control over how or when our information gets put out there. But companies that do are out there, as I can attest to with my own personal experience.