RE: Ideas in Motion

["Mike Starr" <writstar -at- wi -dot- net>]

I'm not suggesting the companies I've dealt with have no focus on quality;
it's just that their primary motivation is marketing-driven. If the trade
show starts on June 11th and the whole industry trots out their latest and
greatest at the trade show, then you'd better be ready to dazzle 'em with
your new features and functionality. And if there are three or four
different trade shows a year, then the process repeats itself. It's good,
old fashioned competition and these companies don't disappear into the mud.
The one that develops the best product brings home the bacon.

As I said in my previous post, I can dazzle the bosses and the users with
one hand tied behind my back. Why?? They don't know enough about what
constitutes good documentation to be dissatisfied with substandard
documentation. I work very hard to produce a usable document. Do they go
through usability testing?? Nope. Does that mean they AREN'T usable? Nope.

I'm not suggesting that usability testing is not a good thing. It is. A
small sample can identify problems if, as you say, a fair portion of the
testees stumble over the same crack in the sidewalk. But if they don't
stumble, that doesn't make it necessarily good usability design. It only
indicates that the specific users were able to navigate to the required
data with a minimum amount of fuss. If the designer of the usability
testiing doesn't have a clue what the product is and how to use it, then
the usability testing can't be designed to identify flaws in the real-world
use of the product. The real usability testing in my opinion involves the
user base and tech support. If I've done a good job, inbound tech support
queries should be reduced. That's what really matters to me.

Your example of Bill Gates being horrified to see a user running the mouse
down the table leg illustrates my point... what changes did they make based
on that user? I'll bet they didn't make any, and rightly so. Nor should
they have made any changes to reflect the user who called tech support to
ask for a new cup holder.

Mike

Mike Starr - WriteStarr Information Services
Technical Writer - Online Help Developer -  Technical Illustrator
Graphic Designer -   Desktop Publisher   -       MS Office Expert
Telephone (262) 694-0932 - Pager (414) 318-9509 - mailto:writstar -at- wi -dot- net

-----------------------Original Message-----------------------
From:  Tim Altom
To:  Mike Starr;TechDoc List
Date:  3/13/2000  6:27 AM
Subject:  Re: Ideas in Motion

If metrics won't help you do your job, I suppose it depends on what you see
as your job.

If your job is, as you say, to have something approaching communication
ready when the boxes ship, then you have obviously done your job. The
client's emphasis isn't on quality standards, apparently, but on
desperation. Many such companies exist, especially in high tech. If you
didn't produce for him, somebody else would be glad to take his dollars to
do so.

We see things a bit differently here, and that's why we have trouble working
for such people. In our experience, the "bang it out by the due date"
standard is only one of many problems on such a job. Such a client doesn't
regulate his projects well, either, so he likely changes his product
abruptly, but doesn't forgive lateness of the manual. This is a classic
level one or two operation. Most such disappear into the mud, and
inattention to the details is a common reason. My 12-year-old thinks the
same way when he dashes out of the bathroom after using all the toilet
paper, making a hasty promise to himself to change it later. In a company
that has NO quality standards, the culture won't support usability testing.

As to the hoary quality standard of "I talked to a couple of users and they
liked the manual", you find during testing that even users who profess to
like something often won't or can't use it. I say again, with emphasis...*If
you ain't tested it, you don't know.* I realize the father of the manual
finds it hard to imagine, but just because there's an answer in
there...somewhere...it doesn't mean the damned thing is usable.

And speaking of testing, you may think it counterintuitive that a small
sample is good enough, but remarkably, it is. You're not amassing
statistics; you're pinpointing problems. It doesn't take a statistically
valid sample of joggers to find a piece of ragged pavement. Run eight of
them over the patch and if six of them stumble, you've got the problem
located. This is troubleshooting, not reproducible research. The story goes
that in the early days of testing Windows, Bill Gates was horrified to see a
user in the test lab run a mouse down a table leg trying to reach the bottom
of the screen. It didn't take fifty or a hundred users doing that to horrify
him. And with good reason.

A "heuristic method", by the way, is basically saying "my initial best
professional guess". It does not mean "hunches". It means projections based
on experience, education, and judgment. It is NOT meant as a stopping place,
but as a basis for further cycles of refinement. If you make your best
guess, write it, then ship it, you're not working heuristically.


Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar Method(TM)
"Better communication is a service to mankind."
317.562.9298
Check our Web site for the upcoming Clustar class info
http://www.simplywritten.com


> Well, having specific metrical targets is a nicety that I've never had the
> luxury of and from what I can fathom of it, they don't help me do my job,
> either. In the world I've lived in, the metrical target has been the ship
> date. The development team keeps coding and I keep on trying to put
> together a document that provides the best possible documentation for the
> user before they rip it from my hands and ship it. I've never been
> completely satisfied with what I've had to ship because there are always
> things that I've wanted to include but was prevented from doing so by the
> ship date.
>