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.
When all they ever wanted was ....but we gave them a tree?
Subject:When all they ever wanted was ....but we gave them a tree? From:Geoff Hart <ghart -at- videotron -dot- ca> To:techwr-l List <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Sat, 15 Mar 2008 10:08:40 -0400
Daniel Ng reports: <<Our customers are factory production workers.
They don't speak english very much other than management. The
management is of course part of a much larger organization. We write
software solutions for their organization and used on the floor. Some
of these workers will need to do some maintenance on the system. I've
been writing books of maintenance and software how to's, help
systems, indexed, just like what microsoft, apple or ibm does, in
that style.>>
It's always important to provide this information because some
organizations do eventually hire experts (or promote them from
within) to administer the systems. These people need the full story,
nicely integrated into a single package. However:
<<I discovered that our project deployment engineers, find it very
hard unusable to teach a factory worker, non-english speaking worker
how to do a few of these tasks regularly when the stuff is all
written and diagrammed in english and maybe chinese and there is
cross-referencing and all that written in a sort of generic manner.>>
The usual solution in such situations is twofold: First, hire a
deployment engineer who understands both the system and the local
language, or find someone already working for you and train them in
the system or the language, as needed. Second, localize the documents
to eliminate the language barrier in the first place. Unfortunately,
that solution isn't always feasible because companies hate to pay for
this. In that case:
<<In fact, all they need is a one page instruction sheet for each
role or responsible. What buttons to press, and the schedule of when
to do that. they don't need to know why or what else they migth need
to do in an eventuality of something different happening. its a moot
point.>>
I call this audience-appropriate documentation: writing documentation
that meets the specific needs of the specific audience. It's a great
idea that it would be nice to do more often. I've done it a few
times, and it's been greatly appreciated by both the support staff
and the users of the documentation. However, two important side notes:
First, this is one of those cases where your engineers should be
designing most of the workflow into the interface. If all the workers
need to do 99% of the time is press a series of buttons in a specific
sequence, this should be clear from the interface: the sequence of
buttons should follow the sequence in which they are pressed, for
example, rather than requiring users to hop back and forth between
sides of the control panel. In some cases, pressing one button should
temporarily disable all buttons that are no longer relevant for the
task that begins with the first button; in software, pressing that
first button should then display all buttons that are usable from
that point onwards in the sequence. And so on. Realistically, it's
hard to teach product developers to do this, but worth trying.
Second, don't assume that all they need is a single instruction
sheet. That's fine so long as everything works exactly as planned,
and so long as the software and hardware function perfectly. That may
happen most of the time for a really well designed product, but even
the best products malfunction or encounter unexpected problems the
designers couldn't account for, particularly in factory environments.
In that case, what will the workers do? In the extreme case, they'll
shut down the factory for one or more days until you can send a
support engineer to fix the problem. You can imagine what that would
cost in terms of lost production. But if you can provide strong
troubleshooting advice and an understanding of how the device or
software works, they may be able to solve the problem themselves.
Just because they're illiterate or uneducated, don't assume they're
stupid. Give them the tools they need to think their way through
problems and things will proceed much more smoothly.
----------------------------------------------------
-- Geoff Hart
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
www.geoff-hart.com
--------------------------------------------------
***Now available*** _Effective onscreen editing_
(http://www.geoff-hart.com/home/onscreen-book.htm)
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
