Notes Watching Senior Users at the Computer

by Tom Johnson on Mar 6, 2009
categories: technical-writing

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:

• Calendar picker tools are tough to navigate, since the forward and back links are small. In these situations, make the calendar larger and provide a sample date format so users can type it in manually. Also, many users won't realize they can click the calendar icon to select the date.
• Senior users may not be used to scrolling, so if your Next or Continue buttons are at the bottom of the screen, and only visible if you scroll down, the user may be confused as to what to do after finishing a task on the screen.
• If the application doesn't immediately respond when you click a button, make sure an hourglass or some other visual indicator promptly appears, because otherwise users may think the button didn't work and will click the button two or three times. Also, in your testing of the app, make sure an error doesn't appear when you double-click a button.
• Some senior users tend to focus entirely on the screen, rather than being able to bounce back and forth between documentation and the screen (even when they need to). Try to integrate the help in a context-sensitive way such that it's combined with the task on the screen (much easier said than done).

Error message Documentation

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.

Simplification

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.