Creating a User Interface That Speaks Your Users’ Language

Creating a User Interface That Speaks Your Users' Language

In this article, we’ll talk about the challenges of writing concise and familiar copy for web application user interfaces.  We’ll illustrate, with a real case example, how tools like Amazon’s Mechanical Turk can help designers find a common language with their users.

Words Matter

A good user interface needs concise instructions. When we label interface elements or write instructions for a given task, we aim for clarity and succinctness.

Succinctness is a fairly simple standard to follow. The shorter the better. Short, familiar labels and instructions are more readable. Long copy can convey more information and may explain things more completely, but designers find long blocks of web copy unwieldy, and for users, mentally taxing (i.e. because people don’t read). The result is that longer copy generally makes for more confusing interfaces.

But a short label must also be clear; and it’s tricky to write copy that’s brief but thorough at the same time. And then what the definition of "clear" is, in the context of your UI, is another (tougher) problem altogether.

We don’t write for ourselves, but for the users, and web users defy categorization and stereotypes. Some are technically savvy, some are less so. Some use their own lingo and some don’t even speak our language.

The Challenge of Finding Common Language

So how do you write succinct instructions in your UIs that are meaningful to your audience? We run into this dilemma regularly with We run a service that lets people build web forms and collect data. We want to make an inherently technical subject accessible to a general audience.

A core principle to boiling down something that’s complex for general consumption is to shy away from technical jargon.

That’s why we prefer to talk about "questions" and "responses" instead of "fields," "labels" and "inputs." We think that most people can understand what these more familiar terms refer to, even if they might appear a bit unusual at first for the more technically keen crowd.

But finding a common language with your users isn’t always that straightforward. In a recent redesign of the interface of our Form Builder (go ahead and try it out for the sake of our discussion, you don’t need to register or anything in order to use it), we reconsidered how we should label the different types of input our users can place on a form.

Here’s our first form element:

The Challenge of Finding a Common Language

The technical name of this HTML element is "select." In the office, we usually call it a "drop-down menu," and from our experience, this is how most English-speaking users refer to it. In our UI, we call it a "Drop Down."

Next, we have:

This one is a variant of a select element, where more than one option can be selected. This element looks and behaves differently than the one above it, yet it’s technically the same element, a select with a multiple attribute.

So what do we call it? We didn’t feel strongly about it, but we came up with the term, "List" and it seemed good because it was concise.

And finally:

What about the one above? We know it as a "radio button," and in our interface, it’s simply called "Radio Buttons." The funny thing is that we weren’t even sure why it was called that way in the first place. A quick look on Wikipedia answered that for us — it’s a reference to the way buttons used to behave on old car radios. You’d push one button to select a preset station and the other selected button would pop out. But that’s not how modern car radios work anymore.

This is interesting because we can hardly hope that using an outdated metaphor is a good way to convey information.

So is there a better way to call it or should we just stick to calling it a "radio button?" We had no clue. It was time to gather some data.

How to Test the Familiarity of a UI’s Copy

Amazon Mechanical Turk is a service that lets you give a simple task to a large number of people very quickly and at a very affordable cost.

We devised a short test. We presented the images above and then asked 50 randomly chosen testers what they called each of those form controls.

The Results

In a matter of minutes, we had our 50 responses. Here’s what we learned.

The Results

No surprise here. The majority of the people surveyed called it a "drop down menu" (or a close variation of it). So it reinforced our existing term for this form element.

The result above gave our testers the most trouble and we ended up with many exotic names. We settled on "Selection List." The terms "menu" and "list" are very similar, but "list" in this case is more distinctive.

Here, respondents seemed more sure of their answer. Yet, a large segment didn’t make the distinction between radio buttons and checkboxes. Also "multiple choice" was a fairly popular term. I suspect this shows a US-centric bias in our tester population, as this control looks like the multiple-choice tests that are common in the US education system.

Since we didn’t have a clear winner, we decided to stick with the technical term "radio button." Any other option would be confusing for too many users, or simply inaccurate. And if we have to teach our users a new term, we may as well go with the flawed but technically correct one.

