User Assistance in the Role of Domain Expert

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.

Champion Advertisement

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.

Trigger

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.

Context

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.

Conflicting Forces

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.

Problem Resolution

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.

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:

Concept

Alpha indicates how willing you are to reject a true finding as not being statistically significant.

Guidelines

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.

Tip

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.

Conclusion

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.

In User Assistance Design

9 Comments

Jigesh

January 11, 2007 4:50 AM

This is a very interesting article. Probably stating the importance of common sense, which unfortunately is not very common. The challenge, I believe, is in estimating the degree to which the writer needs to be tool centric and user centric.

Mike Hughes

January 11, 2007 12:28 PM

Jingesh, thank you for commenting on the article. The tool-centric aspect is almost a check-off item; you have to have it in order to put the product into the marketplace. The good news is that is the easy part. Technical communicators who are feeling the pressure to offshore documentation work could consider outsourcing the tool-centric topics:

Their language is more straightforward, as these topics tend to be procedural.
Writers can research and validate the content by deconstructing the user interface—something that distant writers can easily do.

The greater challenge is in finding the domain expertise. As I illustrated in my first example, it was not the developer who had the domain insight. We often have to look deeper and broader within and without our organizations to find that content.

Ann

January 12, 2007 2:26 AM

Sounds like a kind of education application. Any harm to systematic knowledge learning?

Mike Hughes

January 12, 2007 7:23 PM

One needs to be cautious with this pattern in terms of education. The objective is to not take the user out of the task flow, and many educational interventions would do that—tutorials for example. Expert guidance should strive to close a relatively narrow gap, which is why I link it to Vygotsky’s ZPD—the emphasis is on proximal).

Chris Collingridge

January 25, 2007 12:03 PM

The key, in my view, is to bring answers to the point of user’s questions. This means that reference information—what does this button do—and point assistance—tips or examples for setting values, for instance—should be within the interface. Users should not have to divert from their tasks for this information.

Procedural information should describe how these functions fit into various workflows—for example, using styles in Word: How do I set up a template?—and need to be linked to the activity in the application, but probably displayed elsewhere.

I think the domain expertise fits both into point assistance—through giving good examples and some brief context—and into procedural assistance that enables users to fully utilise functionality and improve their efficiency.

Meghashri

February 13, 2007 1:31 PM

Excellent article.

On one project, we did the usual online Help and later did a FAQ. Then we realized that the whole Help can be just a FAQ, because rest of the content we had put in Help was “explaining the self-explanatory”!

Mike Hughes

February 14, 2007 12:03 PM

Both Chris’s and Meghashri’s points came together for me in my last job. Like Meghashri, we found that the good information was in the FAQs. But to Chris’s point, we were able to keep users in the task flow by distributing the questions, as links, next to the potentially problematic areas of the user interface. For example, if a user account did not qualify a user for a specific feature and that option appeared dimmed, we provided a link like “Why can’t I transfer funds using Next Day?” Clicking that link opened a pop-up that explained what business rules constrained that option and how the user could qualify for it. We called that kind of user assistance point of pain assistance. We would do something similar for user input areas where we thought expert guidance could help. Once again, the link was phrased as a question and the focused answer was in a popup.

And to reinforce Chris’s point—I believe—if that guidance can be a static part of the user interface, as when providing meaningful examples, that is the optimal solution. Sometimes, however, a pop-up is the better solution, because it doesn’t occupy screen real estate unless a user needs it.

Chris Collingridge

February 15, 2007 12:38 PM

I completely agree. If a user’s not asking a question, he doesn’t need assistance. But sometimes users are not going to know they have a question until something goes wrong. I think this is where—in an ideal world—a choice can be made between having guidance as text on the interface and having pop-up assistance resulting from a question hyperlink.

Consider the situation where you have a text box in which a user needs to enter a code—say a customer number. Here, you could have a pop-up that might be linked to the question “What is the format of this customer number?” However, I think that a user’s unlikely to click this until he’s made a mistake.

If, alternatively, you put text in the interface to say “Example: ABC/1234567”, the user is much less likely to make an error in the first place. Obviously, you can’t do all of this in all circumstances, but I feel you should try to do this—and push interface developers to give space for this—in every situation you can.

Soapbox over!

Meghashri

February 17, 2007 12:55 PM

I agree with Chris’s idea of embedding as much Help as possible, space permitting.

Another point: After we have addressed the obvious pitfalls—format, for example—and provided some point of pain assistance, a very major area of user assistance (UA) still remains. That is best practices.

In a banking transaction user interface, for example, I can choose various deposit types, but without any guidance about what they really mean in my specific circumstances. In real life, a good banker can guide me very well in these matters. I think providing best practices can fill this gap. In my current project, I am exploring this aspect of UA, which is a proactive assistance.

I would say UA has come a long way: from being reactive—error messages—passive—manuals and Help—preventive—embedded Help or text in user interfaces. Now, let’s take it further and make it proactive.

Mike Hughes

UX Designer at TSYS

Atlanta, Georgia, USA

In his role as User Experience Architect for IBM Security, Mike’s professional focus is on designing usable user interfaces that accommodate the user as learner. Previously, as User Assistance Architect at IBM, Mike identified tools, methods, and standards for integrating the content and delivery of user assistance, including documentation, Help, elearning, and training. He was formerly Lead UX Designer for CheckFree Corporation, where he instituted their User Experience Research and Design Center. Mike has a PhD in Instructional Technology from the University of Georgia and a Masters in Technical and Professional Communication from Southern Polytechnic State University. He is a Fellow with the Society for Technical Communication and a Certified Performance Technologist through the International Society for Performance Improvement. Read More

User Assistance in the Role of Domain Expert

Who Are We Helping To Do What?

Busy Callback Time Redux

A Pattern for Expert Guidance in User Assistance

Trigger

Context

Conflicting Forces

Problem Resolution

Outcomes of a Proposed Resolution

When to Apply This Expert Guidance Pattern

When Not to Apply This Expert Guidance Pattern

Example: Basic Expert Guidance

Example: Detailed Expert Guidance

Concept

Guidelines

Tip

Benefits of Expert Guidance

Conclusion

9 Comments

Join the Discussion

Mike Hughes

Other Columns by Mike Hughes

Other Articles by Mike Hughes

Other Articles on User Assistance Design

New on UXmatters