Add embedded help if:
▪your product is a product that users use only rarely ▪most of your product’s users will always remain beginners or intermediate users, and won’t become advanced users or expert users Don’t add embedded help—or provide an option to disable embedded help—if:
▪users use your product very frequently ▪your product is mostly used by advanced users, specifically if advanced users are your primary user group (note: “advanced” in this case means advanced in using your product) ▪the user interface of your product doesn’t provide much screen real estate ▪the user interface of your product can’t be changed to provide room for embedded help If you add embedded help:
▪Plan for embedded help early and coordinate your plan closely with interaction design, interface design, and development. ▪Anticipate the users’ questions at the field level. Often, this concerns: ▪reminders (for example, the meaning of an acronym) ▪exceptions (“what if …”) ▪relationships and dependencies that aren’t obvious ▪Embed only the most important and most frequently needed information. ▪In addition to embedded help, also provide traditional help that includes detailed help topics, in particular concepts and procedures. Link to the detailed help topics from embedded help. ▪When linking to traditional help, don’t use vague link text such as “Help” or “More ….” Use descriptive link texts that communicate clearly what users can expect when they click the link, and that motivates them to overcome their resistance to “asking for help.” Often, a good solution is to use a question such as “How do you …?”, “Why is …?”, or “What does … mean?”. |