Notes Watching Senior Users at the Computer

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.


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.

Madcap FlareAdobe Robohelp

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

10 thoughts on “Notes Watching Senior Users at the Computer

  1. Alistair Christie

    Watching users use the software you’re documenting – or better still watching them use the software you’ve already documented – would be great. I’m guessing, though, that few tech writers get the chance to do this (I never have).

    However, even watching people using *any* software is a great way of reminding yourself that things that seems obvious to you just aren’t obvious to others.

    Yesterday I watched over his shoulder while one of the QA engineers at my work used Jing for the first time. I was astonished to see that he found it difficult to mark the area of the screen he wanted to capture. To me it was so simple: click where you want the top left corner to be and drag down diagonally to where you want the bottom right corner. If I’d been documenting Jing I might have assumed that it would be enough to say something like: “Click and drag with the mouse to draw a box on the screen. Your video will show everything that happens in this box.” But, for my colleague this wouldn’t have been enough.

    It’s tough. You don’t want to treat your readers like idiots. But on the other hand you can’t make many assumptions about what they’ll know.

    1. Tom


      Thanks for the comment. I agree that access to users in their environments is tough. Actually, access to users period is often tough. But you can create your own ad hoc usability lab under the guise of training. If you do have a training component to your role, schedule an hour in a computer classroom for “training.” As you train users on how to do tasks, give them a few activities to do, and then circulate around the room, watching them try to do them. It always blows me away. Bring a QA engineer and interaction designer, if you can.

      Re Jing, that’s interesting. I’ve introduced Jing to some of my IT colleagues and it has taken off here (at least for the QA people).

      I see you have a new comment philosophy. That’s cool. I always enjoy comments. I’m a bit slow in my replies, though. Still working on that.

  2. Milan Davidovic

    “Only the QA engineer can probably know all the possible error messages, since he or she actively tries to break the system.”

    Those error messages had to come from somewhere, though; someone else must know about them, too. Try going back to your design docs, see if they deal with failure conditions, and work your way forward from there.

    1. Tom

      Milan, thanks for leaving a comment. In my environment, we follow agile methodology, so there really aren’t any design docs, just prototypes. I’ve found that developers do understand the error messages, but since there are multiple developers on any one project (usually), it may require some asking around before you find out who wrote the error message.

  3. Pingback: » Baby Boomers and Instructional Design Instructional Communications and Technology

  4. Rhonda

    Hi Tom

    One thing I’ve noticed that my parents have difficulty with — even after using their computer for some years — is when to single click and when to double click. And with double-clicking, how quickly you have to click — too quick and it doesn’t work; too slow and it doesn’t work either. My father, especially, continues to have difficulty with this. They fit your seniors demographic, being 78 and 79 this year.

    My 85 year old uncle has difficulty with coordinating mouse, keyboard and what’s on the screen. He’s been using computers for years for email and genealogical research, but it’s quite frustrating watching him as his eyes and hands go from one to the other. Slightly impaired mobility is one thing — the other is the mental leaps between the various physical and on-screen objects that those of us familiar with software, hardware and the internet take for granted.

    I’m sure my 20-something nieces and nephews equally find it incredibly painful to watch as I try to get my slow thumbs to create a text message! There are times when I’m sure they’ve just wanted to grab the phone and do it for me…

  5. Brad

    This article and some of the comments piqued my interest; especially for what is considered the ‘senior range’ of 60-85 yrs. Though I will be 58 this year and a few colleagues of mine are in their early 60’s, none of us feel like ‘seniors’.

    Perhaps being involved in the deep end of computers [programming, system integration, testing], we are used to working with applications and hardware so the basics of scrolling, double-clicking, or selecting, for example, in screen capturing software isn’t difficult for us. Most of us also spend our non-work hours with computers.

    I will contend that there are many like my mother, who didn’t get involved with computers until 80 yrs, do run into some difficulties though double-clicking was no problem for my father-in-law in his 80’s as he had worked the Morse key as a ham radio operator for years. Through long-distance instruction, I’ve even had my mother making changes in her registry and changing out cards inside her computer.

    Outside of a Mac in my late 30’s, I didn’t really become involved in computers and apps until my early 40’s but feel quite confident in all aspects of usage including Twitter and my Crackberry.

    As far as apps not responding quick enough, I have some colleagues in their late 20’s, early 30’s who are more impatient than I and start clicking all over the screen or on a button, thinking the app isn’t responding. It’s all on what we are used to.

    The curiosity will be how the 30-40 year old folks now will handle whatever new technology is rampant in their senior years.

    1. Melanie

      Thank you, Brad! I’m a 61-yr. old tech writer and editor with more than 20 years’ experience in the field.

      And Roxanne, at least somewhat old dogs can learn new tricks! :)

      OK, so I will admit that I don’t like reading large amounts of text on-screen. (It’s also not as good for catching errors….)I also prefer to do my Web searching on a PC, not a cell phone. And I like to read actual printed books!! :-0

  6. Alistair Christie

    Rhonda’s comment reminded me of my Mum when she was learning to use her laptop. She used to worry about whether she should single-click or double-click on things because she didn’t want to do the wrong thing.

    I found it a strange thing to worry over, and to me it was so intuitive when to single-click, when to double-click, that I had to stop and think out the principle behind it: basically that you should only ever have to double-click on something that’s selectable – i.e. where a single click selects it and a double click does something more active (like in Windows Explorer where you can single-click a file to select it or double-click it to open it).

    It was a useful experience to realise that something to which I never gave a second thought – but just did automatically – might really trouble someone else and need explaining.

  7. Roxanne

    It’s hard to teach old dogs new tricks. I guess that applies to seniors when you first teach them how to use a computer. It may be hard at first but all you need is patience.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>