By Julianne Chatelaine, Trellix Corporation
Reprinted from Usability Interface, Vol 4, No. 3, January 1998

This is the story of two real-life attempts to apply the research described in The Media
Equation (TME):

Reeves, Byron and Nass, Clifford, The Media Equation,. CLSI Publications, Stanford & Cambridge, University Press, 1996

In The Media Equation, Byron Reeves and Clifford Nass suggest that even text-only interfaces are experienced by humans as having some "personality". The author reports on how she tried to apply this research in editing error messages for two different software products. Her goal was to tune product personality in ways that helped users and their perception of the software, while reducing possible negative effects.

The first set of error message revisions discussed here were completed in 1994-95 at OneSource Information Services, Inc. Although in 1994 The Media Equation had not yet been published, I heard Reeves and Nass present their research as part of the tutorial, "Seductive Interfaces: Satisfying A Mass Audience" at ACM-SIGCHI '94 with co-authors Barry Linnett, Karen Fries, and Tim Skelly of Microsoft Corporation. Inspiration to try this method again with Trellix Corporation's first product, Trellix 1.0, came at UPA '97 where I had the opportunity to
purchase the book and hear Clifford Nass present the group's research in context.

In The Media Equation, Byron Reeves and Clifford Nass sum up many of their research projects with the sentence, "People respond socially and naturally to media." As they define media, they include everything from
radio to software. They admit that this conclusion is "counterintuitive." (TME, page 7)

If you have participated in any group discussions of their findings, you may have heard harsher assessments. TME demands that we critically examine some long-cherished intuitions about ourselves as human beings, and not everyone enjoys that process.

Why is TME interesting to our SIG?

Intuition aside, I find TME fascinating, and of particular interest to usability advocates and technical communicators.

In studying usability, we are interested in reality: what is, rather   than what should be. We've all had to give up (or help our teams decide to abandon) a long-cherished, well-refined design because the users just didn't understand it. If you truly believe the users are always right, you will find TME's descriptions of repeatable experiments easy to grasp.

In addition, TME emphasizes the power of simple text. Many TME experiments were carried out without pictures, icons, or sound, using only text on a black-and-white computer screen, plus graphical buttons to
register users' choices. Varying that text caused significant differences in how users felt about the software. "Personality can be perceived in the most minimal of places--a simple English sentence." (Page 89) As technical communicators we already believe text is powerful, but it's nice to hear this validated by research.

Note that adding multimedia did not significantly change the results of TME experiments: "Voices did not make the interaction any more social than text." (page 25) These findings implied that noticeable effects were being produced by text alone.

Why start with "error" messages?

I started applying TME findings to software text (resource) strings for two reasons.

First, I've spent most of my career in small software companies. My last two development groups didn't have the funds required to 'personalize' their interfaces with animated characters or even multimedia. And the error messages were already scheduled to be reviewed by a writer. If TME's findings were even partly right, I could potentially produce improvements in the way users perceived the software, with no additional expenditure.

Second, TME suggests that there are often unintended negative effects of poor text in interfaces. Before trying for any improvements, it seemed like a good idea to eliminate any negative effects we were currently causing.

Third, I wanted to follow Nass' and Reeves' own example and test the effect of the changes I made. I was not able to do this in the case of the first interface, but I am in the process of testing users' reactions to messages in the second interface., and the results will be incorporated into future versions. (If you want to assess the "feel" of the messages after the editing pass described below, and you have a 32-bit Windows system, you can download and run a free trial version of Trellix 1.0 from Trellix.

TME findings about media "personality"

I tried to change my programs' error messages to take advantage of the  following TME recommendations and findings.

First of all, Reeves and Nass found it was possible to "suggest" personalities of two basic types, dominant or submissive, by making simple textual changes in an online exercise. Here is an example:

Though the language styles used for the two personalities were different, we kept the information the same. In the experiment, participants were asked to discuss items that might be useful for survival in the desert. For example, in a discussion about sunglasses, the dominant computer would say: "In the desert, the intense sunlight will clearly cause blindness by the second day. Without adequate vision, survival will become almost impossible. The sunglasses are absolutely important." The submissive computer was more tentative: "In the desert, it seems that the intense sunlight could possibly cause blindness by the end of the second day. Without adequate vision, don't you think that survival might become more difficult? The sunglasses might be important." (pages 92-93)

