When Virginia returned to the workplace from graduate school, she was hired as an independent contractor for a large, privately owned company that was experiencing major cultural shifts and staff reorganizations, a result of its increased emphasis on inter-organizational communication. The company, for instance, had recently updated its internal communications systems, but many older employees, who had been with the company for more than twenty years, were intimidated by computers generally and understood little about computer applications for their work. One of Virginia's projects was to write usable computer documentation that would support these employees' transitions to the paperless office. [Click on right side of photo to advance story.]

In this regard, Virginia planned to use the rhetorical problem solving she had been introduced to in graduate school in a variety of ways. Not only did she intend to use problem solving to explain her ideas, but to learn from others in her projects as well. As she discussed the planning stages of her work, Virginia described how such an approach allowed her to consult with intended users, in this case the older employees for whom she would be writing computer instructions:

Problem-solving is a way to learn, because it makes me get into the users' shoes and understand their perspective before I start to write. I've found that the extra time spent up front is well worth it in the long run because it gives me some insight into the problem at hand, and lets the users in on the writing process.

Given this statement, it is not surprising that Virginia wanted to take time to engage in rhetorical problem solving-to assess the worker's needs before she began documentation work for them and to test the usability of her recommended solutions before they were formally adopted. Neither is it surprising that the company, concerned about the extra money that such consulting time would require, was reluctant to go along with her.

More important than money in this disagreement was a difference in how Virginia and the company viewed workers and the nature of what they did. Having been influenced by the work of audience analysis that rhetorical problem solving encourages, Virginia assumed that office workers have individual needs and complex work styles, which must be acknowledged to produce computer documentation useful to them.

I see myself as making things easier for people in the offices where I work. If part of that means I have to sit down with them and show them how to use a PC before I ever get to the documentation project, that's okay with me.

Virginia's emphasis on contextualization and complexity ran counter to the company's view of "rationalized" work as a seamless series of tasks carried out by a homogenous work force. Company managers did not stop to consider that problems are "problems- in-a-context." In this case, they had little idea of the problems faced by the office workers as they struggled to learn computer skills and to use those skills in their daily work. Thus, well-intentioned office managers ordered computer documentation for workers without being aware of their needs and expected Virginia to produce instructions without determining what those needs might be. What was delivered, Virginia explained, may be exact1y what the managers asked for, but it's not what the users want or need. A manager may order documentation for a member of her staff, but she doesn't do that person's job. There may be a vital piece of information that the user really wants, but unless I go and talk to the user, I'm not going to find out about it..

Learn more about Metis case studies.