… it’s not about tech writing. No one cares about tech writing. They care about service, about finding answers to problems, and about positive experiences.

Scott Abel, commenting on a blog post by Ivan Walsh

As he often does, Scott Abel got me thinking. At least, got me thinking a little more deeply about something that’s been on my mind for a while now. And that something is what’s important and what’s not when it comes to user assistance.

Content, content, content

When dealing with what’s usually called user documentation, what Scott Abel said is right on the money. It’s not about tech writing. It’s about content.

It’s about content that’s easy to read and easy to follow. It’s about content that’s delivered to users in the way they want and need it. It’s about content that helps users achieve their goals — getting a task done in the fastest, most efficient way possible.

Formats and tools

And you know what? It doesn’t really matter what format that content is in. It just needs to be accessible. Users need to be able to get to the information that they need when they need it. It can be PDF, HTML, SVG, Flash, on a wiki, or in a blog. It can be on the user’s computer or handheld device, or on the Web.

And this leads to a point that I keep harping on about. Blame that on Gordon McLean (he’s a bad influence on me) … That point is the tool is not important. You can add techniques to that, too. At least, all of those things aren’t the most important factors.

The tools we use in our wacky profession are a convenience for us, as are the techniques we use. Users don’t care if we use FrameMaker, AuthorIt, Flare, Word, AsciiDoc, OpenOffice.org Writer, DITA or DocBook to create the content. They don’t give a hoot if the content is single sourced or topic based.

Using the most popular (or even obscure) tools and techniques doesn’t ensure that the content is well written, easy to follow, and conforms to the 6Cs. It’s up to you, the technical communicator, to ensure that.

What about technical documents?

By that I mean API and developer docs, operations and administration guides, and the like. Guess what? it’s still about the content. Anyway, I lump that kind of documentation into the category of user documentation. It’s just that the audience is different from, say, the manual covering how to use a piece of software or a gadget.

The content still needs to be correct. It still needs to be concise. It needs to flow. Imagine you’re writing an SDK guide. You need to ensure that the code you’re documenting is accurate. You need to ensure that any examples that you’re including actually work. If not, the content is useless.

In some cases, as I discusses in a previous post, you need to break a few rules in order to make the content more usable by the audience.

But your focus needs to be on the content. Everything else is secondary.

Thoughts? Feel free to leave a comment.

Update: A good post in a similar vein from Tom Johnson, and a very interesting response to this post and Tom’s from Alan Pringle. Both are worth a read.

Related posts:

1. Usability: as important as the product
2. What’s more important, content or process?
3. Is telecommuting important to you?