Testing Your UI’s Language is Quick and Inexpensive

Amazon Mechanical Turk is well suited for short tests involving instant recall, reading comprehension or quick identification. Workers are only paid a few cents per tests so they are not going to spend more than a minute or two on them.

We were able to quickly test and iterate on our user interface’s copy by using Mechanical Turk.

First, we were able to verify that a "drop-down menu" is a familiar term, so we stuck with our existing label.

It helped us make an informed revision of the term "List," changing it to "Selection List" as a label for select elements that had a multiple attribute.

The result for radio elements were inconclusive, so we stuck to the technical term for them, "Radio Buttons."

This simple case shows how simple it can be to test the effectiveness of your user interface’s language.

In the future, we might consider using this same method to get useful insight to questions like, "What do you think is behind each of these tabs?" or for a paragraph of instructions, "What would you do after reading this paragraph?"

A similar site, FiveSecondTest, provides a quick snapshot of viewers’ understanding.

Remote user testing can be an effective way to evaluate and improve the clarity and conciseness of web application copy.

Related Content

About the Author

Cedric Savarese is the founder of Veer West, a software-as-a-service company. He enjoys writing code and prose, crafting user interfaces and running a lean business. You can follow him on Twitter as @cedsav or visit his blog for more on entrepreneurship, bootstrapping and web development.

This was published on Sep 27, 2010


Giacomo Colddesign Sep 27 2010

Great article, it’s very important to understand user’s language..

Irfan Suleman Sep 27 2010

thanks for sharing

Matt Goucher Sep 27 2010

Nice posting. Thanks!!!

Cedric Savarese Sep 27 2010

Thanks for your kind words. Enjoyed writing the article, and glad to see it published here.

Criselle Sep 27 2010

Thanks for sharing! I learned a lot!

Sarah Jones Sep 28 2010

Very informative posting. I will send this link to my Programming team.

Antoine Guédès Sep 28 2010

Such an interesting & really great post. UI languages are so important!

So why is the Radio Button term not valid any more? Even with a modern radio you can only select one preset station at a time. I think that’s the point to the UI element, you can only select one.

Jacob Gube Sep 28 2010

@Dave: I don’t think Cedric meant “not valid,” more like “outdated.” Do you have 5 buttons in your car’s radio that when you press one, the other one would pop up? Yes, you can still only have one radio station, but the UI metaphor, visually, isn’t as relevant in modern car contexts. Now you will typically have a knob/dial that you twist left and right, and that interface is no where similar to a set of radio buttons. And, heck, if I’m too young to even know that that’s why they’re called radio buttons, imagine the new-generation of web developers and users — they’d never realize why they’re referred to as “Radio buttons” when their radios have digital dials.

The functionality is the same, but the interface itself is not, and in fact, vastly different.

And to add, that really wasn’t the reason they didn’t want to use “radio buttons,” that anecdote was just an aside. The reason they didn’t want to use this term, from what I’ve read up there, is that it seems like a technical/unfamiliar term (at least, outside of the context of web developers). But, as it turns out, either people were calling it radio buttons or there really wasn’t any other term people were calling it, so might as well stick to the technical term.

Steve Sep 30 2010

I’m surprised by the radio button responses… I admit that not all would know what they were, but the responses were truly “all over the place”.

Great data and thanks for the reference to Mechanical Turk. I’ve never thought of using it as a way to test user feedback but its so obvious now that I think about it.

Avangelist Oct 01 2010

that’s incredible. I have never heard of mechanical turk before but will certainly look into the service now.

Terminology in applications is often a curse, particularly when the initial descriptions of a requirement are formed from an ill advised or uneducated explanation. A function starts off as ‘we want a thingamy like the bibble bopper on that site’ and before you know it, it somehow has made it into specification and you are builder a doohikie.

It doesn’t mean anything to you and it most certainly will not mean anything to your target audience.

This comment section is closed. Please contact us if you have important new information about this post.