For example, our current department’s name is “User Education.” Because of this, every time a user has a how-to question about the application, they send the user to me to be educated. It would not be so, I believe, if our department name were different.

Lately I’ve been having conversations with a QA guy as I carpool to work. We’ve been talking about roles. Because I am a “technical writer,” he wonders why I feel I should comment on software prototypes, or interact with users. “You’re a W-R-I-T-E-R,” he says. “You shouldn’t be interfacing with the customer. That would be overlapping other people’s jobs. You should be writing help material. That’s what writers do.”

People make decisions all the time based on connotations of job titles and department names. For example:

• A user needs help with the application. Who should he call? “User Education” or “Information Design”?
• You’re setting up a meeting to evaluate prototypes. Who should be included? “User Information Development” or “Technical Publications”?
• You need to develop some e-learning materials for training. Who should you call? “Learning Support” or “Strategic Communications and Media”?

In each case, I bet you leaned toward the first option. Your department’s name does affect how others perceive the role of your department. I guarantee you will be asked to provide more user training and support with a name like “User Assistance” than “Communication Strategy and Design.”

Given the importance of choosing a department name, here are some options. Many of these were sent to me by tech writers over Twitter. Others I pulled from the archives of the Techwr-l listserv.

• Information Design
• Information Development
• Learning Support
• Technical Publications
• Technical Publications Office
• Technical Communications
• Training and Publications
• Design and Development
• User Information Development
• Technical Information Development
• Technical Documentation
• Documentation
• IT Documentation
• The Knowledge Group
• Knowledge Transfer
• Strategic Communications & Media Group
• Customer Focused Communications
• Global Content and Training Products
• Customer Communications
• User Success Group
• Corporate Publishing
• User Knowledge Center
• User Assistance
• User Help Department
• Help Design
• Documentation Analysis
• Information Architect and Strategist
• Communication Strategies
• Customer Focused Communication Design
• Communication Strategies and Design
• User Assistance Strategies and Design
• Information Strategies and Design

And a few silly names:

• Fellowship Renowned for Excellent Documentation (FRED)
• Masters of All Spatial Order, Chronological Hierarchies and Interesting Sorts of Trivial Stuff
• The tellers of how stuff works and what is
• Department of User Intelligence (DUI)

None of the department names jumps out at me as “the one.” In the end, I’m convinced that a slightly vague name is better than a limiting name. I’d rather be “Information Development” than “IT Documentation.” In the former, you might contribute to prototype design; in the latter, you would more likely just describe the design.

I would rather be “Information Strategies” than “User Knowledge Center.” In the former, I might make high-level analytical decisions about branding, user awareness, and task efficiency. In the latter, someone would assign me to assemble a knowledge base.

I would rather people said, “Communication Strategies and Analysis – what the heck is that? Rather than “Learning Support? Oh, good, I have a group of new users that needs a Webex.”

Have you ever had a department name that you worked against you? What department name do you prefer?

Additional Reading

• Tech Writer: “Someone who writes as opposed to someone who rides something.”

The Real Problem

The real problem isn’t that people believe no one uses help, but that no one finds help useful. Most people are too tactful to say this outright, but it is a distinction you might raise: “Did you mean no one uses help, or that no one finds help useful?” The answer is probably both: people don’t use help because they don’t find it useful. And the more help isn’t useful, the less people use it.

Pyramid of Results

The “Pyramid of Results” (what I’m calling it) explains the root of the problem clearly (see graphic). Experiences are the foundation of our beliefs. Beliefs give rise to actions. Actions lead to results. Here’s the key:

If you want to change the result, you have to change the underlying experiences behind the result.

In other words, you can’t convince people that help is useful unless you change their experiences using help.

I once read that every poor help file is a black eye to the profession. I didn’t entirely understand that at first, but now I do. It means that even when engineers in other countries write terrible help documentation, though it seems unrelated to my products, life, and experiences, it actually drives the general experiences users have with help, solidifying in their minds the idea that all help is useless. Since help is useless, it’s unlikely that people use it. If people don’t use it, it’s not significant. Experiences form the basis of their beliefs. So as excited as I may be about my help file, I’m fighting against a mountain of poor experiences that users have had with other help files.

We have to change people’s experiences with help if want to change their belief about its usefulness.

My Plan to Change Perceptions

We can turn the tide of this thought, but it will require radical changes. It won’t be enough to merely provide well-organized, accurate, grammatically correct help. Help has to go above and beyond the mark of helpfulness. It has to be so good that it blows people away, that it gets your attention in a shocking way. People use the help and their jaw drops because … because … all the answers are there, in just the format you want. It’s simply awesome. It teaches you everything you need to know, right when you want to know it, concisely.

A Challenge for Creative Innovation

Although we sometimes think our field is dry, technical, and just a day job, if someone can figure out how to make help whallop the user with wonder and awe, it will be the creative innovation of the century. Once we begin to establish a standard and a precedence, people’s beliefs will change from feeling that “all help is useless and unimportant” to “the help at my company is exceptionally good and useful; I will explore it more often.”

Such a radical shift in help might have the following help characteristics:

• Audiovisual options for each topic (screen demos)
• Excellent search and index — searching for a word finds the topic
• Personalized help for your role and job title
• Ability to provide feedback to the help authors, to contribute, or otherwise interact
• Cheatsheets, cue cards, quick reference guides, and other handy references you can print
• Abundant visual displays of processes, workflows, procedures, and other eye-catching diagrams
• Help that calculates and aggregates the most popular topics based on number of times viewed and searched for
• An active, engaging blog about the product integrated with or beside the help
• Download options to load help content onto your iPod, BlackBerry, or other device
• Live chat support
• Holographic images of a friendly person explaining (with gesticulations) help concepts (I’m kidding here)

What do you think? What would help need to have to change people’s experiences for the better?