Embedded assistance makes us reevaluate some tried and true principles of information design because our instructions occur within an action-packed medium--an application's user interface. If you think you have trouble holding a student's attention in the classroom, try teaching in a video-arcade. In many ways, embedded assistance has the same challenge.
Having said that, I'm going to shoot you over to a column I wrote a year ago for UXmatters called Instructional Text in the User Interface: Some Counterintuitive Implications of User Behaviors .
I want to discuss MOO POPs early in this series of blogs on embedded assistance (EA) because the concept drives straight to the heart of EA: When and where do we need it?
MOO POP stands for "Moment of Opportunity" and "Point of Pain." A moment of opportunity refers to a state in the user interface when we can intervene and move the user to increase his or her adoption of the product. I wrote an article for the Cutter IT Journal last year about progressive user adoption that talks about the ability of embedded assistance to increase user adoption of advanced features based on detecting user readiness for that advanced feature. For example, a useful feature in Microsoft Word is its ability to automate header content using heading tags in the document, such as making the current Heading 2 the header entry. When would you point that out to the user? If someone is in the act of defining a header, that could be the appropriate moment of opportunity. Imagine a link on the header dialog box that said "Tell me how to automate my headers" and which launched a popup that explained how to do that.
A point of pain is where we anticipate that the user might run into trouble. For example, if we provide a field for entering the name of a firewall rule the user is creating, and the developer points out that the database cannot accept spaces in the name, we can reasonably anticipate that some users will screw up. A simple statement next to the field that says merely "No spaces" will save innumerable instances of error messages popping up. In general, the following situations are good candidates to be points of pain:
So one of the first lessons in doing embedded assistance is that you do not have to be consistent, and by that I mean you don't have to treat all fields equally. The field that asks the user to type her first name does not need embedded assistance; the field that asks her to create a new password probably does (as in what are the rules for a valid password).
The guiding principle should be "Is there a moment of opportunity or point of pain that justifies taking up room on the user interface?"
In my next blog, I will talk about how to maximize effectiveness and minimize the intrusiveness of the EA entries on the user interface.
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:
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.
Today's blog focuses on why user assistance writers should shift their focus from traditional Help and concentrate more on embedded assistance.
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.
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.
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.
Tune in for the next few blogs as I go deeper into the following:
