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.
<< Some of his ideas are spot-on and any company would be well-served
to implement them. A couple stand out: 1) "The Manual Writers should be
a part of the design team." -- Having the writers involved early can
provide designers and engineers with some good feedback on both
usability and "product" function.>>
It also produces a team environment in which cooperation and learning
from "the other side" occur. I've worked with programmers to help them
design or redesign an interface and create effective labels for the
parts of the interface so they could concentrate on the plumbing. They
found this easier and more efficient than producing a dozen drafts of
the interface, and were duly grateful. Of course, then I had some
issues with the program manager and that ended _that_ brief but happy
experiment....
<<2) "The manual should be activity-centered. Pick the most basic
activities and explain how to accomplish tem.>>
Alan Cooper has written at some length about this concept, but from the
perspective of "personas". Very interesting work, and I'm currently
trying to adapt it into a presentation I'll be giving to STC Montreal
in March. Cooper has considerable street cred because he's both a
respected programmer and a sought-after design consultant who has a
record of simply making things work. Moreover, he picks up on some of
Norman's early work (the wonderful _Psychology of Everyday Things_) to
design products that work the way people want them to work rather than
forcing people to change how they work.
<<However, some of Nelson's suggestions fall into the "utopian" or
"fantasy" realm, IMO:>>
"A man's reach should exceed his grasp; else what's a heaven
for."--Robert Browning. We achieve utopia by striving for it, conscious
all the while that we may never attain that goal. It's the striving
that makes things better. In that context, allow me to play devil's
advocate for a moment:
<<1) "Ideally, the manual is written first, aimed at being short,
simple, and understandable. The designers and engineers help oversee
the writing, for when the manual is complete, it will serve as the
product specifications that they will follow. Therefore, they must buy
into the design from the beginning." -- This is impractical and
unrealistic.>>
Actually, it's neither. Architects build houses in precisely this way,
and the software/hardware design business would be more effective and
much less prone to error if it adopted an architectual design model.
Instead, the current process is more like the following: "Let's build a
house. With three bedrooms. No, two. No, four. No... two bedrooms and
two office spaces with folding cots. No, forget about the cots... let's
go with Murphy beds. Yeah! And let's use Sealy mattresses. No, how
about tempurpedic foam? Yeah! No, wait... how about water beds?
_Murphy_ water beds! OK, let's tear out the walls and install plumbing
so there's no messy garden-hose business each time we need to drain the
bed. Hey... we could install a drain in the bottom of the bed and use
it the water for emergency fire suppression! (We'd automate that of
course, since we can't leave the decision to the user. So what if there
are occasional accidents?) And if we recirculate the water, we can do
heat-recovery in the house!"
Yeah, that'll work. Never mind that they forgot the bathrooms, never
bothered asking how many people will live in the house, and never
considered usability requirements such as separating the master bedroom
from the rooms for the kids to give both the adults and the kids some
space and privacy.
<<The next time a team of designers, developers, and engineers winds up
completing a project EXACTLY as it was designed, conceived, and
envisioned without any additions, deletions, or changes will be the
FIRST time that has ever happened in the history of product
development, dating from the invention of the torch (fire on a stick)
to the present microsecond.>>
Though I have some sympathy for this notion, the main reason that
software projects fail more often than they succeed is precisely
because managers have bought into the notion that it's impossible to
know what you're designing for when you start. Moreover, they believe
that products are sold based on features, not usability, and that the
more features we build into each release, the happier users will be.
Both opinions are a load of crap. Design for discrete targets and
you'll hit them; design for a constantly shifting target defined by the
cool idea of the day and you get the current chaos: unusable,
bug-filled products that ship late and require dozens of patches.
It's not hard to figure out a core batch of features and design so that
version 1 supports those features elegantly and effectively. If you
know that there will be two additional core sets of features that are
not essential, but that will certainly be useful at some future point,
you design version 1 to allow those features to be added... just as the
architect can leave room to add a wing to a house if they know that
this is part of the user's eventual goals. The hard part is
disciplining yourself to accept that core set of features, and put off
the cool but nonessential stuff for a future release.
<<2) "Test the manual with people chosen to match the intended user
community. How do you test a manual before the product is even
designed? The manual testing should be done in conjunction with the
first design tests, using the rapid-prototyping techniques used by the
your Human-Centered Design team. They don't do rapid, frequent
prototypes? You have a bad team--change it." -- Again, this is pure
fantasy. You can't test something before you have a prototype, and you
can't have a
prototype until you get a design agreed upon; and the minute you allow
users to be part of the process there will be changes because everyone
will have neglected to think of something the end user wants or
needs.>>
Cooper's work shows exactly the opposite. It's trivially easy to create
a rapid prototype once you've built a design spec. Indeed, I've got an
article on how to do this with inexpensive tools (Powerpoint and
Dreamweaver being two) coming out in January from STC's Information
Design SIG. The goal of working with users is to find out whether
you've guessed right and met their needs with the prototype. If that
proves to be wrong, you adjust the prototype until it meets those core
needs. You don't start building anything before you know what you're
building.
<<3) "Get rid of the lawyers, or at the least, put their required
warnings in a separate booklet or Appendix..." This will never
happen because of the need for companies to protect themselves from
liability. As stupid as it may seem, if you neglect to put the warning
that one shouldn't use a hair dryer in the bathtub in the main manual,
in a conspicuous label on the product, and on the packaging, those same
lawyers you fired will escort that one idiot client who thought drying
his/her hair in the shower was a good idea to court against your
company and will probably win.>>
Norman's early work provided an elegant discussion of how to design for
error and failure. Understanding how things will be used, and the fact
that "to err is human", means that you can design to eliminate obvious
failures or make failures "inexpensive" when they do happen.
For example, why not build an effective ground-fault interrupter into
that hair dryer so it's impossible to electrocute yourself? Why not
build takeout coffee cups with simple swinging valves that seal when
the cup tips? Why not automatically save a copy of all deleted files
for 2 weeks and offer a "recover old files" option directly in the
software's user interface? Because that requires us to think about how
people would use the product, and apparently that's more work than
hiring a fleet of lawyers to protect us.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
