I listened to Alistair Christie's IT Author podcast the other day online and then later driving home from work. Alistair is based in Scotland and has one of the most enjoyable podcasts on technical communication around. If you listen to podcasts, add his podcast to your feed. His latest episodes are as follows:
Although the dogcast started out slow, this was the podcast I enjoyed the most. About 15 minutes into the podcast, he really hit his rhythm and started driving down into the topic that seemed to grip him most: user psychology. Users don't read manuals. The days where long, printed manuals were standard prerequisites to using technology are gone. People experiment with an application and try to learn by doing; when they need information, they search for information about the task they're trying to accomplish in that instant. Online help is critical in helping users find a single piece of instruction for an immediate need.
Users are also in a state of anger and impatience when they turn to the help. They're mad because the software has frustrated them and stopped their work. They don't want to read a manual. What they really want is someone to explain to them how to do something.
Listening to Alistair's thoughts on the user's state of mind made me think about the help we write. Why is it that we often begin a software documentation project by documenting all the tasks that users can possibly do from all the available functions of the software application? We spend the bulk off our time creating written instructions that almost no one wants or reads.
Instead, I think we should be focusing on several key deliverables:
Further, we should begin by getting to know our user -- not through a description from the SME or business analyst, but actually contacting the user to determine the tasks they want to accomplish and the format for the help.
The Getting Started guide should walk them through the most common, basic tasks the user will need to perform. This guide should be easy to get through. Alistair says the help should provide immediate rewards to the user. Take them through some quick wins. In the Getting Started guide, you give them easy-to-perform tasks that make them successful.
The screencasts (which should also be short) provide a range of other benefits, such as providing the experience of a friend showing them how to use the application.
The context-sensitive online help gives the user immediate information about the task at hand. The online help also provides a searchable database for answers.
So often we begin with the comprehensive manual in mind, when that's the last priority for users.
A few months ago I posted some notes from a Kathy Sierra presentation that talked about the user's state of mind as well.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.