Embedded Assistance

I'm working these days on some very exciting projects involving embedded assistance. Embedded assistance (EA) is user assistance that is incorporated directly into the user interface, specifically, assistance that does not require the user to go into a Help file or document. Although most people think of embedded Help panes that exist along the right or left side of the application screen when you say embedded assistance, that is just one aspect of EA--and quite frankly, one of the less important elements. Embedded assistance incorporates any text or communication within the user interface that informs or instructs the user:

• Field labels
• Inline instructional text
• Error or information messages
• Button labels
• On-screen examples
• Hover text
• Tool tips

And beyond this obvious list of element where words are involved, I also include other design considerations such as grouping and sequencing of fields on the UI.

I'd like to give a shout-out to Fred Sampson, a colleague of mine within IBM, for the leadership he has shown in taking me down this path. In the next series of blogs, I will be relating research and guidelines Fred has helped assemble along with tips and how to's from my own experiences helping my division move in this direction.

Why embedded assistance?

Today's blog focuses on why user assistance writers should shift their focus from traditional Help and concentrate more on embedded assistance.

1. Users don't go to Help.
2. Embedded assistance keeps users in their task flow.
3. OK, some users eventually go to Help, but then it isn't helpful.

Users don't go to Help

In most corporate cultures there is somewhat of a dichotomy between working and learning. By that I mean we think of the two as being different activities. We say things like "I won't be at work next week because I'm going to the WritersUA conference." Or when an inhouse training session comes to an end, someone invariably says, "Time to get back to work."

Users see going into Help as being an interruption to work. I used to complain about users who were "too lazy to read the manual" until I started doing usability testing. I then realized that the users were working very hard to get the task done, and they were not going to Help for that very reason, they were focused on the task and that is where they felt they should stay.

Staying in the task flow

The best place to put user assistance is in the UI where and when the need occurs. I like to talk about MOO POPs--no, not milk-based Popsicles, moments of opportunity and points of pain. Understanding where the MOO POPs are in your application is a critical aspect of designing good EA. I will blog on that later.

Why Help is anything but

When I watch users doing a task and then watch when they eventually go into Help, more times than not the Help is not helpful. It's not the writer's fault. See my UXmatters column Stepped Procedures: The Sacred Cow Blocking the Road for an explanation of why there is often a mismatch between the user's question and Help's answers.

Upcoming blogs

Tune in for the next few blogs as I go deeper into the following:

• MOO POPs
• Progressive disclosure (an essential technique for EA)
• How to sell the developers on letting us into the UI