Re: Usability Testing

[Paul Hanson <hanson -at- JORDANSYSTEMS -dot- COM>]

Barbara,

The situation you describe sounds oh so familiar to the company from which
I just left after 3 years of fighting similar political games!

All I can suggest is to develop credibility with your developers. Get a
developer as your "buddy" that respects/understands that you are
representing the user (you have to understand how to use the software to
explain it to the user.) That "buddy", if it is someone with enough
authority (say a senior level person) can then help you when "lower"
developers resist your changes. When they respect your suggestions, and
ultimately, realize you're trying to make the software better, they will
back you up.

It is a tough transition. You will not get every fix into the system before
the error reports come in, but you may catch a lot of them. I was also at a
disadvantage because the software was for insurance companies to use and I
had no insurance background coming into the job, as well as it was my first
writing job out of college. After a year of listening, learning, and
"internalizing" the way the system should work when I would point out
something non-standard on a panel within the software and ask for it to be
fixed, the developer would mutter a little bit less and realize that I was
making the software better. We found it a better tactic to reason with a
twisted "Would you rather have a user send back this problem and have it
reflect on your programming or fix it before a client sees it."

This sort of change does not happen overnight but once the seed is planted,
I found it easy to nurture. Establishing a good relationship with the
developer would be my suggestion.

Paul Hanson
Technical Writer
Jordan Systems Inc.

-----Original Message-----
From:   Barbara Karst-Sabin [SMTP:Phillinion -at- AOL -dot- COM]
Sent:   Tuesday, June 23, 1998 2:32 PM
To:     TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Subject:        Re: Usability Testing

My attempts to query things that obviously weren't going to work were met
with annoyance, at the very best
of times.  Instead, we sat and waited for the error reports to come in
after
publication so that the developers could be forced to iron out the wrinkles
the writers had already shown them.  To add insult to injury, the problems
were categorized as "documentation faults"!

A very strange way to operate, but apparently the entire culture supports
it,
including the customers.  So how do you change it?

BJ