RE: User research

["Carey Jennifer (Cry)" <jennifer -dot- carey -at- cdi -dot- cerberus -dot- ch>]

I couldn't agree more with you about the value of doing this - I just
finished a similar analysis. After I discuss the process I used, I'll tell
you a bit about the outcome.

I write documentation for four main groups - the people that sell our
products, the people that install and configure our products for the
customer, the people that maintain and service our products, and the people
that use our products. The set up we have sounds like it may be similar to
yours in that our development group is here in Milan, while our distribution
groups are considered customers and are scattered around the globe. So,
sales and product installation/ configuration/ maintenance and
troubleshooting is done by them.

The first thing I did was ask to attend a training on one of the products I
had documented. While I was there, I asked several attendees if I could
interview them. Everyone I asked was pleased to participate. I asked a
series of questions to understand how their groups were structured and what
the different groups did, along with general information about age,
turnover, training and education, etc. (a survey would have been a better
way to gather this kind of data though). Then I asked how they used
documentation and how well what we provided supported their needs. I asked
if they created any additional documentation for themselves, if they made
notes on their documentation, and if they would be willing to share what
they had done with me so that I could see what kinds of information was
missing or of particular importance. I also listened to the kinds of
questions they asked during the training to get a sense of what was
important to them.  Finally, I asked if I could keep in touch with them so
that I could have direct channels of communcation. 

The next thing that I did was to hold a couple of meetings, first with some
visiting salesmen, then with a couple of technical managers. In the sales
meeting, we discussed what happens from first customer contact through to
the close of the sale and what documentation they need to support each
phase. Here we were able to get a picture of the whole process and to
understand the real objective of each document and how it will be used. We
did the same for the technical cycle. The outcome is that I now have a
complete list of documentation that will be needed, I know exactly who will
be using what and why and have been able to make informed decisions about
how they will be organised and delivered. We have also been able to
streamline certain documents to help reduce information-gathering visits to
the customer. We added a few documents and eliminated several unnecessary
ones that had been on our original list.

>From this data I created a document describing the lifecycle of the product
from first customer contact through to the maintenance of the product (it's
software, so disposal of the product isn't relevant in this case). I also
compiled a document outlining the general structure of the binders that will
be shipped with the product. I sent this to the product managers, our
company president, and all the participants in the meetings for feedback and
validation.

I got great feedback from the product managers and sales people (one person
said it was the best thing since sliced bread), and the president asked me
to put it into a format that can be used as a regular part of project
planning.

But while kudos make you feel good for a few days, this work has a much more
lasting benefit. It has made my job go from interesting but peppered with an
element of uncertainty and 'grope time'*, to extremely rewarding and (dare I
say it?) fun (basically no grope time anymore). With the knowledge I have
now, it's easy to create documents that I know will be used and will make a
difference. I know how important documentation is to these groups because
I've met them and they have told me themselves how much they use it (even if
they have to create it themselves). I know who I'm writing for and how this
information will be used. 

I have the support of my boss to do some customer site visits to learn more
about the end-users of our products, and my hope is to reach the same level
of clarity about our operation manuals and users by the end of the summer. I
would ideally like to shadow the installation/configuration/maintenance
process as well, but having direct contact with these groups through
training makes this less critical...

Good luck.
Jennifer

* grope time: that period during the early phase of creating a document when
you are trying to figure out who is going to read it and why, so that you
can decide what information needs to be included and how it should be
structured. This period is generally defined by its periods of blank stares
into nothingness and frequent coffee breaks. 


-----Original Message-----
From: Tom Storer [mailto:tstorer_tw -at- yahoo -dot- com]
Sent: martedi 14 gennaio 2003 10.03
To: TECHWR-L
Subject: User research



We're about to start writing a set of documents to
help our OEM partners program our products'
functionality into their applications. We've decided
we need a much meatier audience analysis than what we
now have, which is basically "tech people."

Although we are a pretty big company, with our major
customers buying tens of thousands of licenses, the
doc department has little history of serious user
research, apart from a couple of questionnaires done
without any real research into how to do it
effectively.

I'd like to hear about how you've done it: what sort
of questions are asked apart from who will use it,
what skills will they have, how will they use it... or
is that all there is to it? Also, any recommendations
for helpful books or websites on the subject of user
research would also be great.

Thanks in advance!

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A new book on Single Sourcing has been released by William Andrew
Publishing: _Single Sourcing: Building Modular Documentation_
is now available at: http://www.williamandrew.com/titles/1491.html.

Help Authoring Seminar 2003, coming soon to a city near you! Attend this
educational and affordable one-day seminar covering existing and emerging
trends in Help authoring technology. See http://www.ehelp.com/techwr-l2.

---
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.