UA2009: Embedded user assistance (help in context)

One of the central messages of the Software User Assistance 2009 conference was that Help must move into the UI itself (embedded user assistance).

Scott DeLoach (ClickStart), in his presentation "Best Practices for Embedded User Assistance", said the goal to fix Help is to [1] HIDE in plain sight, [2] PREDICT questions, [3] PREVENT problems, and [4] SEDUCE users into opening the Help they need. Research shows that [1] users simply won't ask for help, [2] they don't perceive embedded help as Help, and [3] they do use embedded help, so it has strong ROI.

He recommends using whatever field-level help is possible, such as examples, guidance, and Help links posed as questions or tips. Help icons (question marks) are not the best visual device, given that users resist requesting "Help". Prefer any solution that keeps users from leaving the context of the page or having to take action (such as roll over or click) to see the guidance. Best practice for linking to external Help is to link brief guidance to a truncated preview of extended guidance, which links out to the full Help text, without calling it such.

More radically, he urges us to implement a Help pane within the UI itself, either as permanent screen real estate or as a collapsible area. This content should focus on high-value user questions, to keep them from getting stuck or making errors. This Help pane, if rendered using AJAX, could be easily set up to accept user comments and ratings and, more importantly, to be editable from the UI itself -- such that developers and writers can collaboratively create embedded Help in place in real time, with no external processing or off-line production. The pane could be made read-only when shipped, or whatever the use case indicates.

In both scenarios, the content should be stored in the application's resource files, which is important for many reasons:

• supports application modularity (add a new module, and its resource files and thus its embedded Help comes with)
• supports localization (third parties have the source they need for translation/customization)
• supports third-party development (external developers can add their own embedded Help without special source/kits)
• supports just-in-time updates and zero production time.

Should that content be needed for external references or training, simple scripts could write out the contents of those resource files. The presentation slides include source code for the AJAX implementation described.

The separate panel discussion on embedded UA detailed more requirements:

• Embedded UA must be [1] directly relevant to the needs of users, [2] highly selective, [3] very concise, and [4] very compelling 
• Writers must change roles: [1] get in the code: edit resource files for error messages, tooltip text, field names, etc., [2] help with usability testing, [3] guide UX, [4] manage/edit collaborating authors

Resources:

• "What is the Technical Writer’s Role in Interface Design?" http://www.idratherbewriting.com/2008/12/14/bogo-vatovec-technical-write...
• Usability Professionals Association: http://www.upassoc.org
• Interaction Design Association: http://www.ixda.org
• Information Architecture Institute: http://www.iainstitute.org
• "10 Most Common Misconceptions about User Experience Design" http://mashable.com/2009/01/09/user-experience-design
• "A definition of user experience" http://www.fatdux.com/blog/2009/01/10/a-definition-of-user-experience

Comments

[rob pierce]

Can we also see a link to ACM Special Interest Group for the Design of Communication - www.sigdoc.org - under the "Resources" section?