Empower Your Users by Avoiding Language Ambiguity in Your UX Designs

Many of us have experienced ambiguity in words when we hear something like “let me put you on hold for a few minutes”‚ “He will be back in a few minutes”, or when we read “this download will take a few minutes”. But how many minutes is a few? Is it always the same number? It most likely is not.

Likewise, have you ever gone for coffee, bubble-tea, ice cream or dessert and had to decide between small, medium, and large sizes? How confident were you that you would receive just the amount you wanted based on those options?

Since I’m not a frequent buyer of these products, and industry definitions for these sizes are not standard, I find words like small, medium, and large ambiguous, and often need to ask for clarification or be shown the actual cup. If the person serving me cannot clearly describe or provide samples of these sizes, I’m left with uncertainty, and sometimes end up wasting food, or feeling like I didn’t get enough.

The list of ambiguous words we find used to describe size, length, amount, frequency, intensity and more can grow very quickly. While we might use these words very naturally and carelessly in our day-to-day conversations, these words need to be carefully used, if not entirely avoided, when aiming to design a seamless experience with a product or service.

One of the principles associated with the intentional design of product and service experiences is to empower the users. One fundamental requirement to achieve this empowerment is to clearly and timely provide actionable feedback. This is to inform users of what is happening, e.g. what is the status of the task or step they are trying to complete; and tell them what options and actions they have available based on what is happening. Based on this, we need to avoid potential confusion when communicating with our users, and therefore, leave no room for ambiguity.

Major and Minor Delays

Not long ago, we observed symptoms of what seemed to be a failed attempt to improve the empowerment of users of the Toronto Transit Commission (TTC), the public transit service in the city of Toronto.

The TTC, like most transportation services, has frequent interruptions that affect and generate pain for its users. Caring for their users, in an attempt to better inform them on the status of the service, they recently changed the language used when broadcasting delays and interruptions in the subway.

The TTC chose the words “minor” and “major” to communicate the degree of the interruption, expecting the new notifications to better inform the status of the service and soothe the users’ pain.

According to a TTC spokesperson, a minor delay is the one where trains are running up to 20 minutes behind the schedule, and a major delay is where trains are behind more than 20 minutes. This distinction seems to be clear for the spokesperson, and we assume it would be as well for the staff involved in producing such delay notifications.

But based on the users’ feedback via social media and TV, the difference between “minor” and “major” might not be as clear for TTC users, which are expressing their frustration with how the expectations they create based on the notifications are not being met (i.e. it’s minor, it will be resolved very soon), start losing trust in these communications (i.e. responding with sarcasm to the notifications), and that their time and therefore their business is not being valued (i.e. losing 20 minutes of their time is not a minor issue).

It seems like the effectiveness of the TTC initiative is suffering not only from a problem of ambiguous language but also from a disconnection between the designers’ mental model and the users’ mental model.

If the language used in a product or service doesn’t match the users’ mental model, communications using such language might be rendered ineffective, useless, and in some critical cases, potentially dangerous.

How to Solve the Problem

The TTC seems to be refining their communications based on the customers’ feedback, which IS something to celebrate. However, the negative feedback during the release of this notification indicates that insufficient user feedback made its way into the final design. Getting feedback early, iterating and multiple rounds of testing with real users are all needed to make the experience successful.

In general, the first thing that should be done when designing a solution (product or service) is to understand the end-users of such solution. We need to answer questions such as: What are their needs? What are their current pain points? What do they need to remediate them? How do they think? What do they know? And in this case, what language do they use and what do they think it means?

Instead of coming up with a systematic language that is valid internally and expect users to learn what we mean with such language (e.g. small, large, some, a few, several, a lot, minor, major, etc.), we would understand first what works in the minds of users to avoid ambiguity and communicate with clarity what the options are at launch.