Re: Are User Surveys the best approach for defining your audienc

["Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM>]

Kelly:

This is written in response to:

**********************
     My department has decided to "better define our end-user".  We are
     considering taking the survey approach. Can anyone make suggestions as
     to some good questions to ask on a user survey? And how can we get
     them to send it back? We've got to start somewhere, but is a survey
     the best approach?
**********************

My off-the-cuff response to that last question is "no."  IMHO, the best
approach to "knowing thy user" is to walk a mile in his or her shoes (or
boots, as the case may be).  I do not mean "observe," I do not mean "hang
around with," I do not mean "conduct a personal interview."  I mean get out
there and BE A USER.  Bend tin, enter data, tune control systems, whatever
it is that your user does, you should do to.  There is no substitute for
this experience.

I presume you can't readily replace a field engineer with a writer, but I
also assume it wouldn't be too hard to learn enough to be some sort of
semi-skilled apprentice for a few weeks or a few days.  Or that you could
learn one particular task that needs to be done (installing an upgrade or
something) well enough to do it under an engineer's supervision.  It's an
eye opener, which allows you to see for yourself what gets used and what
doesn't; observe what information is written down on Post-it notes and
stuck to the lid of the tool case, and discover first hand just how
annoying that "standard" 8.5"X11" binder can be in close quarters.

Management is generally very reluctant to do this because of the time and
expense involved; I had to search across several years and jobs before I
found somebody who believed in the approach enough to actually do it, but
the experience was priceless.  One of my visits started an overhaul of the
type of documentation offered, and another resulted in some major
improvements to previously-unused system documentation.  (There is no
better motivator for a good technical illustration than watching a guy
with 10 years experience go for the wrong set screw, despite careful
written directions.)

Actually, I think everybody in the development community should get this
sort of "up close and personal" experience with their products, but
management is usually even less willing to part with developers/engineers
than they are to part with writers.

If you can't get out among your users, at least spend some time working on
the support line.  Find out what frustrates people and what you have to do
to talk around it.  It's a substitute for a site visit the way TVP is a
substitute for beef, but it's better than sitting back and making a guess,
or relying on second-hand reports.  Remember, a bad day doing is better
than an good day theorizing.

Anyway, once you and some other people in your department have this
experience, you will have some context to ask questions about the things
you didn't observe, or to discover how widespread some of the behavior you
observed is.  Until you have this context, your survey is pretty much a
blind man in a dark room searching for a black cat that isn't there.

Skoal,

Doug                            "Did you really think that you could
ENGSTROMDD -at- phibred -dot- com           conjure up the Devil, and then expect
                                 him to behave?"
                                                --Fox Mulder

***********************************************************************
The preceding opinions and positions are mine alone, and are only
coincidentally related to those of Pioneer Hi-Bred International, Inc.
***********************************************************************