User Assistance in the Role of Domain Expert
Published: January 8, 2007
This article explores the role of user assistance in providing domain-centric online Help—rather than Help that simply explains obvious user interactions with well-designed user interfaces—and provides a pattern for and examples of expert guidance.
It took two Aha! moments for me to get the importance of providing domain expertise in Help. The first came at a conference for writers of user assistance when the technical communications manager for a company that makes home accounting software said, “My challenge isn’t teaching people how to use our software; it’s teaching carpenters how to be accountants.”
The second Aha! came during usability testing of the online Help I had written for system administrators of a predictive dialer—a device that dials phone numbers automatically, then if someone answers, connects that person with the first available call-center agent. On one of the screens we were testing, users were to set the Busy Callback Time, which I had defined as: “The time the dialer waits before redialing a line that is busy.” I had specified the minimum and maximum allowed values—0 and 999 minutes, respectively—and even mentioned that users could click an up arrow to increase the value; a down arrow to decrease the value. And, of course, I also told users to click Save to save their changes. Well, when I tested the online Help in the usability lab, I learned the following:
- The label Busy Callback Time was self-explanatory—really, everybody got it right away.
- No one wanted to set the value to less than zero.
- No one tried to set a value that was even close to going over the allowed maximum—and if someone had, the system would not have accepted the value.
- Everyone figured out that whole up arrow and down arrow thing without my help.
- They figured out Save on their own, too.
Still, users went to Help with one simple question: “What’s a good number of minutes to delay before calling back?” It seems that was the only thing I had not documented.
I understood then that Help should provide domain expertise, not just tell users how to manipulate user interface elements.
Who Are We Helping To Do What?
The term user assistance implies that a user has a goal he or she wants to accomplish by using an application or other tool and may require assistance in doing so. Thus, we can divide user assistance into two main types of information:
- how to use a tool
- how to use a tool to accomplish a specific task or goal
The first type of Help is very tool-centric and focuses on the constraints and manipulations of the user interface itself. Good user experience design minimizes the extent to which this kind of user assistance is necessary by making such interactions self-evident. However, most applications require this type of assistance to some degree. Help that explains how to enter a summation formula in Excel provides an example of tool-centric user assistance.
The second type of user assistance is more user-centric and focuses on goals and problems that exist within a user’s context. Showing someone how to use Excel to do a budget is an example of goal-oriented user assistance.
Unfortunately, many technical communicators continue to emphasize tool-centric user assistance to the same degree that was necessary when we were documenting command line syntaxes for mainframe word processors. User interfaces have moved on; so should technical communications professionals. To earn our place in the world of user experience, technical communicators need to get better at writing goal-oriented user assistance.
Busy Callback Time Redux
So, what did I do after that usability test showed my Help was anything but helpful? I asked one of our customer consultants—the folks who went on site and helped customers tune their systems—what a good value was for Busy Callback Time.
“Ten minutes,” he said. “You know there’s a warm body there, and you don’t want to let that person slip away.”
I followed up, “Why would you make it higher or lower?” After all, there had to be a reason for the spinners that let system administrators change the setting.
“Oh, I check the daily reports,” he said. “If the line-utilization rates are low, I change the busy callback time to make it higher, because I’m wasting an outbound line if I’m calling the same busy number too many times. If the hit rate starts going lower, I decrease the busy callback time, because I’m letting the live bodies get away by not calling back soon enough.”
Okay, there’s a lot of fuzziness here—no hard and fast algorithm, but some really meaningful heuristics. That’s what users were looking for: guidance that has its basis in expertise about managing a call center, not numbered steps that tell users how to enter data into a standard dialog box.
Two psychologists have provided interesting insights into this problem from their different perspectives. Piaget has given us the concept of schemata—models that help us interpret the world. As we take in data, we look for a schema that lets us make sense of it. Once we find a useful schema, we assimilate the data into that schema. However, if our library of schemata does not adequately explain new data, we must accommodate it by changing our schemata or create a new schema if an experience is unique. According to Piaget, this is how we learn.
The concept of schemata also guides how we design user interfaces. How did you know to click a labeled button when you first encountered one? Did you go to the Help file? Probably not. It looked like a real button, and you already had a schema that said buttons are things you press. Your mouse pointer turned into an arrow when it was over the button, so you clicked it. It worked, and you assimilated digital renderings of buttons into your button schema. You also extended your button schema to accommodate the behavior of clicking with a mouse rather than pressing with a finger. User interface designers find metaphors so useful because they tap into people’s existing schemata.
Vygotsky offers a different perspective on learning—one that emphasizes its social aspects. A concept of particular interest to instructional designers and writers of user assistance is his Zone of Proximal Development (ZPD). Vygotsky defines ZPD as “the distance between the actual developmental level, as determined by independent problem solving, and the level of potential development, as determined through problem solving under adult guidance or in collaboration with more capable peers.”
Vygotky’s ideas apply more broadly than just to learning in children. In his definition, think of “developmental level” as meaning “understanding of a product’s application to a user’s context” and replace “adult” with “expert,” and you have an exciting model for user assistance.
A Pattern for Expert Guidance in User Assistance
This section proposes a pattern language approach to describing how user assistance can provide expert guidance.
A trigger is an event that causes a user to need assistance. For example, a user might need guidance regarding a decision point within an application—such as turning on a feature or providing a value during configuration.
A system prompts a user for input within a context in which an application domain requires expert knowledge that the user does not possess. Therefore, the user requires assistance. Examples include non-accountants using accounting software and people who are not professional writers using word processors.
There are conflicting forces at work that should influence what kind of information a Help system provides, as follows:
- Users understand how to manipulate user interface elements, but do not know how to proceed, because they don’t fully understanding what information to provide to the system.
- Users understand their own contexts and needs, but cannot translate their knowledge into the information the system needs. For example, a user might know he needs a hard copy of a report to distribute at a meeting, but might not understand the implications of two radio buttons labeled HTML and PDF.
At a user’s decision point, you can either provide a relevant link in the form of the user’s likely question or provide user assistance automatically through embedded Help. Display the Help topic either as a popup or embedded text, ensuring that it is closely associated with the user’s task. In the Help topic, provide the following:
- conceptual information users need to understand the guidelines that follow
- guidelines that relate users’ potential choices to scenarios—for example:
- Type a high number if…
- Type a middling number if…
- Type a low number if…
- Turn on when…
- Turn off when…
- additional considerations such as the potential results of making inappropriate settings and the impacts of users’ decisions
Outcomes of a Proposed Resolution
Providing expert guidance can have both positive and negative outcomes, as follows:
- Positive outcomes:
- Enable users to perform at a higher level of expertise than if they were acting alone
- Enhance the usefulness of an application within a problem domain, giving users better results.
- Negative outcomes:
- Add to the cost of producing user assistance, because the content is harder for technical communicators to obtain.
- Make a domain seem more complex to some users, because the Help further illuminates particular questions. In other words, it might be harder to make a thoughtful decision than a naive one.
When to Apply This Expert Guidance Pattern
Apply this pattern in situations where the typical user might not
- have the full expertise that making an informed decision requires
- know what is an appropriate response to system prompts
When Not to Apply This Expert Guidance Pattern
Do not apply this pattern in the following cases:
- when a system needs information that is subjective and well within a user’s expertise to provide—For example, a drop-down menu that lets a user indicate how frequently a recurring meeting should repeat is not an appropriate application of the Expert Guidance pattern.
- when the gap between a user’s expertise and the needed expertise to complete a task is too great—For example, in a word processor, a dialog box that lets a user create page headers might provide expert guidance about automatically generating headers from section headings within the text. However, it would be too much to also explain style tags, heading levels, and hierarchies in document design at that point.
Example: Basic Expert Guidance
This example shows how expert guidance can help users complete a challenging task that requires domain knowledge.
Figure 1 shows the Function Arguments dialog box in Microsoft Excel. When the insertion point is in the Alpha text box, the embedded user assistance defines Alpha and gives its acceptable values.
Figure 1—Function Arguments dialog box
Microsoft product screen shot reprinted with permission from Microsoft Corporation.
Example: Detailed Expert Guidance
A less-than-expert user might need additional guidance in selecting an appropriate value for Alpha. Suppose the Help on this function link provided the following kind of advice:
Alpha indicates how willing you are to reject a true finding as not being statistically significant.
Use .99 or higher where significant harm or loss could occur by accepting a false finding—such as in a test of a new medication.
Use .95 where making an important investment—such as deciding whether to replace an expensive application program.
Use .90 where you need to make a decision based on data, but you cannot afford a large sample size.
Higher values of Alpha typically require larger sample sizes to indicate that a true finding is statistically significant.
Benefits of Expert Guidance
Embedded Help that provides detailed expert guidance
- expands the conceptual information about a setting—In the detailed example, it defines Alpha.
- offers expert alternatives—The Help instructs users to provide one of the three values that experts would typically use rather than just giving any number greater than 0 and less than 1.
- gives guidelines regarding which value to select—The Help describes the circumstances in which to use specific settings.
- offers additional tips—In this case, warning users that a high value for Alpha requires a larger sample size.
Even if a user does not fully understand the concept of Alpha and, therefore, does not make an optimal decision regarding its value, the user is unlikely to give a really bad value—for example, an Alpha of 0.25. While that value is theoretically valid and the system would accept it, no expert would ever use it.
Offering domain expertise within user assistance provides a better user experience by helping users to successfully accomplish their goals. Embedding expert guidance within a user interface also gives technical communicators a more valuable role within the world of user experience. Today’s user interfaces obviate much of the need for conventional procedural user assistance. So, the real challenge lies in providing content that offers domain expertise. It is no longer sufficient to deconstruct the user interface and describe its physical behaviors. User assistance designers and writers must research user tasks and goals, then seek out best practices for attaining those goals.