What we do and all that!

[Damien Braniff <Damien_Braniff -at- PAC -dot- CO -dot- UK>]

This thread about "what is a document?" and "it's more than grammar" have got me
thinking about what we do, or rather about how we describe what we do (I include
myself here!!).  We're all communicators and yet we seem to find it difficult to
put into words exactly what do - is it because it covers such a broad spectrum?
that it's different for everyone and so can't easily be defined?  Or is it a bit
like "faith" - you KNOW what it is/means (at least to you) but find it difficult
to verbalise?  Or perhaps it's we've become so used to blank stares when we say
what we do (getting better!) that we've got into a rut spewing out the simplest
possible explanation - we do the instructions for computers, video recorders or
whatever.  Perhaps it IS the sheer breadth of what we cover that's the problem
but as communicators we should be able to come up with a workable definition
that covers us all that we can embellish to meet individual requirements.
Anyway, here's my 2 pennies worth!

To me the writer is really a surrogate user - we are, or should be, the user's
representative in the scheme of things as the real user hasn't (usually) any say
in the development  unless a company has really done a good job and run focus
groups etc before starting development.  OK, we're a surrogate user, so what do
we need to do?  As is often the case, "it depends...."  Generally, however, it
means meeting, as closely as possible, the needs of the user - the better we
know the end users and what they want then the better we can meet those needs.
This doesn't simply mean providing a user/installation/whatever manual.  It also
means we should be fighting the users corner at all stages - functionality,
usability and so on.

This leads on to what I think a manual is.  According to my dictionary, a manual
is a book, especially of instructions or information.  This is the traditional
definition and is still the view held by many users - you get the manual out
when you need to DO something and it'll tell you how to do it.   In many
respects this is still what a lot of us do - we provide the information to
enable the user to DO something - switch on, save file, or whatever. In the
broader sense it can be described as an information delivery system (could
include hard copy, online etc. but the end result is still often the same - how
do we DO THIS?  I know we provide lots of "added value" in manuals, background
information and so on but we should only do this when required.  Come on, admit
it, how many of you have read a manual just for the sake of reading it? Not many
I'd think. You're probably like me (and a large proportion of the population)
and dive in, referring to the manual when stuck.

Of course this definition of a manual and how it's used depends very much on
WHAT the manual covers.  Very apt for software products but hardware?  I feel
that it still applies. Generally on hardware (simple stuff) I've read the manual
for connections, warnings  etc. and then off I went.  For larger, more
complicated machines (more dangerous?) there is usually training involved and
the manual becomes a reference manual.

So, to summarise, I think that our job is to provide the user with (all) the
information needed to carry out his/her job and deliver that information is a
format(s) that is applicable to the job.  Anyway, back to some surrogacy!

Damien Braniff
Technical Author
PAC International


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=