Re: Usability Testing, Technical Writing, and Blurred Lines -- longish reply

[Barbara Karst-Sabin <Phillinion -at- AOL -dot- COM>]

I think those of us who have been in the business for, say, 15 years or more,
have been called upon to do many things that were nowhere near in the tech
writing ballpark.  I have often worked with developers, been a beta tester or
graphic artist.

My most unusual assignment had me babysitting a prototype system with major
problems.  When it stopped working, I had to get on the phone to the
developers, tell them what was wrong, and apply the fixes they recommended
with them on speakerphone giving me instructions for everything from altering
code to rewiring and board swapping.

I guess what I'm trying to say is that the old style tech writer has had to be
a pretty adaptable beast, because it's only recently that the job has begun to
have some fairly structured guidelines.  We did what we had to do to get the
job done.

Newer tech writers probably aren't used to working in that kind of
environment, so they don't have confidence that they can do what might be
expected of them.  Believe me, it may not be in the job specs, but at least
give it a try.  The occasional board swapping or graphic designing makes a
nice break from straight tech writing.

Besides, if you know the product well enough to document it, then you should
know how it works well enough to determine if it's usable, at least in the
short term.  I don't know how it is in other places, but most places I've
worked we had the application, hardware, whatever, there to try out so that we
could better document it's use/operation.  That in itself is a form of low
level usability testing, isn't it?

BJ