He mentioned this during one of our lazy afternoon meetings, which dragged on much longer than the scheduled time. The central problem of writing help, my colleague Derek explained, is how you make it so Joe user can find the answer to his one question among 50,000 other answers in the help.
Every user seems to have the one or two questions he or she thinks should be at the top of the help file, he explained. A lot of users think a help file only needs a few pages -- listing the answer to two or three questions.
But project managers have one set of questions. New employees have another set of questions. Team members have their own questions. And team managers have other questions still. You can't just address one user's questions without deprioritizing other questions. And as soon as you start answering everyone's questions, the help grows longer and longer. You start trying to account for all of these different questions and scenarios, adding more and more topics and notes and other information, and the help grows longer.
At some point, with so many topics, your help sucks. Either it becomes too long, and users dismiss it as a lengthy manual no one has time to read. If you reduce it to five pages, it also sucks because it doesn't have relevant information for anyone.
Exactly, I thought. I've been trying to answer this exact same question! This is the central problem of help. It's why I have 40+ posts on the topic of findability. It's why I came up with my whole metadata plan, and faceted browsing, and so forth.
Then Derek shared an experience that opened my eyes. He said about ten years ago, when he was a new technical writer, he was incredibly enthusiastic. He read everything he could get his hands on, kept up with the latest journals and conferences. He had lots of energy and drive to learn everything he could about technical writing. He tried different approaches with help, always trying to figure out the solution that would make users happy. Once, during a meeting, he told his project team, One day I'm going to figure this help thing out. I'm going to figure out how to do help in a way pleases every user.
He later changed jobs and navigated his career path. A decade later, as he was interviewing at a local company, some of the same project members were there, and they were the interviewers. Near the end of the interview, his former team member said, Derek, so, have you figured out a help solution that satisfies all users?
Derek was at a loss for words. No, not really, he said. He mentioned the move to improve user interfaces, and how you have to go to the UI with the information users need. But he knew this was only part of an answer, not the answer.
Like Derek, I often say to myself, One of these days, I too am going to figure out the solution to help. I'll come to the right solution that makes every user satisfied. I'll find a way for Joe user and Suzy user and Sam user to find that one topic he or she needs among 50,000 other help topics.
And yet, I've been a technical writer more than half a dozen years, and I still haven't come up with the answer. Is the answer to move towards usability and try to fix the UI, or embed your help directly in the UI? Is the answer to build a robust search engine, like Google, so that users can find what they need by searching? Is the answer to provide more video-based tutorials that guide users through problems visually? Is the answer to create quick reference guides that get users up and running? Is the answer to present a course that users progress through, one level at a time? Is the answer to provide informative graphics that communicate visual information to the user? Is the answer to get lots of SMEs writing the content, perhaps on a wiki?
I keep thinking that one day I'll stumble across the answer. I'll figure it out.
Mark Baker, who has also followed this problem diligently, writes,
Findability is an intractable problem. This does not mean that we should not try to improve findability. World peace is an intractable problem, but it is still worthwhile to make a friend. Climate change is an intractable problem, but it is still worthwhile to plant a tree. Findability is an intractable problem, but is it still worthwhile to add a keyword.
Still it is important to recognize the that the problem is intractable, lest we waste too much of our time and energy for too little gain. (Findability Is Intractable)
He goes on to explain the shortcomings of solving findability through taxonomy and other measures. His tone reminds me somewhat of Ecclesiastes, when he laments:
All the rivers run into the sea; yet the sea is not full; unto the place from whence the rivers come, thither they return again.
I wish I had more insight. Maybe a clever reader can fill in the gap. I fear that the answer might be a combination of solutions -- similar to the answer of how one makes money on the web. Apart from building a wildly successful app, the way to make money online is by diversifying your income stream. You provide advertising, give presentations, do consulting, sell e-books, sell products, host webinars, create courses, host affiliate links, and do other efforts. Alone, none of these solutions amounts to much. Combined, they produce a decent income stream.
Perhaps help authoring is the same way. You write the quick start guide, you produce a series of screencasts, you record a podcast, you publish a reference manual, you embed help in the user interface, you provide e-learning courses, you build a robust search tool, you create a meticulous index, you provide several main entry points (beginners, troubleshooting, scenarios), you even put a little Chat Now box in the app. You do all these things, and though none alone is the answer, together they meet 80% or more of the user's needs.
That may be the reality of the problem. But it seems like a lot of effort, even if you can repurpose content from a single source. It seems so much more elegant to dream of the one brilliant idea, the one deliverable to rule all deliverables, or the magic trick that solves findability every time for Joe and Suzy and Sam, regardless of their scenario and individual needs. But that pursuit, like looking for the fountain of youth, might merely be a vain effort that keeps us walking past the answer, even when it is right in front of us.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.