TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Doing new things new ways From:"Bonni J. Graham" <bgraham -at- ELECTRICITI -dot- COM> Date:Wed, 22 Jun 1994 16:10:04 PST
One of John Brinegar's scenarios asks:
*****
(3) Marketing consults with a major customer to identify a new
function the customer needs in a software product. Marketing writes a
requirements document, engineering interprets it as a specification,
engineers develop the new function, and it is delivered to the
customers. When the major customers' employees get it, they say,
"What is this? I can't use it? It doesn't do anything I need!"
Is it possible that anyone along the development chain didn't
understand what the customer really wanted? Could technical
communicators have contributed to the development process?
***
I've been through this from the other end. How my company handled it was
to send the human factors expert and I to a major client site. There, we
interviewed (in as much depth as two days would allow us) the five main
user groups, i.e., the "major customer's employees". We were able to
identify some major discrepancies between what the major client's
management thought they wanted and what the actual users wanted. We were
able to at least present these findings in the design process. I won't go
into what happened after that, because (more than a year later) it still
makes me angry.
That is, however, how I would propose involving the tech writer in this
situation. We're trained (as are human factors experts) to figure out
where people are misunderstanding the product and to figure out ways to
address it. Some of the problems really were "doc" problems in that they
could be more easily solved in the documentation than in the program. If I
had not gone to the customer site, I would have had no way of identifying
these problem areas.
Sometime the miscommunication is lower down the food chain at the client
end -- and there's no way to find that out except to do extensive user
interviews.
B.
Bonni Graham
Manual Labour
Director, Region 8 Conference
bgraham -at- electriciti -dot- com