design of help files

28 Jun 2010 - 8:58am
4 years ago
3 replies
566 reads
claudia borges
2009

Hello,

I am looking for and thinking about what would a online help file need as interaction to be good help files.

Obviously in an ideal world, a system would not need help files if it is 'well design'. But experience tells even though a system is well designed, there is always people that of want to know more or would like to have more support to use the system.

What would you consider a good interaction for online help files? Do you have examples of good practices?

Thank you!

Claudia

Comments

28 Jun 2010 - 9:25am
penguinstorm
2005

Good search results.

28 Jun 2010 - 4:05pm
Barbara Ballard
2005

We ran into that problem a couple months ago, and didn't find a lot of information available. So we wrote something.

http://www.littlespringsdesign.com/blog/blog/2010/02/22/best-practices-in-interactive-help/

~~~~~ Barbara Ballard __ president — Little Springs Design __ curator — Design for Mobile __ author — Designing the Mobile User Experience @barbaraballard barbara@littlespringsdesign.com 1.785.838.3003

Come join us at http://www.design4mobile.com/ Chicago 20-24 September

On Mon, Jun 28, 2010 at 11:38 AM, claudia borges wrote: > Hello, > > I am looking for and thinking about what would a online help file need > as interaction to be good help files. > > Obviously in an ideal world, a system would not need help files if it > is 'well design'. But experience tells even though a system is well > designed, there is always people that of want to know more or would > like to have more support to use the system. > > What would you consider a good interaction for online help files? Do > you have examples of good practices? > > Thank you! > > Claudia > > (((Ple

29 Jun 2010 - 12:07am
Dimiter Simov
2006

Barbara has summarised the essentials quite well. I will add a few things:

Make the help easy to find. Most people are used to applications having help. For a web application, we made an 'experiment'. We hid the link to help in a form that users open from within a Support & Feedback form, which theopen by clicking a Support & Feedback link. Our rationale was that nobody really needs to use help. We also have context-sensitive links to help from various places in the app. The logs show that users are visiting help. The most visited topics are the ones to which we have context-sensitive link. Some users complain that we do not have help - they are not recognising the Support & Feedbacklink as leading to help.

Build the help as a separate website complete with homepage, hierarchy, navigation, search, and so on. You would want your users to be able to find their way through help.

Organize the help in two ways: by user tasks and by application structure. Users who do not know your application will use the task-based entrance. Users who know the application will prefer the task-based entrance. You can never predict all user tasks nor can you guess how people will formulate their tasks - for example, a person who wants to use bold but is not familiar with the term "bold" and is guided only by the appearance of the bolded text might look for "darker text", "stick out", or "thick letters". The application-based approach will cover these cases - for example, the help on the comments of IxDA website might have a set of topics on comments: Adding, Editing, Deleting, Formatting, Subscribing.

Make your content granular. Try to keep every topic on a separate file or page. Most of the time (my guess is 99%) users need help for something very specific: how do I set my browser to accept cookies, what does that checkbox do, where was the Disable rich-text link. So they need a topic that answers their specific question. If you give them a topic that answers their question and 7 more, you are making things harder. Compare Google help and Microsoft Office help. Google stick to one topic per page while Microsoft tend to pile several related topics into a single very long page.

Each topic must be complete. It is too easy to skip 'obvious' steps and information. Unfortunately what is obvious for the author is not always obvious for the reader. Do not assume that readers will now how to open the Settings box or where the Post comment link is located.

Provide a good search or/and an extensive index. Again, compare Google help and Microsoft Office help. From my own experience, Google help has an excellent search and Microsoft Office help has a sloppy search and no index. For me, it is much easier to find thing in Google help than in Microsoft help.

These are just a few guidelines. Writing help is a craft of its own. You can check the Society for Technical Communication website for resources www.stc.org.

Dimiter

Syndicate content Get the feed