The Tale of the Toaster and the True Cost of UI Content
Recently, I was asked to help make a case for why terminology and consistency matter in a user interface (UI). Frankly, I was surprised that a case needed to be made. After all, doesn’t everyone understand the importance of a clear and consistent UI? Apparently not. Here are a few things that I pointed out.
From a customer perspective, your UI is your product. What goes on in the background to make your product work is not visible to your customer. Therefore, it is not “the product”. Regardless of whether your product is physical, such as network hardware, a toaster, or a toy, or if your product is an application or software, the user interface is a critical component.
Terminology and Val’s Toaster
Let’s take a toaster. In fact, let’s look at the toaster in my kitchen:
The UI of my toaster has a number of labeled buttons. And they don’t all make a lot of sense. For example:
It took me more than a few minutes to figure out what to do when I wanted to bake cookies, not pizza, and I didn’t want to use the convection feature. Because I can bake lots of things in addition to pizza, the term pizza is confusing. I’m not sure why Cuisinart decided to label the button with that term.
Another toaster UI problem is the language around the up and down arrow buttons. These two buttons are labeled in three different ways:
- Up and down arrow icons
- The words UP and DOWN on either side of the TEMP button, next to the up and down arrow icons
- The words DARKER and LIGHTER on either side of the TOAST button – located rather far away from the up and down buttons that they are meant to label
In this case, too many terms are too much of a good thing. When I first used the toaster, it took me a moment to understand that to make the toast darker or lighter, I was supposed to use the same buttons that were labeled UP and DOWN. Both the wording and the placement of the labels threw me off.
Reasons to Care about UI Strings
With the toaster, I can keep pushing buttons until I have the correct sequence figured out. There is something physical for me to touch and I can see when the heating element warms up. With software, it’s not necessarily as easy. All I have to go on are the UI strings that are displayed.
If you use incorrect terminology, poor grammar, or inconsistent messages in your UI, your customer can end up being unable to install, configure and/or use your product. If you misuse your own trademark in your UI, you can violate its usage terms. If you misuse someone else’s trademark, you can get in big trouble.
Here are some reasons engineers need to pay attention to the UI strings they create
- An inconsistent or poorly worded UI can make your product unusable.
- A poor UI can lead to more product returns and an increase in support calls.
- A poor UI can harm your brand.
- Not paying attention to trademarks can cause legal problems.
- Inconsistencies in your UI make it more difficult and much more expensive to translate.
The True Cost of UI Strings and Translation
Translating UI strings is a process that few engineers consider when they create a UI. Here are some translation issues to consider:
- Multiple versions of the same string need to be translated multiple times. For example, each of the following strings have the same meaning:
See your system administrator for more information.
For more information, see your system administrator.
For additional information, see your admin.
Consult your system admin for more information.
You get the idea. Each and every variant of the string increases the cost of translation accordingly. If you use the same string over and over again, you don’t have to pay to have it retranslated. In addition, by using the exact same string over and over, your users are less likely to become confused.
- The fewer words you use in your string, the cheaper it is to translate. I once had a customer that used the word Please in every error message. Please see your system administrator. Please click okay. That one little word, Please, ended up costing the company thousands of dollars to translate. Limit the number of words in your UI strings to only what is necessary. Please adds no value and a lot of unnecessary expense.
- Text expands in other languages. For example, when you translate from English to German, I suggest allowing for a 30% expansion of the text. Make sure your screen layout is designed to accommodate the longer terms. I’ve seen many examples where the translated term exceeds the boundaries of the button on the UI.
- Some languages read from right to left. I’ve worked with companies that forgot to account for languages such as Arabic and Hebrew. The screen layout did not support the UI strings when they were written out “backwards.”
- Some languages swipe from right to left. If the language reads right to left, you can pretty much assume that those readers swipe from right to left, as well. You have no idea how often this seemingly benign fact causes a huge problem at the very end of a release cycle. Or maybe you do.
- Some words really do go together in that other language. Make sure that you get input from your translator (or a native speaker) if you need to move words around in the UI. A term in English could be made up of one word, while that same term in another language uses two or more. If you split the sentence in the wrong location, you might end up with either an embarrassment or a mess.
It is important to treat the UI like any other content that a customer needs to interact with. Whether it is labeling the buttons on a toaster or creating a UI string that will be translated into 42 languages, the point remains: The UI is the product. The customer interacts with the product. You want the customer to love the product. So, let’s make it as easy as possible for the customer to use the product.
Also, I’m happy to say that I am now fully capable of using my toaster.
When not blogging, Val can be found sitting behind her sewing machine working on her latest quilt. She also makes a mean hummus.
Latest posts by Val Swisher (see all)
- Three Best Practices for Creating Global-Ready Video - May 19, 2016
- Musings on 22 Years of Content - May 12, 2016
- The Many Sweet Flavors of Content Taxonomy - April 25, 2016