They supported these textual changes by adding a numeric ranking of confidence, either high or low, to the textual discussions just described, and adjusting whether the computer spoke first or waited for
the user to act. However, this excerpt illustrates their approach with text.

Second, the TME studies found that social science research indicating that people prefer personalities like their own, applied to media also. "When the personality of the computer matched theirs [dominant or submissive] ...participants were significantly more satisfied...they enjoyed themselves more, had more fun, and thought the whole experience was more interesting. ...And it is important to remember that every participant was an experienced computer user who, after the experiment ended, denied any thoughts of a social relationship with a machine." (page 96)

Psychologists have found that the general population contains equal amounts of the two basic personality types, dominant and submissive. If one does not have the technology to make the software assess each user's personality and adapt to it (a provocative TME suggestion!), the next best thing is to select one personality and stick with it. "Make personalities strong and reliable. ...Even though personality can be assessed with limited information, inconsistencies...diminish the purity of personality, and thereby contribute to confusion, and even dislike." (page 84)

In other words, users are more comfortable when they can figure out what the software's personality is - whether they like it or not. "Hydrid personalities, which inevitably emerge from uncoordinated group efforts, can be unpleasant for users. ...If people can identify the personality, generally half will like it. If it's ambiguous, almost no one will." (page 98)

The published TME findings were underscored by Dr. Nass' remarks at UPA '97. He said that when a product's textual messages were written by a variety of different people, using different styles and degrees of dominance, it made the product seem "psychotic." A chill crept down my spine, for reasons I will explain shortly.

Case study #1: The software was grovelling

The year I first heard about TME, I was working on an integrated suite of tools with a graphical user interface (GUI). Our tools let business customers work with information from premium financial and reference databases packaged together in an easy-to-use format. The company's support was first-rate, and we were considered a premium product in several market segments. There was only one problem: our software was grovelling (textually) before the users, in a way that, if it was done by a "person", would be extremely tiresome.

Most notably, every message of any kind began with "please." This had begun with a few default messages added by our GUI toolkit, all overly polite, and then the developers conscientiously copied the tone of those messages as the product grew, until the overall feel of the textual messages was extremely cloying.

My colleagues and I used TME research to rewrite all the messages in a neutral and "businesslike" voice. In addition to removing the humble "please," we also rewrote phrases in second person (using "you"),  following current industry standards for online help.

Unfortunately, we didn't run specifically targeted before and after tests to measure the effects of these changes. However, qualitative usability reviews suggested there was a lighter feel to the interface afterwards and that using it felt like less "work" than before our edits.

Case study #2: A sane, reserved, but helpful interface

My current job involves both usability work and technical writing for a brand-new software application called Trellix. Early pre-release builds of Trellix had messages written by nine different developers, using tones
and styles that varied from bossy/directive to reserved/indirect. In addition, we had purchased specialized software libraries to help Trellix process text, images, and windows, and each of these libraries came with
its own (separate and further differentiated) messages. The resulting  mix did (I realized with a chill as Dr. Nass spoke) seem somewhat  "psychotic."

TME indicates that these impressions of interface 'personality' are formed by the way, as users are engaged in their overt tasks. The Trellix designers hoped that users would be able to use the product in a highly productive, creative "flow" state; my guess was that in the presence of a potential psychotic, it would be difficult for them to relax sufficiently to do this.

One key implication of TME is the point that has also been made by Ursula K. LeGuin, Suzette Haden Elgin, and many others, that all native speakers have sufficient information to analyze dialogues and infer personality from them. Our team could use what we already knew to protect our software from users' hatred and scorn, and maybe even make it more effective (if relaxation is a prerequisite for flow, or if the users came to "trust" the software and hang in longer when a problem was encountered).

With two other experienced writers, Molly Oldfield Yen and Jim Lindsay, I developed a texual "personality" and "character" for Trellix.

Here are the key elements of its personality:

• Doesn't put itself forward; speaks only when spoken to

• When it finally speaks, it's firm and authoritative

• Doesn't brag

• Doesn't grovel either - doesn't even say Please, just states facts

• Uses language and constructions that are neutral OR, if a
  choice must be made, that shade slightly towards dominant

And it has a character too

• Tells the truth

• Is consistent

• Is empathetic in a businesslike way - speaks to the users' point of view or about their tasks, not system tasks/concerns

