Journals by RSS
Journals by EmailA 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):
Guidelines for Writing Error Messages
User Assistance Embedded in the Interface
Why Writers Should Be Involved Throughout the Project Lifecycle
Ben Reply:
November 9th, 2009 at 6:30 pm
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]