The last STC News and Notes email highlighted a BBC News article entitled “Web users ‘getting more ruthless.’” The gyst of the article, which is based on a report by usability specialist Jakob Nielsen, is that people are doing a lot less Web surfing than they used to. People go online to accomplish specific things and are not given to wandering and dawdling.

I don’t think this surprises anyone much except for Web marketers, who try to grab people’s attention (and end up annoying them instead) with ads and widgets. But what does this mean for us as technical communicators? Are we contributing to people’s success rate of accomplishing their tasks online? If not, how do we?

Nielsen points out that one of the reasons people are becoming more successful at accomplishing online tasks is the use of search engines that can take them more directly to the Web pages they need. They don’t have to come to the home page and try to navigate through the menus as much anymore. Fortunately for us, help authoring tools and other software like Adobe Reader provide search capabilities out of the box.

One of the challenges for me while writing user assistance materials is deciding what information is useful. Minimalists argue that less (information) is more (useful and usable). But what if you cut out some content that is just what someone needs later to answer a question? Thinking this way, I get in danger of providing too much information, making it harder for someone to find what they need. Take away the haystack, and people don’t need to look hard for the needle.

No matter how much or how little content you provide, this is where “The Code” comes in. Good old-fashioned tech writing principles say that to be usable, technical content should have clear headings, logical organization, consistent and concise language, and diagrams (where needed).

I’m not a minimalist; as mentioned, I probably tend to err on the side of providing too much information. At least if I do that, I can still make the content easily navigable. This is where creativity comes in to technical communication. Unless you’re tied down by corporate dictates, you can put some thought into the best structure for your project’s purpose. Spend some time devising an organization and structure for your documentation before you ever start writing. Give it a friendly and inviting character. It doesn’t need to be inviting to the point of trying to keep the user inside the content, because that’s not the purpose, and as Nielsen has found, you’ll gain few fans; it should be inviting to the point of saying, “Hey, I’m going to help you get your job done. I’m the express lane, so come through here, get what you need, and get out.”

Related entries (auto-generated):

Where Usability and Documentation Meet

Documentation Needs Usability Testing, Too

Technical Documentation for Zero-Attention Audiences

Making an Opportunity out of Rogue Documentation

Six Things to Remember in Your Documentation Usability Testing