Audience Analysis

From the Tech Writing Trenches: User Analysis

By Fran Sullivan

I was so excited to start my project. It was the first release of software that would need new documentation, no updating ten-year-old manuals or five-year-old help systems.

One of my first priorities was to learn about the expected users or audience. What was the user like? What work would the user be doing with the software? Where would the user be working? Unconsciously, I started forming an opinion of the user based on my own skills. I knew Microsoft Windows; they would know Windows. I knew how to use help systems; they would know how to use help systems. I didn't realize how wrong my assumptions were until I actually met users and watched them operate the software.

My first deliberate step in learning about the user was to ask the software developer. I inquired about the typical user's educational background, technical background, and knowledge of the English language. I was assured of the following:

• Users had high-level degrees in electrical engineering.
• They were familiar with programming in Visual Basic at the developer's level.
• They knew how to use Window applications.
• Despite our international audience, users had a firm grasp of the English language (because English is commonly used in the software world).

I was skeptical, very skeptical. Although the software developer had been a user before he became an engineer, I just did not believe that every user in my audience was as skilled in the subject matter and programming as the developer led me to believe.

My next deliberate step in learning about the user was to interview the verification engineer who happened to also train our software users. His was a very different story. In recent years, the education level of our users had decreased. Rather than users having high-level, four-year degrees in electrical engineering, our users were being promoted from the manufacturing floor and had lower-level, technical degrees. Our user community was beginning to include more and more skilled technicians rather than college-educated engineers. In addition, neither the skilled technician nor the college-educated engineer would know how to develop software and write spin-off applications that could effectively use our systems.

My search for user information continued with the training department. I interviewed the trainers for our products. They see the users in classes throughout the year, and they confirmed that less-skilled users were currently entering their classrooms, more so than four or five years ago.

My final step in constructing a profile of the user was to work as a teacher's aide in a training class of our internal users. Although these were internal users, they were representative of our external users with one exception: they were more skilled. It was in this class that I really learned that the user was not like me or like the software developer. I know this should have been obvious, but sometimes it was not.

The class that I observed was all men from around 30 to 60 years old. I am a woman and forget about the age range. All of a sudden, I was reminded of color-blindness and started to think about which colors were used in software and online help. I also started to consider learning styles, how easily would this age range accept online information versus hard-copy manuals.

In addition, as I watched some users fumble with the mouse and select items on the screen, I learned that some were just coming from Unix systems and did not have the Windows applications experience that both the developer and I had anticipated. And, when I asked users about scripts and their knowledge of Visual Basic, they stared at me as if to say: "That is what your tool is for?" Again, another expectation shattered.

Finally, in the classroom, I learned that international users do not all understand English on the same level. Users were from France, Italy, China, and Germany. After meeting them and answering their questions about our application, I realized that some were more proficient in English than others. I was pleased that I had used internationalization guidelines in writing my help system.

In conclusion, we need to remember that the user may not be like the writer, the developer, or the software trainer. Meeting users will provide you with valuable insights that will improve the documentation and help systems that you write.

Fran Sullivan is a technical writer at Teradyne where she designs and writes online help systems and end-user manuals. Fran can be reached by e-mail at Frances.Sullivan@teradyne.com.