Clear, Common Language Leads to User Success

November 5th, 2009

A huge problem for projects is the lack of a common language between the developers and the users.

When my colleague and I were preparing a presentation for an internal conference on this subject, he said something that has stuck with me. He said, “The goal of the project is to make the user successful.” I added to that: It’s not to write code or validate code. It’s not even to ship a product or make money (of course, this last one is especially true in a non-profit organization). At least, it shouldn’t be these things.

The goal of a project is to make the user successful at what he wants to accomplish.

Go ahead, read that previous sentence a few times. It’s one that would do well to sink in.

This isn’t to say that, for example in the case of software, that the code isn’t the main output of the project and is therefore the most important deliverable. But the code is a means to an end. And if you’re concerned about helping the user reach her goals, then you’ll be more likely to make the money, or at least be a trusted partner if you’re not out for a profit.

Communication Breakdown

As mentioned, breakdown in language is a barrier to users’ success. I’m not talking about localization problems, though that subject is related.

I have a couple of examples just from this week. First, while I was getting some answers to questions, a QA engineer suggested to me that we needed to have a glossary for the short guide I’m working on. His main concern that he had found some people in the customer department had different definitions for certain terms. The application used the terms a certain way, so it would be important to set those terms out the way the application uses them to reduce confusion.

Second, a user of a different application ran into trouble with a feature and thought the entire feature didn’t work. Part of the problem was the infamous error message. It was nonsensical to this user and added to his frustration. When I read the message, I was able to pick out what it was saying, but I agreed that it was very unclear. I have no idea who wrote the message, but what I think the person was trying to do was use one sentence to account for all possible input formats for this particular field. The unfortunate thing is that in explaining in these terms what was acceptable, the message didn’t tell this user what was actually wrong with what he had typed: the inclusion of a single illegal character.

The reason I became aware of this second situation was that the QA lead asked me to rewrite the message. So I rewrote it to show acceptable formats instead of describing in general terms what was allowed.

The Importance of Text

This is one of the reasons I strongly believe that technical writers should be involved in crafting user interface text and error messages. With our user hat on as when we write documentation, we can help put together UI text that makes sense and lets the user know what to do next.

Text is an essential part of nearly every interface. Imagine going to a website to shop, only there was no text. You would probably see thumbnails of the products, but you wouldn’t know how much they cost or where to enter your credit card information. You probably wouldn’t even know what site you were on if it weren’t for the URL.

Granted, there are some common icons on the Web that are widely understood, such as a shopping cart. But many times, icons are still accompanied by text to make little room for misunderstanding.

Designers and Writers Unite …

This is an opportunity for designers to partner with technical communicators to improve the usability of products through clear, effective text. Admittedly, many technical communicators are in this field because we’re word nerds. We think it’s important to choose the right words.

In our presentation, my colleague told of an experience he had where he was brought in to work on a project that was rated badly by its users. He found that the main problem was that the text that the developers had used in the interface didn’t make sense to the users. While it was technically correct, the average user didn’t have the right vocabulary to understand it. After my colleague spent some time with the designer changing the text and a product update was launched, the product was rated as much more usable. The users had a much more positive experience from that point on.

Wrap-up

When teams think in terms of making the user successful, I think priorities will adjust and emphases become more balanced. Simple, clean interfaces are important, but without instantly decipherable text on those interfaces, users can’t accomplish their goals. And this affects the bottom line—making (or saving) money or being a trusted partner with your customers.

Related entries (auto-generated):

Why Writers Should Be Involved Throughout the Project Lifecycle

Usability and Maintainability: Understandable Information

User Assistance Embedded in the Interface

Consistency Leads to Trust in Information Sources

Conclusions from a Conversation with a User

4 Responses to “Clear, Common Language Leads to User Success”

  1. Ivan Walsh Says:

    Hi Ben,

    Can I offer an alternative viewpoint here?

    <The goal of a project is to make the user successful at what he wants to accomplish.

    No.

    The goal of a project is to achieve its objectives.

    This may, or may not, make the user successful.

    An example.

    Interruption advertising, politics, negative PR campaigns, nag-ware, and other ‘projects’ that are not related to pleasing the customer.

    Another is customer support and call centers. It would appear they are trying to please the customer, but in my experience, they’re often trying to get rid of you. Try to return a product and see how easy/hard it is.

    Maybe if we re-phrased this to

    <The goal of technical communications is to help the user accomplish what they wish to achieve.

    Then, if you have a common vocabulary (i.e. the users, writers, and developers) all have the same understanding, then, maybe, maybe, maybe, they’ll come to some form of agreement.

    By the way, I think people want to be understood but making the effort to put yourself in someone else’s shoes — that’s hard work.

    Hope this reply is taken in the best spirit. I read your blog in my Google Reader.

    Bye

    Ivan

    [Reply]

    Ben Reply:

    Sure, alternative viewpoints are welcome.

    Frankly, I’m not sure there’s much difference between my original statement and your rephrasing of it. I wouldn’t classify customer support or call centers as a project because it doesn’t really have a lifecycle—no beginning or end. It’s an ongoing service effort. But I agree with you that sometimes customer service isn’t much service at all. Many times, it’s a sales pitch.

    The same with the other things you listed; not much of a lifecycle there. I’m thinking of projects in the sense of something that is funded, has a start and end, and results in a product (rather than negative feelings about someone or something or someone gaining a campaigned-for position).

    Thanks for commenting. I’m subscribed to your blog as well.

    [Reply]

  2. Is this true? The goal of a project is to make the user successful! | I Heart Tech Docs, Ivan Walsh, Technical Writer Says:

    [...] Ben’s article is at:  Clear, Common Language Leads to User Success [...]

  3. Scott Nesbitt (scottnesbitt) 's status on Wednesday, 18-Nov-09 00:56:08 UTC - Identi.ca Says:

    [...] http://www.gryphonmountain.net/2009/11/clear-common-language-leads-to-user-success/ a few seconds ago from Gwibber [...]

Leave a Reply