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.
I've never worked on a project that went quite according to Steve
Hollander's recipe:
>1. Sit down with prospective users of a new software-driven system
> to discuss requirements, work habits, etc.
>2. From the above info, draft a complete user manual for the system
>3. Redraft the manual after receiving users' opinions on the "paper
> prototype" in Step 2
>4. Hand the manual to the programmers and instruct them to "make it
> work this way.
The closest I ever came was in implementing an indexing subsystem for
a publishing system (before I came to Interleaf). In that project we
had an 'initial user' from the very beginning, and that user had spent
a lot of time documenting exactly what they wanted out of indexing
software. Their spec was the most important input (although not the
only input) into my spec; they reviewed my spec before we started
work, and they were the primary (maybe only) beta site. I recognize
that that's a far cry from Steve's outline -- and that's the *closest*
I've ever come in 12 years as a professional programmer.
I think Steve's outline is incomplete. My experience is that users,
documentors and programmers all bring something to the design process.
* Users (certainly not all) know their existing systems intimately,
and their existing frustrations; this knowledge makes them invaluable
in finding out what *not* to do, but sometimes binds them so closely
to those existing systems that they can't visualize broad
possibilities for change.
* Programmers typically don't use their own systems, or at least not
the way intensive users do (programming systems excepted, obviously),
so we are often weak on what it feels like to use our stuff. On the
other hand, we probably have a much better handle on what is feasible
than do users, and that's an important part of the design process. If
some feature will take a very long time to develop -- or to run once
developed -- that often needs to be taken into consideration. And the
converse is often true -- features that users imagine to be difficult
to develop or slow to run might not actually be that way.
* Documentors, as people here have observed in the past, sit in the
middle -- filling in a technical perspective for users and filling in
a user perspective for programmers. But they do something more: they
keep the design team honest. There are visionaries among both users
and programmers who see clearly (in their own minds) better ways to do
things. Sometimes those ways really are better -- but sometimes they
only look better because the visionary is "skipping a few steps".
Such a vision might carry the day in a design meeting, but when a
documentor gets hold of it, they'll insist on filling in those missing
steps -- and the great idea might turn out to be less than great, or
at least to need more work.
Obviously these are all stereotypes; people are individuals and bring
individual strengths to any process. But I think the general
observation still applies: shutting *any* involved group out of the
design process makes that process less effective than it could be.
(Of course, there's a lot more to having an effective design process
than just having a bunch of people -- even the right people -- sitting
around a table together... but that's a topic for entire books!)
Ed Blachman edb -at- ileaf -dot- com (or) ...!uunet!leafusa!edb
