When Help Content Is Forgotten

What's missing from this project plan?

What’s missing from this project plan? Its absence is glaring and painful for technical writers

In recent posts on content strategy, I’ve written about how common it is for “user experience” designers to create websites without considering content. I made this point in my last post, Text Matters, and it’s what fuels the fervor behind content strategy.

In the same way that user experience designers forget about web content, replacing empty spaces in their prototypes with lorem ipsum filler, project managers do an even better job of forgetting about help content.

Content strategy may seem new (and all the discussions about web content being forgotten in website redesign projects), but help content has been marginalized in tech comm since time immemorial. Today our user education team was sitting around in our weekly team meeting, talking about ways to ensure that help isn’t forgotten in project plans.

To illustrate, just last week a project manager emailed me about help solutions for a site launching in a week. Other times project managers come to us at the ninth inning of their projects, when all money is gone and the only remaining budget allows for just a few days of labor. Other project managers suddenly inform us of help needs when the only timeframe to complete the work will require full-time commitment on their project from the first contact until release.

Two Types of Content

In the two situations I’ve mentioned — the project manager who forgets web content and the project manager who forgets help content — “content” doesn’t mean the same thing. On a website, content is the main text, audio, video, and images that users will look at, read, interpret, think about, apply, comment on, and so forth. Content drives the heart of a website.

With an application, however, help content isn’t the focus. Applications do many different things, but frequently applications are a platform for users to create content, such as documents, presentations, projects, agendas, lists, and so on. Think of PowerPoint, Basecamp, SharePoint, or even Twitter. What’s the content in those applications? There is no content, for the most part. The user creates the content. The application offers functionality.

When we talk about help content, clearly help content shouldn’t be on center stage like website content. Help content is an emergency kit in the back of your car, available when you need it. Because of this nature of help content, it’s understandable that project managers would forget it. I don’t even have an emergency kit in my car, for example.

Different Content, Same Question

Despite the different types of content, the problem is similar: project managers forget about content. Website project managers forget about the creation of web copy. Application project managers forget about the creation of help content. (Either they forget or they willfully neglect / postpone it.)

How do you help project managers remember web/help content for their site/application? One of my colleagues is so driven to solve the problem that he emailed the CIO and arranged a meeting with one of the top three decision makers in our organization. It was a positive meeting with many heads nodding in agreement.

But a week later, we sit around asking ourselves if anything will change. Will things be better? What will it take to firmly cement user education into the software development process in a way that has “teeth,” as we kept phrasing it? We need teeth to ensure we’re not forgotten. It’s not enough to acknowledge the problem and agree that user education shouldn’t be called at the last minute. We need teeth, dang it. And we want to lock those teeth down on something and hold it like a pit bull clamps down hard on anything between its jaws.

We need teeth like a pit bull.

We need teeth like a pit bull. (Photo by This Year’s Love on Flickr.)

I’m curious to know if any of my readers have found a workable solution for large organizations such as ours, where new projects come out of nowhere with little or no warning, where the right hand and left hand are autonomous agents acting independently. If you work in a small company where you eat lunch together daily, you may not face this issue. Even mid-size companies with a highly standardized documentation process might not have this problem. We’re more like a full-size startup organization when it comes to tech comm. Our ratio of tech writers to other IT personnel is 1:200.

Brainstorming Ideas

Since this blog is often a brainstorm of ideas enriched by reader comments, I’ll offer a few ideas for helping project managers remember the help content. You can add your own ideas in the comments.

Idea #1. Insert TC into the approval process. Insert a clause in the software development process that requires sign-off from a technical writer before a project gains approval. Almost every IT shop has a project approval process, right? A system of checks and boxes before the finance guys write the check? The problem is in understanding this mysterious process, leveraging the power to change it, educating project managers about the change, and enforcing it. It’s kind of like moving the Titanic onto a new course with a spare oar.

Idea #2. Designate a new project scout. Designate someone to be a scout in the project approval process; make it the person’s job to continually scan for new projects coming down the way. This person may search a project database daily, making contact with project managers to find out information. Or he or she may have close ties with the lead over project managers. (Someone has to allocate a project to a project manager, right?) Maybe the scout sets up regular meetings with this individual to learn about new projects. The only problem is that this meta project manager no doubt is high profile and busy, with little need or care to meet weekly about documentation that his or her project managers should have to deal with.

Idea #3. Bill support costs into projects. Hold project managers accountable for help costs. In a dream world, project managers would have to factor in costs for all support, which means they’ll do everything in their power to minimize these costs up front by providing proper documentation and training. The only problem is that allocating support costs is nebulous. Does the project pay for the health benefits of each support agent, as well as their office space? And how can you budget for something that may be ongoing for years? I wish ITIL recommended a model that considered this idea.

Idea #4. Educate project managers. Start an organization-wide campaign to educate project managers about the need for help, when they should involve technical writers, how many hours to estimate for a project, and such. Hold a regular training for project managers that is ongoing, such as monthly, and invite them all to attend. Begin a campaign of continual education. Even if the project managers keep hitting Decline on meeting invites, they’ll get the point sooner or later. This idea, however, assumes project managers forget help not out of willful neglect, but out of dumb ignorance. This may not be the case at all.

