Welcome to the inaugural Ask UXmatters column, where you can submit your questions and get expert answers. Our highly experienced experts are ready to answer your questions on a variety of user experience matters. Please send your questions to [email protected]. Without further ado, let’s get to our first question.
Q: We have a challenge that I’m sure is common to many software development efforts. Everyone on our team—including the user interface (UI) designer, product manager, quality assurance, developers, and documentation—wants to choose the words that show up in the user interface. We are having a really hard time naming page elements that represent business processes and objects. Language is so subjective, and we all consider ourselves experts. I’m wondering if there are any best practices for the process of choosing the language that appears in user interfaces. We’ve tried having smaller meetings with key team members and brainstorming, but always end up reaching compromises that no one really likes and are apt to create confusion for our users. We have great documentation people and use them throughout the process, but can’t figure out who should have the final say. Everyone is very unhappy with the choices we make when naming elements by consensus. We need to figure out a process that ensures we use the best language in the product. Who should own these decisions, and why?—from a UXmatters reader.
Champion Advertisement
Continue Reading…
The following experts have contributed answers to this question:
Pabini Gabriel-Petit—VP, User Experience, at scanR, Inc.; Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at Spirit Softworks; Emeritus Member of Board of Directors, Interaction Design Association (IxDA)
Colleen Jones—Partner and Interactive Experience and Communication Consultant at threebrick; UXmatters columnist
David Heller Malouf—Senior Interaction Designer at Motorola; Professor of Interaction Design at Savannah College of Art & Design—effective January 1, 2009; Founder and former Vice President, IxDA
Jim Nieters—Director of User Experience at Yahoo!; UXmatters columnist
Whitney Quesenbery—Principal Consultant at Whitney Interactive Design; Past-President, Usability Professionals’ Association (UPA); Fellow, Society for Technical Communications (STC); and UXmatters columnist
Understanding the Problem
Colleen applauds this reader for this question, “The fact that you are asking about the process to arrive at the best language in the product means you already recognize that your product interface depends largely on language.” In fact, all of our experts agree that the choice of language is critical to the quality of all digital products. Dave states emphatically, “The language of your application is as fundamental to the user interface as the choice between a radio button and a check box.” Pabini says, “It’s important to come up with the best text possible, because despite the term graphic user interface, many of the user interface elements we actually design—as opposed to those that are part of an operating system user interface or framework—are text elements.”
Exclaiming “I bet everyone is unhappy!” Whitney describes three of the intermingled issues this reader faces. “First, the language in the interface is not separable from the user interface. People using your software don’t experience the visual style, interactions, and information in the interface separately. That’s why user experience is so difficult to get right—it’s inherently multidisciplinary, and takes expertise in many skills. You should be designing the language along with the rest of the interface.
“Second, although you want all stakeholders involved in brainstorming and in understanding the design and usability requirements, at the end of the day, someone has to sit down and make sure it all works together. A consensus process just isn’t the way to do that. As you’ve suggested, someone has to be in charge of the overall design of the language. Third and most importantly, you seem to have forgotten about the most important stakeholder: the people who use your software. The entire experience has to work for them, and that includes all of the ways the product communicates with them.”
Colleen goes on to say, “Most articles, presentations, and other discussions regarding language and interface design focus on either
the argument that language is important
some qualities of and techniques for designing effective language
“But not many tackle how to incorporate this aspect of design into our processes. So, I think your question and this collective answer from several UX experts is blasting, not just breaking, new ground.”
Perspectives on Process
Our experts have described various approaches to the process of making decisions about user interface language. Here’s what they had to say.
Get the Right Writer to Create the Right Text
“You need not just any writer, but a writer who has expertise in both interactive products and effective communication,” Colleen says. “The writer should work closely with the UI designer.” If you cannot hire a full-time writer, she suggests several alternatives:
“hiring someone who can assist with both UI design and wording
“hiring a freelance writer
“shifting someone from your documentation group into that role”
Describing the role of this writer, Colleen says, “The writer needs to be involved throughout your entire development process. First, to write appropriate interface language, the writer needs to understand user needs, business goals, the experience flow, and more. Then, the writer needs time to craft words, in collaboration with the UI designer. The writer needs to be willing to write in a conversational tone. Next, the writer needs time to receive and incorporate feedback from the project team and testing with users. Finally, the writer needs to help ensure the wording gets implemented correctly.
“For the long term, the writer must have support to develop a style and standards for interface wording. Some of the standards could be incorporated into a design pattern library, which gives more another reason for having the writer and UI designer work closely together. The style and standards will help you maintain consistency across projects, design more efficiently, and reduce the need for crafting language by consensus.”
Pabini also emphasizes the importance of developing style guidelines: “To ensure consistency in the use of terminology, it’s important to document the terminology decisions we make in a style guide. Doing so makes everyone’s work easier.”
Whitney suggests, “One way to test the language in a user interface is to see whether you can easily describe how to complete a task using the terminology you have chosen. If you find yourself creating tongue-twister sentences or talking around your chosen words, you know you have a problem.” To learn more about language and usability, read Whitney’s articles on UXmatters and elsewhere. Whitney also recommends reading Ginny Redish’s book, Letting Go of the Words: Writing Web Content That Works, which “includes the outline of a good process for ensuring the text is useful, consistent, and usable.” Caroline Jarrett’s book, Forms that Work: Designing Web Forms for Usability, discusses “how to use both language and the visual design of the form to make it flow well.” (See Suggested Reading.)
To learn about testing wording during usability testing, Colleen suggests reading about that process in her UXmatters column, “Turn Usable Content into Winning Content.” In the cases where a team cannot reach agreement, she recommends having an escalation process. However, “escalation should not happen often with a good writer who respects the team, a team that respects the writer’s role, and a process that involves the writer from start to finish.” If your management requires further enlightenment, Colleen suggests reading the works of Hall, Kissane, MacIntyre, and Rutter and Halvorson, as well as her blog entry “Content Is More Than Copy.” (See Suggested Reading.)
Ask the Right Questions
To establish a foundation for a good process that incorporates feedback from users, Whitney asks the following questions:
“How does your team learn about—and from—users? Not customers or their IT departments, but the people with their hands on their mouse who will have to use your software day in and day out. If you are not listening to your users as part of your basic user experience design process, you need to start there.
“How do you test your designs? It’s not enough to just look at the text alone. You need to try out the whole interface and make sure all of the pieces fit together. No matter who designs the language, no matter how expert the team is, there is no substitute for usability testing with real users.
“How do you integrate documentation with the product? Your technical communicators have the expertise to help make sure you have not only chosen appropriate words, but words that help make the product easy to explain—and therefore, easy to use.
“Depending on the answers to these questions, your user interface designers and technical communicators might be the right people to decide how the product communicates. They will need good user research to inform their work, input from all the other stakeholders, and a way to test the language they create. But, the words on the screen are part of the user experience and should be designed along with—and with the same care—as all the other parts of the product.”
The Virtues of Plain Language
Whitney also suggests the use of plain language. “The language has to support user tasks. It must include terminology the users can find—or recognize—in the documentation or on the page, use words that fit the way they already think and talk about their tasks, and help them complete their business tasks effectively. Plain language isn’t just about the vocabulary for field labels, but about how communication is part of the user experience. There are also instructions, prompts, and introductions to each task as well as any embedded Help. Writing these texts well is also part of language in the interface, and how they are written can affect the user experience. The Center for Plain Language provides some good guidelines for all communications that apply to the user interface as well.”
A Process Yahoo! Uses
Jim shares the general process the Marketing Products division at Yahoo! uses for creating content: “In our standard process, the User Experience Design (UED) team produces user interface (UI) specifications, describing every aspect of the interaction design. This includes all elements on the screen. To come up with names for on-screen controls, fields, and field descriptions, UED works with and takes input from Product Management (PM). PM and UED agree on the names for these elements and the UI spec reflects this agreement. Our specs also indicate where on-screen information would appear—though they typically use Latin text as a placeholder. We hand off our UI specs to the Content Development team, who create a content specification on top of our UED UI spec. This content spec highlights the specific content and information that appears on the screen. Now, this is what happens when we don’t have contention between groups on what words to use.
“Like everyone, we also have frequent contention on terminology. To resolve this contention, the manager of our Content group recommended a Terminology Normalization Board (TNB), which we instituted. When a stakeholder disagrees with a term, the Doc team files a bug in our bug-tracking system, with all interested parties listed in the bug report. We hold TNB meetings once per week, where everyone presents their recommendations, their data, and their rationale for the terminology we’ll use. We make final decisions on which terms we’ll use in these sessions. The manager of the Content group forces decisions in these meetings, and we record these decisions in an internal glossary. If the TNB cannot resolve terminology issues, we let everyone know the TNB will escalate them to our senior leaders—the VPs of Product Management, UED, and Engineering—to resolve them. It turns out, nobody wants to say we could not come to an agreement and need a VP to resolve our disagreements!”
Jim says, “I have to say, the TNB meetings have decreased the pain involved in terminology decisions, though the number of issues has not decreased. In fact, the TNB decides on between five and twenty issues per week. The difference is that, while we used to iterate for weeks and opinions would get heated, we now solve contention quickly and with much less pain.”
Making Decisions: Owning The Solution
Providing another perspective on the creative decision-making process, Pabini says, “Who should own decisions about the text that appears in a user interface depends on both the nature of the text and the skills of the people on a product team. It’s best if the decision-makers are actually on the product team, because the people on the product team have the best understanding of the product.
“In an ideal world, where everyone on your team has great writing skills:
the UX lead on a project should own all decisions regarding user interface text
the product manager or marketing lead should own branding and marketing text
the technical communicator should own Help text
“The best terminology and text usually result when these three team members work on all text collaboratively. At the very least, they should make decisions regarding key terminology collaboratively. However, when disagreements arise, one person needs to own decisions for each particular type of text.
“And, while it’s great to get input about terminology issues from everyone on a product team, when it comes to actually making decisions, it’s best to limit the number of people in the room—typically, to the three people I mentioned earlier. True collaborative work is difficult to achieve when too many people are involved, because the tendency, in that case, is toward consensus decision-making, which is not the best approach.
“If the UX lead, product manager, or marketing lead lacks top-notch writing skills, that person should work on text collaboratively with the technical communicator or another person on the product team who’s a highly skilled writer—perhaps another person in their own specialty.”
Dave agrees, “Like every other part of the user interface, the language should be owned by the UI Designer, who is responsible for interpreting other stakeholders’ intelligence and perspectives as manifest design elements.” He describes his “joint relationship with Marketing at Motorola. They have better access to users and user research than I do. I am an equal partner and have just short of veto rights when it comes to labels and copy. I try to focus on issues of clarity and understanding. I also work with the technical writer on style, grammar, and style consistency, especially on more sentence-structured items—instructions and the like. On other projects, I take full ownership of the text—just going to Marketing and Technical Communications for support.”
Another advocate for writer involvement in the ownership of text decisions, Colleen says, “The writer and the user interface designer—closely consulting user feedback—need to make the final decisions. While the writer and user interface designer should listen to feedback from the other experts on the project team, their expertise needs to be respected. While we all may be familiar, we are not all experts. We do not all understand the nuances of tone, the impact of connotations, the subtleties of viewpoint, and so on. Trust the experts!”
To establish a sound basis for decision-making, Whitney says, “The people on your team who own the decisions about language need to be confident that they understand the terminology users use, how they talk about their tasks, and their mental models of the business processes your software supports.” In other words, much of what makes us experts is the depth of our understanding of users.
Finally, to our reader who posed this question Dave says, “In the end, it really is all about your team relationships. It really sounds like you need to get your team relationship house in order.”
Most terminology doesn’t need to be invented. It needs to be identified by listening to real users during the product definition process.
I agree that it’s best to have one person as the final decision maker regarding all elements of the UI. This needs to build UX credibility by consistently presenting evidence for their decisions, not just exercising power and throwing around random anecdotes.
Usability testing won’t do much to create terminology, but it can certainly build consensus once decisions have been made. If all of the stakeholders can see real users being successful with the product, they’ll be more willing to accept the use of terminology that wasn’t their first choice. If real users fail because of the terminology that was chosen, and those failures are captured as video snippets, nobody’s going to object to going back and choosing new words.
A great discussion. At the end of the day—and at the beginning of the day for that matter—if user research isn’t informing your UI language decisions, the UX isn’t going to be delightful, persuasive, or profitable.
The most intriguing thing I learned is that there is a Center for Plain Language. What’s next, the Association of Forward Walkers?
Dr. Janet M. Six helps companies design easier-to-use products within their financial, time, and technical constraints. For her research in information visualization, Janet was awarded the University of Texas at Dallas Jonsson School of Engineering Computer Science Dissertation of the Year Award. She was also awarded the prestigious IEEE Dallas Section 2003 Outstanding Young Engineer Award. Her work has appeared in the Journal of Graph Algorithms and Applications and the Kluwer International Series in Engineering and Computer Science. The proceedings of conferences on Graph Drawing, Information Visualization, and Algorithm Engineering and Experiments have also included the results of her research. Read More
