RE: User research

["Giordano, Connie" <Connie -dot- Giordano -at- FMR -dot- COM>]

I want to emphasize some of Sean's excellent points with exclamation points
and underlines!  If you are doing user research, you are not looking for
feedback on the documentation, you are looking for feedback on how the
product gets used.  

Documentation is part of the product, not a separate product or its own
goal.  As I completed several major projects that included major redesigns
and rewrites in the last few months, I have finally convinced development
and management folks to completely reconsider the stock approaches.  For
some of our products, manuals may be the way to go, for others on-line help
works well, and for still others we need to take the EPSS approach of
building in coaches and tips. What works for the users of one product will
not necessarily work for another, and you need to understand the user and
the product in order to determine that.  And standard responses of turning
the doc into on-line help or vice versa doesn't necessarily work too well
either. At least not in my experience.

For one of our really complex products, we completely redesigned on-line
help, and totally dropped creation of a manual.  The users are smart
portfolio managers whose primary goal is to make lots of money for their
clients by trading securities.  They do not sit at a computer with a wire
bound user guide in their laps.  They use laptops and cell phones and move
fast.  And they're smart and arrogant as all get out.  So we redesigned the
help system to provide multiple points of entry to the reference stuff they
need for creating lots of intricate calculations, how and why to customize
functions, and the overview/step-by-step instructions that are most useful
to new users.  We don't include the intricate cut copy paste click
instructions any more, but general steps for using a function.  And we used
real PMs to get feedback that told us what was missing-e.g.. How the choice
of investment strategy affects how they use the tool.  Worked
extraordinarily well, but it is absolutely the wrong approach for my data
entry/mainframe-green screen users of an administration product who wouldn't
know an algorithm from a spaghetti noodle.  They need a manual, they want a
manual and they complain vociferously if there is no manual.  They're
starting to like the on-line help, but it's a slow process to get them to
trust it.

Site visits are ideal, but when you can't get that, try to be lucky enough
to work with folks who will find out this kind of feedback for you.  Our
installation team doesn't ask if they like the documentation, they ask where
the problems are and what additional info they need to work with the tool
the way they want to...  

I trained those installation folks good didn't I?  :)

Above all, remember that documentation (I really prefer user support, since
I don't write all that many traditional docs any more) is integral to the
product and its support, not separate from it.  What you discover from user
analysis should benefit not only the user support, but the product design,
marketing and development.


I guess that was my every-six-months-or-so-rant on designing Product not
doc... I'd best step down from the soapbox now.
Regards, and good luck defining your users!

Connie P. Giordano
Senior Technical Writer
Advisor Technology Services
A Fidelity Investments Company
704-330-2069 (w)
704-330-2350 (f)
704-957-8450 (c)
 
 "You can't build a reputation on what you are going to do."  - Henry Ford 





-----Original Message-----
From: Sean Hower [mailto:hokumhome -at- freehomepage -dot- com] 
Sent: Wednesday, January 15, 2003 11:43 AM
To: TECHWR-L
Subject: RE: User research




Hi.

Someone already posted a very good outline of how they went about their
audience analysis. We're currently conducting audience analysis. Email me if
you want some details about what we've done so far and where we're planning
on going.

May I suggest you don't even bother with surveys. No matter how well
designed, you rarely get the feedback you need and want. To really get at
your audience, you need to ask open ended questions, and those give anyone a
chill when they appear on a survey. :-) Go with interviews and site visits.
Luckily, you can usually combine these two efforts. Ask open ended
questions, and try to observe your audience members while they're using the
product. Avoid asking questions like "Do you use the documentation?" "How
often do you use the documentation?" and so forth. Instead, ask questions
about what they do during their day, how the tool helps them get their job
done, what sorts of problems they encounter and so forth. This will give you
an idea of their needs, which you can later build into user profiles
(personas).


Also, take a look around your company. There might be information in other
departments that you can use. Check out training, customer service and
marketing for starters. You can get an idea of common issues from the first
two. Your marketing team might have target customer profiles they use (the
worth of these profiles may be anywhere from a waste of time to a starting
point for further research).


As far as other resources:

Try "The Inmates are Running the Asylum" by Alan Cooper. ISBN: 0672316498
This is sort of a critical analysis of the software industry. It's geared
towards product design, but it does discuss (eventually) conducting user
analysis and creating personas, which are characters you create as a
guideline for your design. You can adapt the process he outlines to audience
analysis for your docs.

[snippage]


Finally, can I just say that nothing beats a site visit. My entire
perception of our audience changed with one visit. And that was an informal
event. :-)

Hope that helps.



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