Re: Research on software help

From my personal experience running usability studies:

- people get really pissed off when "help" simply rephrases the interface e.g. "under the file menu, you will find..."

- people are usually looking for "how" to do something, rather than an explanation of the UI, especially tips, tricks or trouble-shooting

- it takes only a few (usually only one) bad experience with a piece of unhelpful help content for the user to stop using help altogether on that product

- more technical users are, in my experience, more likely to persist with a help system or online documentation than consumers, because often the tasks they are performing require specific and correct actions and errors can have huge impacts; they also annotate and copy over good, useful help content - to an internal resource, such as internal wiki

- a great way to get feedback about your online help/documentation is to  include a brief online survey incorporated into the help/doc system, along the lines of:

   1. How helpful was this topic (then have a rating scale)
   2. What were you looking for? (open-ended)

  This feedback helps to inform you what parts of the content are being looked at, relative ratings and match between content and needs. The Sun website has been using this for years to refine their content

I have found perusing forums to be a good way to assess how helpful a product's documentation is - if many users are asking questions that could/should have been explained in the help - likely they are not using the online help or it doesn't provide the answers they need

 - conceptual information is more likely to be printed and shared (and therefore formatted to make this easy), while step-by-step information is more likely to be used "on-the-spot" and has less need for easy export design

Meghan


--- On Fri, 4/8/11, Greg Austin <[email protected]> wrote:

> From: Greg Austin <[email protected]>
> Subject: Re: [BayCHI Discussions] Research on software help
> To: "Cate de Heer" <[email protected]>
> Cc: [email protected]
> Date: Friday, April 8, 2011, 5:19 AM
> When Help is preconceived, then
> usability is not. If one needs to rely on Help to explain
> the communication that is intended by the interface, then
> that interface is wrong, since the functionality is not as
> the target audience expects it. Therefore, users have not
> been studied well enough.
> On Apr 7, 2011, at 10:58 PM, Cate de Heer wrote:
> 
> > Hello,
> > 
> > I'm interested in any data on how users (end users and
> developers) access and use help documentation. In
> particular, I'm interested in the following:
> > 
> > _ Expectations or results when users encounter help
> documentation on the developer's website or via a search
> engine (I'm familiar with studies from 10 or more years ago
> indicating low user expectations from the documentation in a
> software help menu)
> > 
> > _ The success of different approaches to information
> architecture for online documentation; for example,
> self-contained, one-page topics versus the longstanding
> "help manual" model with several levels of hierarchy
> > 
> > _ Any differences between approaches that work well
> for end users specifically or for developers
> > 
> > Cate
> > 
> > 
> > . . . . . . . . . . . . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . .
> > The real technologybehind all of our other
> technologiesis language.
> > Norman Fischer
> > _______________________________________________
> > This is the BayCHI Discussions mailing list, [email protected]
> > To change your subscription options, or to
> unsubscribe, visit http://baychi.org/mailman/listinfo/discussions
> 
> Greg Austin
> [email protected]
_______________________________________________
This is the BayCHI Discussions mailing list, [email protected]
To change your subscription options, or to unsubscribe, visit http://baychi.org/mailman/listinfo/discussions