MOO POPs
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:
- When choices or actions are grayed out (Hey! why can't I do this?)
- When we ask users to make decisions (Did you want DES, 3DES, or AES encryption?--say what!)
- When business or validation rules will lead to likely error conditions
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.
2 comments:
About "items that are grayed out": my dev team never wants to add any explanation in the UI. Do you have some specific points that I could use to convince them otherwise? They believe the user should be able to figure it out.
Along similar lines, we recently had a debate about how/how much to inform users, in the UI, about changes that occurred unbeknownst to them when they made inappropriate choices. Suppose you make selections on Tab A, then go to related Tab B. If you make selections on Tab B that render the Tab A selections nonsensical, our application just goes ahead and changes the Tab A selections to ones that make sense. What sort of assistance (if any) would you recommend in this case?
If you consider this too far off the topic of your original post, please just disregard.
Slam dunk scenario for embedded assistance to explain grayed out feature: (1) If that is what the user wants to do and (2) they are being prevented because they have not met some prerequisite, and (3) it is in their power to meet the prerequisite, then tell them. If the UI layout itself does that, for example, a grayed out IP address field under a radio button that says "Assign IP address manually" and the field becomes active as soon as the user selects the button, I think most users get that and I wouldn't do anything with embedded assistance. If it is not clear, for example a feature must be configured on another screen before a choice shows as active, then I would tell them that with embedded assistance of some kind.
One more scenario is where something is grayed out and the user has no control over getting it to be active (e.g., lacks the proper permissions to do a task) I advise not showing it at all rather than graying it out.
Your second question is very interesting. I prefer the UI to inform the user about the conflict and let the user decide. E.g. "You selected printer X on the printer selection box and color as your output in the output box. Printer X cannot print color, do you want to change printers or change output to grayscale?"
This scenario begs the question of why did the UI present the user with an option that is inconsistent with choices made elsewhere in the application.
Post a Comment