User Assistance: Writing for a High-Context Culture
Published: May 19, 2008
Jean-Luc Dumont is a respected authority in international technical communications, but he is most renowned for a particularly entertaining presentation he gives about road signs. This genre of tight communications that are written for small spaces and meant to read by users in motion holds many lessons for those of us who write user assistance.
Especially enlightening is the distinction Jean-Luc makes between high-context cultures and low-context cultures and how that difference in cultures influences the language of road signs. While technical communicators tend to write in a low-context style, user assistance occurs in high-context situations. So, in this column, I’ll discuss the need to reexamine how we write user assistance in light of this cultural proclivity.
High Context and Low Context
Jean-Luc points out—nonjudgmentally—that the American culture is a low-context culture. Figure 1 shows one of Jean-Luc’s examples that makes his point most vividly. I see this kind of sign several times a week in my own neighborhood.
Figure 1—A sign for a low-context culture
This is a typically American-style road sign, because in low-context cultures, the assumption is that people know only what you have explicitly told them, and anything that is not expressly prohibited is allowed. On the other hand, people in high-context cultures do not need to be told not to hit pedestrians, because not hurting people is part of the cultural value system, and the assumption is that this guideline applies to traffic scenarios as well. In a low-context culture, it is apparently not only necessary to state this rule, it needs the further status of being law—versus a general guideline for drivers to follow or ignore at their discretion.
The Culture of Technical Writing
What we consider to be good technical writing often reflects an American cultural perspective. One facet of this cultural orientation is that technical writing tends to use a low-context style. Most notably, we tend to write user assistance as if users have never seen the user interface we are explaining. Secondly, we tend to write user assistance as if users have never even used software before. But users rarely go to Help before they have tried to accomplish a task on their own first, and most users today have extensive experience using software and are familiar with the standard ways of interacting with user interfaces. So a user interface is a high-context artifact—one a user has already seen before reading our documentation and that uses rules and conventions the user already knows.
Discussion of a previous column I wrote for UXmatters called “Procedures: The Sacred Cow Blocking the Road” illuminates the contrast between low-context and high-context perspectives. In that column, I gave an example of a two-column choice table that describes the purpose of each option in a user interface. The name of a user interface element is in the first column, and a description of its function is in the second. One reader, TC Makinen, made the following comment:
“Although I like the choice table as a way of simplifying the presentation of procedures, the descriptions in your example aren’t clear. For example, for the Comment option, the description reads ‘Provides a description of the policy,’ which sounds to me as though the description is generated by the software instead of by the user.”
In the actual user interface, it is clear that “the Comment option” is a text box—something Makinen did not know, because I had not shown the user interface in my example. But a user probably would have known that, because users come to Help from the user interface and only after they have encountered difficulty. Using Jean-Luc’s terminology, the text “Provides a description of the policy” takes a high-context approach to writing, whereas an alternative like “Use this field to type a description of the policy” would take a low-context approach. My point is that a user who is defining a policy and encounters a Comment text box is not going to sit and wonder who fills it in. Yet we tend to document such elements as though they would.
A further advantage of moving to a high-context style is that we can eliminate interaction verbiage that does not add value, such as “Select the…” from descriptions of drop-down lists, radio buttons, and check boxes; “Click the…” from descriptions of command buttons; and “Type the…” from descriptions of text boxes. In high-context writing, we can assume prior exposure to conventional user interface interactions.
Guidelines for High-Context Writing
As user assistance moves from Help files into the user interface itself, as in the case of embedded user assistance, users’ awareness of context becomes even greater, and the need for a high-context writing style increases. As with road signs, the space in a user interface is limited and the user is moving—at least his or her focus and attention are.
Here are some guidelines for high-context writing as it applies to user assistance:
- If the subject is obvious, do not restate it. Sentence fragments should abound in descriptions of user interface elements.
- Examples beside text boxes need no explanation. For example, (555) 555-5555 next to a phone number box is enough. There is no need for Example: (555) 555-5555 or, worse, Use the following format: (555) 555-5555.
- If a user interaction is obvious or well known, you do not have to specify it. Users know what to do with radio buttons, drop-down lists, and the like.
- Just because one or two elements in a user interface need explanation does not mean you must explain every element.
- Context-sensitive Help topics and messages should assume a reader is coming directly from the user interface and, therefore, should use a high-context style. If users get to Help through an index or table of contents rather than from the interface, they are not reading to do, and the how-to topic isn’t really for them anyway.
Safety messages are a necessary exception to high-context writing, especially for American documentation—mainly from the practical consideration that product liability law is a low-context environment. This means we must tell consumers not to spill freshly made coffee on their laps, because it is hot, or not to use electrical appliances while sitting in a bathtub.
Beyond User Assistance
In addition to the obvious need to write user assistance in a high-context style, we should examine our off-line documentation to see whether our low-context style is getting in the way of good communication. The slippery slope of low-context communication starts with telling users they must type their first name in an empty text box that is labeled First name and ends up with us telling people not to knock pedestrians down with their cars.