User Analysis Preparation and Planning
Before the user analysis inquiry begins, considerable time must be spent planning. Barker identifies the following guidelines for conducting a user analysis:
User Analysis
The purpose of user analysis is to study the user in the context of his/her work environment to see what tasks the user performs with the software while at the same time recognizing the cultural differences between you and the user. The process of user analysis involves asking questions and determining how the answers should be applied to the design of manuals and help systems. The following items describe the questions to address throughout a user analysis.
- Tasks and activities the user will perform. “Learn the activities associated with his or her type of work.” [142] Look for tasks unique to the user’s workplace, tasks that require more than one software program and/or information from data resources, and tasks that require communication with other people.
- User’s information needs. Expand the analysis into other work activities and roles users must participate. Find out what information the user needs, origin of information used (Internet, databases, trade magazines, etc.), and how the user communicates.
- User’s work motivations. Try to tap into how software is used to help satisfy work motivations. According to Barker, “what motivates users professionally will also motivate them to do well with software—to assemble interface elements and basic operations into meaningful sequences leading to an objective.” [147] Tables 5.14 identifies sources of workplace motivation, and Table 5.15 suggests how to employ the motivational information in manuals.
- Level of the user’s computer experience. Users bring a wide range of computer experience to each new program and so require different levels of support.
The novice computer user typically experiences anxiety with new technology and is generally distrustful of manuals. The novice user would prefer to be told what keys to press rather than self-exploration of the program.
Experienced users view software as a tool and have definite preferences as to how they want to learn new skills and programs. The experienced user understand the value of manuals and use online help systems more readily.
Expert users often work in the software industry, so they are confident with technology and can troubleshoot effectively. Expert users learn new programs easily but will consult a manual or online help.
Table 5.16 describes each of the three types of users and generalizations about documentation preferences of each type. - User’s knowledge of the program’s subject matter. The level of knowledge a user has about the subject matter of a program will determine how much background information to supply in the program. For instance, an accountant would probably need less background information for a tax program than the first-time tax preparer.
- User community. Within organizations some type of official group (who Barker labels a community) forms whose purpose is to support software issues. User analysis should “investigate two things: the user groups that your users already participate in and your user’s willingness to join groups for mutual support.” [153] Examples of user communities include help forums, special interest groups, newsgroups, user groups, and web resources.
- User’s learning preference. How does your user prefer to develop expertise with the new software? Generally, a user will learn with the help of an instructor, learn with the help of a manual, or learn through the computer. Consider how computer experience will determine learning mode. For instance, a novice computer user will more than likely prefer to be taught by an instructor rather than use a manual or computer assistance.
- User’s usage pattern. “Usage pattern refers to the interaction of users with programs over time.” [164] In other words, how many features does a user learn or regularly use when using new software. Three main usage patterns exist: regular, intermittent, and casual usage. Knowing the usage pattern assists in developing better manuals and help.
Hood/Carlson
13 comments:
Lori and JJ, thanks for your post. This was a chapter that was filled with information and it could have been easy to post a lot more here. Thanks for summarizing the chapter in a brief and understandable manner.
It seems to me that this chapter, of all those we've read thus far, is probably the most critical. User analysis is the hallmark of technical writing. If the technical writer's message doesn't resonate with the audience the document is doomed. You could have the most efficiently planned, designed, and written document, but if if doesn't address the audiences needs, expectations, and skill level it is not going to be effective.
That said, It seems that after reading this, effective user analysis is certainly a process that requires considerable planning and work. Through previous study of rhetorical theory, I had good idea of what audience analysis was, but I have a different view of the process after reading this chapter.
At first I was surprised by how long this chapter was, but after thinking about it and reading it, I understand why. User analysis is such a key to technical writing. If you are not analyzing who will be reading and benefitting from your document, then there is hardly a point. Also, because task orientation is Barker's main approach in this textbook, it makes sense that he would cover user analysis to such a great extent.
Something that comes up time and again in our tech comm classes is the tension between what we, as technical communicators, would like to be able to do and what our organizations have given us funding to do. A consistent theme is that many companies give short shrift to the documentation process. Other companies value it but still do not provide enough funding to "do the job right." The rich detail presented in this chapter reinforces the idea that creating high-quality documentation is neither a quick nor an inexpensive proposition. To do a complete user analysis requires time and money.
I was happy to see some resources in this chapter for those technical communicators who do not have extensive resources at their disposal. The resources for professional behaviors on page 123 seem especially useful. I did not know that these resources were available, and I'm glad that Barker pointed them out. It seems to me that resources like these would be useful even for documenters who have access to real users, if only to help prepare them to understand their users' work situations before they go to observe and interview them.
Like Mary, I was originally surprised at the length of the chapter, but after having read it could not think of anything that the chapter could have left out, yet still remained as complete as it is, and as it should be. At this time, the most important thing I took away from the chapter were the definitions of skill levels among computer users. As we begin our usability testing, this is something our teams are definitely taking into consideration, and I think these definitions will help us to more accurately determine our tester's levels of comfort with computers.
I really appreciate the depth of this chapter, especially now that we're getting into the heart of our group usability assignment. For my part, I'm very curious about the specific users, people in healthcare, of our project. They have well-defined jargon, needs, education level, etc. that makes a good user analysis important but that also makes it tougher for someone who isn't familiar with that specialization. This chapter will be helpful in trying to define what is most important to our intended audience.
Thanks for the summary! This is good stuff, consider the audinece. But I wonder how realistic in-depth user analysis is in the workforce. Usually, there is lack of time/funds and the tasks suggested in this article might be viewed by management (and users alike) as disruptive of the everyday activities. Shadowing might be OK, as long as it is not intrusive in any way.
I think this chapter gets at the heart of technical communication--that we must always be advocates for our readers. I think the depth of this chapter resonates how important our users/readers really are in the technical communication process.
Thanks for a great summary.
I had a similar reaction to some of the other comments. This information is great, but reality is usually different from the ideals listed in the book. I have been involved in several big writing projects in the last few weeks. Time is almost always the main issue that drives the project. There is almost never much time provided to do the pre-planning that is always described and recommended in the book. I wish that wasn't the case.
This was a good time to have this chapter since we are doing our usability projects now. The audience is very important for a tech writer, because if he/she doesn't know the audience then the document is useless. However, saying that, and not being totally converted to tech comm can one document be written for all levels of expertise if the audience is going to be mixed?
Extensive chapter and the group did a good job at summarizing it.
I also found the information from this chapter particularly sections on planing the interview, observation guidlines and questionnaire writing useful as we get into the usability project in our class.
Even if in the "real world" we do not always have time to follow these guidlines thoroughly, I find them valueable and they educate me about technical writing process.
As pointed out by several other people, there can be conflicts between the real and the ideal in terms of how much can be done to understand the users' work patterns.
On the other hand, even if it's not possible to "shadow" users on the job, we can still keep in mind the important issues raised by Barker in this chapter. Perhaps a phone call to several users would suffice, asking, "How do you usually do this?" and "When do you do things differently?" and "What would you change if you could?" Not ideal, perhaps, but maybe a way to figure out some user needs.
At the end of the day good technical writing, or business writing is always about knowing the user or audience. I like the way Barker broke down users into three categories: novices, experienced, and experts. Each has a different preferred learning style, and therefore, each must be considered a different target, or segment with unique messaging. Reading this chapter reminds how anthropologists and psychologists are attracted to the field of usability research. At Cargill, one of our usability experts is a former clinical psychologist.
I agree with the comments that everyone else has stated here. Understanding and analyzing the audience is key. Without the audience, we wouldn't have jobs, so I think it's important that technical communicators keep that in mind - just realizing that the audience is the most important part of writing - I think all the work we do to analyze and test our writing (e.g., the usability study) is very important to help us relate to the audience and determine what their needs are as far as writing is concerned.
Post a Comment