Idea #5. Convert UX to champion CS. Almost every application has an interaction designer or user experience person on the team. Although some UX types don’t want to focus on content, working with and converting the UX lead about the importance of content can give you the leverage of an insider championing your cause. The only problem is that with application development, many UX designers feel a well-designed application won’t need help. Since they plan to create a good design, why would they start thinking about help so early? Doesn’t that admit defeat before the design challenge even starts?

Conclusion

I doubt that any process to help project managers remember content will be effort free. Most of these efforts will require time — maybe 25 percent of someone’s time. Usually technical writers are already so busy working on multiple projects, especially last minute projects, they rarely have time to devote to organizational education campaigns or extensive searches of new projects.

Even if you do have extra time, it’s not often that tech writers have the tenacity to schedule meetings with people three levels above their pay grade to nag them about “documentation.” I know I would feel uncomfortable sending regular emails to the CIO. Maybe this is the real battle: overcoming a feeling of insignificance. Our silence only furthers the degree to which we are forgotten.

Adobe Robohelp Madcap Flare

This entry was posted in general on by .

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, DITA, and more. If you're trying to keep up to date about the field of technical communication, subscribe to my blog. Email

6 thoughts on “When Help Content Is Forgotten

  1. Larry Kunz

    Tom, that’s a good summary of a very real problem. With a 1:200 ratio you’re already up against it, and it’ll be hard for anyone on your team to make time for the additional work of scouting new projects and/or raising awareness. Nevertheless I think that Ideas 2 and 4 might be worth trying.

    Idea 5 is a very good one, and it’s been used successfully in some organizations. One reason that PMs forget help content is the “my product is so intuitive it doesn’t need help” mentality. Your UX professionals can help put the kibosh on that.

    Idea 3 makes all kinds of sense, but first you have to demonstrate that good documentation reduces support costs. This might not be as hard as it sounds. Talk with your support team — find out what each call costs, and get their take on how many calls could’ve been prevented by good documentation.

    Idea 1 won’t fly, IMO. When the project freight train is roaring toward completion, no technical writer will be able to stand on the tracks and make it stop.

    Finally, I like it that you have a weekly kvetch. It probably saves you all a fortune in therapy. ;-)

    Reply
    1. Christine Astle

      “One reason that PMs forget help content is the “my product is so intuitive it doesn’t need help” mentality. Your UX professionals can help put the kibosh on that.”

      Unless, of course, the people considered to be the UX professionals in an organization are the ones with that mentality. There seems to be a number of people who have the idea that if they just design the application well enough, make it intuitive enough, it won’t need help. It will be helpless. Personally, I think the only way to have a truly intuitive experience for all users in all scenarios is to start designing the user.

      Reply
  2. Christine Astle

    As for suggestions, I agree with trying to find a champion within the organization who has the ability to back you up. Whether that’s the UX people, technical support, or someone else entirely probably depends on the organization.

    I think there are a couple of other commonly held beliefs that contribute to the neglect: anybody can write and nobody reads the help.

    If the developer can writer a document in a week explaining the application, why do the techwriters need two weeks to do the same thing. I know the answer; the issue is educating others as to why they should give us the two weeks.

    As well, If the project team has the mindset that nobody reads the help, then the help is not really important; it’s fine to forget about something people don’t use. First of all, that’s assuming that all techwriters do (and can do) is traditional help. As well, we often have no information on whether users read the help, what topics they are reading, if they are finding what they need, etc. so we can’t counter that argument. Of course, if we had the information, we might indeed discover that nobody reads the help (maybe I’m the only one).

    Reply
  3. Reshma

    When we’re talking of applications, help can and should be context-sensitive as far as possible. I think that the first step to ensuring that the help is not forgotten is to make everything that is text in the application the responsibility of the tech writer. This means window/screen names, field captions, menu options, error/warning messages etc. For this to happen, you need a high-level management buy-in to integrate this into the process. The writers role should thus begin when the specs are being written/reviewed. In my previous organization, writers actually could make recommendations for all the text elements of the UI during the spec writing/sign off stage. It helped a great deal to ensure standardization. Of course, we did not have a UX team then. Writers should also consider embedded help, tool tips and so on where the UI is truly intuitive and requires minimal help. However, even though the UI may be intuitive, in an application, there is usually a workflow, which may not be obvious just looking at the app. A user would need some help content that explains the workflow process.

    Reply
  4. Craig

    You said, “I know I would feel uncomfortable sending regular emails to the CIO.” I agree. Our top people are too busy putting out fires. I am not going to add to their burdens by hammering them about documentation. That sort of thing simply isn’t important — until it is. When it becomes important, then I’ll find out about it. That’s the way it goes.

    Reply
  5. Sushant

    Tom, you put a nice post. You have correctly highlighted the points how and why technical writers are being ingnored in a software development project. I completly agree with the point that we must let project managers know our presence and skill in the organization we work for. We must educate the project managers or the product high-level team about how we can offer our help to them which, in the end, help their application/web uers.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>