Sometimes the audience for my help consists of seniors in the range of 60 to 85 years old. The other night I attended an orientation session with users to introduce them to a new application we were releasing. As part of the orientation, I observed first-hand the challenges that seniors have with computers. Here are a few user interface problems:
At the orientation I attended, what users really needed, beyond a more helpful UI, was a table listing all possible error messages in the application and the resolution action for each. Error messages are particularly subtle components that we tend to miss when writing documentation. After all, we're documenting how the application works, not so much how it doesn't work.
Also, error messages often don't appear when you're doing things right. Only the QA engineer can probably know all the possible error messages, since he or she actively tries to break the system. You can also find error messages by watching users, particularly novice users who often don't follow standard browsing/navigating/clicking/selecting protocol.
Just because you're in a development environment, don't assume error messages are temporary and will be eliminated when the system is released. Instead, take a guilty-until-proven-innocent approach. Err on the side of assuming the dev environment will match production rather than assuming production will be a magical environment where everything works error-free.
Today I trained another group of users on an application, and being in a computer classroom, I could observe them at the computer. Again, I was stunned by some things. What I considered fairly straightforward and intuitive, they found tricky and frustrating.
Sometimes when I write help, I mistakenly think of myself as the audience, and will write thinking of tips and how-to information that I personally would need on that page. But this is not the case for many audiences.
Although I'm no tech giant, I do consider myself handy with computers. Most users, at least for my applications, are not comfortable with computers. Computers are a temporary means to an end for a brief period of time, rather than something they work with all day long. Because of this disparity of environments, when I write help, I try to simplify the instructions beyond what I need. I'm not advocating that tech authors write idiot instructions (e.g., click the up arrow to move up), but think of the user perhaps as your grandfather or grandmother.
Part of the problem in writing help is that we explore and play around in applications so long, we lose our first perspective. We lose that sense of disorientation and lost-ness that users have the first time they get in the application and click around. If there were a way to wipe our application experience and start fresh, it would be invaluable.
About the only way to regain this "application innocence" is to observe users. See where they get stuck, what they click, what their first inclinations are to do. Anytime you can watch users in your application, the epiphanies fall like snow from a winter sky -- all over the place, and not always pleasant. It can be an awakening to your application and documentation's usability. This eye-opening experience is one that doesn't come any other way except through user observation.
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.