From the Director
Today, I’m sitting in my hotel room overlooking the lake in the center of Helsinki, Finland, and waiting for the rain to stop. The sun was out (sort of-through the cloud cover) at half past two this morning, serving to remind me that it’s nearly midsummer, and I’m not so far from the Arctic Circle. Tomorrow, I’m talking to writers and managers about the importance of working for the users and measuring the quality of our work in user-centered terms. And I’ve already been warned. I find myself worried about the strength of the opposition to user-centered design. It’s not the marketing folks or the engineers and programmers who put up the most determined resistance; it’s the writers. Good, old technical communicators who are quite content to sit in front of their computers and worry about page design and punctuation. No wonder it’s so easy for companies to outsource.
Someone gleefully accosted me at the STC conference in May. She had found an error in the CD-ROM that Wiley ships with my Standards for Online Communication book. She handed me a printout of the screen and, with a pleased smirk, challenged me to find the error. There it was (after some searching-two words with no space between them square in the middle of a paragraph. I wanted to ask her if she had more important work to do than to find missing spaces among several hundred pages of text moved into electronic form. Why was this missing space important enough to print out the screen, carry the page to Orlando, and find a moment right after my talk to tell me about it? And, what am I supposed to do about it? I’ll wager that this writer spends no time at all learning about her readers but plenty of time feeling smug about the correctness of her copy.
I’ve just reviewed an interesting article on designing user-centered information. The authors describe their work conducting a contextual inquiry and the solutions they developed to move information closer to the point of need (right onto the interface). The opposition to their solutions came not so much from the developers but from the other technical writers in the organization. Their colleagues felt threatened by the intimation that their dedication to rewriting the engineering specifications was not meeting user needs. They wanted none of these new ideas, especially if it meant they’d have to get out of their chairs and actually meet people.
Perhaps it’s the introversion. Many of our staff members are serious introverts; they find it a strain to interact with new people. Or, perhaps it’s fear that the job is changing. Many of our staff signed on to an 8-to-5 job with no travel away from home. Getting close to the customer takes effort and time and travel. I’ve had many writers quit their jobs over the years when we asked them to travel because “No one was going to infringe on their personal time.”
It’s easy to blame sales, marketing, or the “powers that be” when visiting customers is suggested. “They won’t let us,” is the litany I hear so often. Although true opposition sometimes exists, the real problem lies elsewhere. We were actively engaged in customer visits a month ago, at a number of customer sites. We invited the writers to come, expected them until the day before-only to learn that “something had come up,” and they had to skip four great days at the customers’ locations. I couldn’t believe it. Not one person in a large department was willing to attend a completely prearranged (by us) customer visit.
Why do you think this happens? Better yet-as managers, what do you do about it? Are you content with having your staff continue to produce information that few need and hardly anyone uses? Are you willing to argue for funding to create enormous tomes of information that are rarely used? How can we continue to justify our existence if we don’t work for our customers but work only for ourselves?
The myth of the user. Technical writers proclaim that they represent the user on the product-development team. But, when we ask-“How do you know your users?”-we get blank stares. Don’t know the users, only claim to. It used to be labeled, “writing for the lowest common denominator.” That’s us-technical writer as lowest common denominator (aka, stupid users).
I need your advice. Do we need to change how we focus our organizations? Do we have the people we need to do the right job? Or, do we continue to perform the job that others assign to us? That is, ticking off the requirement. “Yes, we have documentation.”
Write me soon with your thoughts.