guidelines - Is it necessary to include an interface's "hidden functions" in the manual / help?

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

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?

Answer

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.