Reading from the User's Point of View

As technical writers, we need to remember that the user is trying to get his or her job done. We need to see the task from the user's point of view.

Recently I was helping a friend troubleshoot some issues with the treatment management software used at the social service agency where she works. Staff members were having trouble with closing cases. They had been trained on the software when it was in Beta test but had no documentation beyond the training handout. Newer employees had not even seen the training handout. Fortunately, there were still a few copies of the handout around.

As soon as I sat down with the handout, I understood why the users were confused. Terminology was wildly inconsistent. It used the term button for command buttons, radio buttons, and sometimes tabs. Tab seemed to mean both the tab you clicked on and the screen it took you to. There were dependencies too. Some operations required that other operations be completed first but there was no indication of that in either the handout or the user interface.

The staff were asking "How do I close a case?" The handout presented the available options on each screen (or tab) followed by an exercise using them. Deep in one of the exercises, I found some clues. Turns out certain buttons did not appear unless you had completed another screen that was not necessarily actually required for the worker to close the case in real life. Using clues from the handout and some experimentation, we discovered that there was a simple workaround that allowed you to skip the unnecessary steps and still close the case. All that was needed was a short task-oriented procedure that told the workers how to do what they needed to do in the context of their agency's policies and practices.

Reading from the user's point of view turned out to be a valuable reminder of what it means to write for the reader.