Re: User Questionnaire

["Domaschuk, Rob" <Robd -at- datalogics -dot- com>]

 Hi Barbara,
 
 In my last role as a "User Experience Architect", I did a lot of this. Here
 are a few things I've learned that I use in my tech writing life:
 
 1. Observations beat questionnaires every time - when you can do them. How
 people SAY they work is not always accurate. Only observing them will
 identify this. A perfect example is the whole Fat-Free product craze in the
 '90s. Everyone said they wanted fat-free food, but when CPG companies
 started producing it, it never sold, because people weren't prepared to
 switch from their regular foods. If you can visit a few users (even two or
 three will help), then do it. IMHO, I'd rather visit three people and watch
 them work (unobtrusively) than get questionnaires back from 200 people. I
 can see things that I would never pick up in a questionnaire, such as their
 physical environment (are my docs laid out in such a way that they are easy
 to read in the context of a phone that rings 50 times a day, poor or
intense
 lighting, private cubes vs. open desks, etc.). I can also see how they are
 using the product (great feedback for the development team) and how they
use
 my document (do they really want training manuals when I have been giving
 them reference manuals?). Be prepared for almost anything, and this can be
 very humbling!
 
 So, if you can go out and meet a few people, go for it (this is often
 cheaper than a full-fledged questionnaire). Take an instant camera to
record
 your observations (remembering that you may need to sign their NDA
 [non-disclosure agreement]). Krug's book, "Don't Make Me Think" has some
 great ideas here (and it is fun to read).
 
 2. I like to find out how often they use my product/application. If it is
 once a year because I sell the world's best year-end accounting package,
 then I know I need to create a different doc type than for someone who is
 using my world's best order-entry system 100 times each day. (This is an
 example, my company doesn't create either).
 
 3. As for specific questions, focus on the parts of your product that will
 help/hinder/change the way they work. If you are really interested in
 education levels, get some job descriptions (if possible) from your users'
 HR departments - or ask what the minimum education level is for the
 position. If somebody who never completed high school sneaked into a
 position that requires a Ph.D. in Astro-Nuclear Physics, they probably
 wouldn't give you an honest answer anyway. Besides, education doesn't
 necessarily equal aptitude.
 
 4. Be aware that someone could potentially lose their job if a company uses
 your product(it has happened). Be prepared for that answer on your
 questionnaire.
 
 Okay, finally (and most importantly) have fun! You are doing something that
 a lot of people never get the chance to do. It is a wonderful opportunity
 that will carry a lot of learning for your whole company.
 
 Just one person's opinion....


Rob Domaschuk
Technical Writer, Datalogics inc.
312.853.8337 - t
810.958.2937 - f

"I hear it in the deep heart's core."
      - W.B. Yeats, The Lake Isle of Innisfree

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Planning to attend IPCC 01, October 24-27 in Santa Fe?  Sign up by
October 3 and get a substantial discount!  Program information, 
online registration, and more on http://ieeepcs.org/2001/

  Your monthly sponsorship message here reaches more than
  5000 technical writers, providing 2,500,000+ monthly impressions.
  Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.