• When a serious problem occurs, is polite in giving a full explanation of how to remedy a serious condition, because
  "...politeness takes time. In real life, most of us would choose politeness over brevity, even at work, and even in our most productive  moments." (page 30)

We found this a good personality for software aimed at business users, and tried to make Trellix messages reflect "a reliable, effective, genderless colleague, maybe a bit shy, who gets the job done smoothly and without offending most users." One thing that helped was that as we gradually refined the product, the developers removed many messages completely, making it less possible to perform actions that resulted in error conditions. (The entire Trellix interface, which is largely wordless, also has personality given it by its design team; this topic is covered in the "advanced" section of TME, but it is outside the scope of this article.)

Examples from the second case study

A few examples cannot give the effect of the scope of the project, but here are some message pairs before and after our message rewrite, showing how we made a disparate group of messages more similar in tone.

The first two BEFORE examples show too-technical language and a system viewpoint; their AFTER versions changed quite a bit.

BEFORE - "Failed to create object."
AFTER - "Trellix is experiencing an internal problem that is unrelated to your work." [We then went on to state the remedy.]

BEFORE - "Create link cancelled."
AFTER - "You have stopped linking."

The next example was not too bad BEFORE, but we added more friendliness and clarity.

BEFORE - "The minimum dimension must not be greater than the ideal dimension."
AFTER - "You have entered sizes that do not work together. The ideal must be greater than the minimum."

The final example was too verbose, with a system viewpoint, but it did have the right idea in giving instructions. We changed the viewpoint and made the instructions shorter and clearer. ("Sequence" is a word from the
interface.)

BEFORE - "This is an automatically-generated list and you can't edit  between items in the list. Click to edit the contents of the list or click outside the list to edit text."
AFTER - "You are editing a list created from a sequence. It is not possible to type in between the links or fields. You can edit any link's contents by clicking it."

Developers also have personality and character

During this second rewrite I inadvertently caused a new problem. The first message rewrite (case study #1) had gone swimmingly, but it extended over several months and involved long meetings with each  developer. During case study #2 I had only a few days to complete the rewrite, and my consultation with developers was limited to messages that were obviously (to me) ambiguous.

One of my least favorite messages came from one of the packages we purchased and incorporated within Trellix. To avoid embarrassing the package builders, who perhaps assumed we would rewrite their messages anyway, I omit their name and area of expertise.

BEFORE - "<Subsystem Name>: Unknown Error."
AFTER - "Trellix is experiencing problems with its management of <noun>s."

I thought (and still think) that from the user point of view this was a fine rewrite. However, the developers who were involved in incorporating this subsystem, whom I had not consulted beforehand, took the AFTER message as an aspersion cast on their work. (Rightly, the entire team felt an intense pride of creation.) Jim Linday helped them craft a third version that would be helpful to users while honoring the quality of the software:

AFTER(2) - "Trellix cannot load this <noun>, because..."

I took away a important lesson about not rushing the rewrites!

Future work

I appreciate the way The Media Equation presents experimental findings that can immediately be applied in an industry setting, and suggests ways by which their effectiveness can be verified. As described above, I am in
the process of testing users' reactions to Trellix version 1.0, and the results of explicit tests of the messages will be incorporated into future versions. (If you want to assess the "feel" of the messages we finally chose, and you have a 32-bit Windows system, you can download and run a free trial version from Trellix. I welcome any comments you may have!)

Another TME design suggestion is to leverage personality effects to make online help seem more effective. If users are already angry at an application, Nass and Reeves argue, the last thing they want is to interact with something that "seems like" what they're angry at. Therefore, TME suggests that there is a role for some online help that is NOT integrated into the application, for users who would like to take a break from the app and interact with something "different." This is not to say that help-in-the-app is bad, but to say that TME suggests that a separate help system still has value. Since most Windows applications now have two kinds of help, some integrated into the application and some in an external file, it would be interesting to test the "default" versions
against two others with different types of help selectively disabled.

Julianne Chatelain (julianne@trellix.com) has worked with online, interactive information since 1979. She can also be reached at her personal website, http://world.std.com/~jchat/.

SIG Home | About the SIG | SIG Activities | Resources | Topics Newsletter |  Conference |  Bookshelf  | Toolkit  Comments or questions? Please send your email to <stcusability at sufficiently.com> © 1998-2004, Society for Technical Communication