---
title: "Faulty Assumptions About the Scope of Help Content? [Organizing Content 15]"
date: 2010-06-11
description: "Findability / organizing content   1.0 New Series: Organizing Content [Organizing Content 1]   1.2 Introducing Project..."
canonical_url: https://idratherbewriting.com/2010/06/11/faulty-assumptions-about-the-scope-of-help-content-organizing-content-1/
---
# Faulty Assumptions About the Scope of Help Content? [Organizing Content 15]
But today I had an experience that made me rethink this assumption. Maybe the problem isn't so much that users can't find the right help topic for their situation. It's that the topic they need *isn't in the help. *It's not that the topic isn't findable. The topic isn't there at all. 

Ever since the release of Swordfish (my fake project name), I've been filling a support role for the application as well. It's a small group, and I wear multiple hats. I know that this support role, while annoying at times, is also advantageous because it gives me an insight into the real problems users are having. Through this close connection and user-informed perspective, my help can provide real answers that users want.

But in reality, the phone calls keep coming and coming and coming. Since the release of Swordfish, I must have responded to about 50 different users, with some users asking multiple questions. A few users have me on speed dial. I see their phone numbers flash on my phone and I think, oh, it's Frank again.

Why is it that all of these users don't t turn to the help material to find answers to their questions?

As I started listing their questions and assessing the help, it dawned on me: the help did not contain answers to these questions. Their questions involved bugs and quirks in the application, edge cases, seemingly random scenarios, unexpected situations, abnormal uses. Few people ever called me to ask a basic question.

Here are a few fictional examples. Joey tries to upload a file and gets an illegal upload error. It turns out he has a space before the period in the file extension that causes the error. Another user finds the system times out randomly and doesn't save the typed information. Another user wants to do something that isn't possible to do in the system. *At least 75 percent of the questions don't involve matters of basic user education, but are rather related to bugs, special situations, or other types of information not typically located in help material.*

No matter how many navigational aids and facets and search keywords I add to the help, if the help doesn't include the answers people need, it won't be helpful, right? It won't matter how findable and well-organized the content is if the content users need isn't there.

### A More Fundamental Issue

This led me to think about a more fundamental issue than organization or findability: the type of content itself in the help material. What degree of user problems and questions should help address? All of them? Most of them? Some of them?

In a [podcast Alistair Christie recorded last year](https://idratherbewriting.com/2008/09/09/how-much-should-you-document-strategies-for-an-agile-environment/), he mentioned that you don't have to document everything. Less is more. But is it? As a user, would you rather have a massive help file that contained answers to almost every question, problem, and scenario (if you could just find it), or would you rather have an abbreviated help file that only covered the most common tasks in an easy-to-navigate way?

While I agree that in many situations "less is more," this truism doesn't help me answer support questions. It continues to render the help as a resource that is pushed aside because it doesn't help the user.

### A New Goal for Help

To address these concerns, I have a new goal I'm trying out. Before responding to user questions, I make sure the answer is in the help. It may take me two hours to research and type up a new topic and republish the help system before I respond to the user, but it's better that way. When I respond, I send a link to the specific topic in the help file. This teaches users that help is actually a thorough information resource with answers to their questions.

### Ever-increasing Help Content

With this method of documenting everything, after some time the help material will grow and grow. What started out as a 197 page manual may well grow to 300 or 400 pages. The more topics I add to the help, the more potentially informative it becomes.