Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Background

A well designed interface allows any type of user, beginner, advanced, or expert, to achieve their objective quickly. In most cases, help information contains the description of elements and functions focused on beginner-level users. It allows one to quickly deal with an unfamiliar interface. In addition there are often many "hidden possibilities" which allow a user to considerably reduce time spent to achieve their purpose. The most widespread example of this is HotKeys/Shortcuts.

Other examples include swipe-to-unlock from the notification center in iOS5 and quick select a month daterange by double-clicking the header in Google Analytics ga

In most cases, information on similar features is learned as a result of interaction with/discovery of the interfaces or on web-forums for advanced users.

Question

Are there any rules on creating the help files in such situations and is it necessary to announce hidden functions? And is it possible to provide this information for advanced users while still explaining the basic functions of the application for novice users?

share|improve this question
add comment

3 Answers

up vote 7 down vote accepted

The idea that Help is for beginners is misguided. Novices don’t use help; advanced users do. Novices don’t use help because:

  • We are a victim of our own success. We’ve made apps and web sites that users can use without Help, so that’s what they expect. And, indeed, an app should be designed so that the average new user can be productive without opening help first.

  • Using help is itself a skill. Users need experience with an app to even know where to start with Help. They need to know the terms, architecture, and internal logic to be successful. Instead of searching Help, new users go to colleagues, friends, and family (we’ve all been there, right?). Novices might be helped with brief “Getting Started” documentation, but even that may get ignored.

Help should be written for that reality. Advance users typically use help when they know most of the solution but are stuck on a certain point. Help should concern the advanced details of the system, broken down and organized for easy searching and scanning.

“Hidden” capabilities, such as those effected through drag-and-drop, double-clicking, and accelerator keys, can be highlighted in help in a “Tips,” “Hints,” or “Short-cuts” section within the help on a particular feature or task. You don’t want to intermixed them with other content on a feature because users get confused by trying to learn two different ways of doing the same thing.

However, the real problem with short-cuts is that users don’t know they need them. Users usually go to help when they get stuck, not because they want to work more efficiently. Given the poor usability of so much out there, why should users expect there is a more efficient way to work?

For hidden features, you may want to use dynamic in-line help of super-brief hints (e.g., a tooltip appears saying, “Doubleclick for default,” when the user manually resets a field to default). In-line help is also about the only help new users read, so you might want to consider replacing novice hints with advanced hints as the user demonstrates progress. However, that’s getting complicated and experimental.

share|improve this answer
add comment

User's don't like thinking - and they particularly don't like reading (particularly anything that has a contents page and an index).

As is discussed in this classic paper:

The Paradox of the Active User

Basically (since, being an academic paper, its not easy reading to start with):

...users aren’t a 'blank slate': they avoid reading, scan text on screen, are in a rush to get things done, and have their own pre-existing ideas on how something should work.

Which is why it’s a paradox:- if users were a blank slate they would read the instructions properly and learn more.

I'd work on the basis that the more words you write - the less likely they are to be read as users will go into 'I'll figure it out myself' mode.

share|improve this answer
    
thanx alot, Philip –  denis.efremov Apr 6 '12 at 12:17
add comment

Personally I think if a manual is required to use something, it is too complex already.

In the scenario of searching or filtering for a report, the common problem is that there are too many results. In these scenarios, it is best to look at how people are using the basic search and why are they trying to get a fine grain view of what the basic search returned.

A post from Boxes and Arrows, Advancing Advanced, may help you here. It looks at suggestions to this problem and below are some of my tips from personal experience.

  • Add hints ie. "Found too many? Did you want to narrow your category"
  • Displaying related filters in your search results ie. hotel searches list the level of stars a hotel has in results
  • Make the autocomplete results contain more data in the suggestion popup (ie. Yahoo's Search
  • Allow complex queries to be added in the search box (using standard web query)

Sometimes people don't know what they are looking for and adding these things will help begineers search like an advanced person. The idea here is to work out the flow of search, what are they trying to find and if they didn't find it what particular data is missing. Answer those questions then you will find how you can integrate advance search into your basic search.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.