Terminology

The words you write in your product have huge power—to guide and comfort users, or if written poorly, confuse and alienate them. This section includes shortcuts and best practices to take your in-app copywriting to the next level.

Be Consistent with Terminology

The words (or copy) that you write in your product have a dual purpose. The first is the most obvious: they label items and views and tell the user which elements are which.

The second is less obvious, but more important: the words you use become a very precise and descriptive language for your product. Understanding and parsing this language is essential to a user forming a mental model of how your product works.

• If you call your e-commerce shopping cart a “cart,” then call it “cart” everywhere
• If you call your user’s profile page “profile,” then call it “profile” everywhere
• If you call your user’s email settings “email settings,” then call them “email settings” everywhere

Mix these up and it will take your user longer to ponder the inconsistent terms and work out what you mean.

Think also about the tone of voice...

Use “Sign In” and “Sign Out”, Not “Log In” and “Log Out”

Everyone has signed in to attend a meeting or visit a doctor or dentist. Signing in is something that people do in the real world. Nobody alive today has ever “logged in” in the real world. The term comes from the ship’s log, where the sailor would log in their times and the distance traveled that day. It’s highly unlikely that your users are 18th-century seafarers!

Despite this, it’s pretty common to see “Log in” (or, even worse, “Logon”) in software, and especially in business-to-business software that’s been designed by developers.

For reasons of familiarity, always use “Sign in” and “Sign out” in your product consistently: they relate back to the real world, unless your product is a mobile app for time-traveling pirates, of course.

Learning points

...

Make It Clear to Users If They’re Joining or Signing In

The principles in this section discuss the confusion of terminology, and in 2022, as I write this, there are few signs that these terms are beginning to standardize. Apps and websites still feature a confusing mix of “Log in,” “Sign in,” “Login,” and so on.

But it’s more than that—the interaction flow of your product should make it clear to users whether they’re joining (for the first time) or signing in (as a repeat user). Seldom-used products will often require a sign-in when you come back to them, and more secure applications need a sign-in every time—often with two-factor authentication. So, let’s make it easy for users to get back into your product.

Figure 91.1: This wireframe shows a clear way to solve this problem—why doesn’t every app do this?

A theory for this “sign-in obfuscation” is that...

Standardize the Password Reset Experience

Password resets are a frequently used part of the sign-in experience. Users will make mistakes and, as UX professionals, it’s our job to help them out as best we can.

When it comes to passwords, unless you’re using a password manager, you’ve either got a password that’s way too easy to remember (and way too easy to guess), or you’ve forgotten your password.

Allowing users to reset their password with an email or text message is a useful pattern, and it’s so well-known that it should be standardized by now. Even so, there are plenty of examples around the web and in mobile apps where unusual terminology or UI makes it unnecessarily hard to reset a password and get back into your account.

Call the control Forgot password and not Reset your password, Can’t access your account?, or Get a reset link. Most users won’t necessarily understand that this is the route for their most...

Write Like a Human Being

Too often, terminology in software is written from a systems-oriented or organization-centric point of view. Consider a CRM or other business system: we often see menu options like Edit customer or Create new customer, but stop and think about this for a second—customers are people and we don’t create them. The first option doesn’t actually edit a customer and the second doesn’t create a new customer.

For the developer, customers are just database records, so of course it makes sense to edit them and create new ones, but for the users of these systems, these options should be better named: Edit a customer’s details and Add a new customer.

This principle is best achieved through objectivity and empathy. In other words, being able to step outside of your view of a product and see it through a customer’s eyes. You must take this step to build usable software and it’s worth the effort.

The words that...

Choose Active Verbs over Passive

Most of this book is concerned with using visual design to improve the user’s experience. However, the words that we use as designers also have a huge impact on the usability of the products we create.

10 years ago, I found myself on a half-day course by the Plain English Campaign (the body behind the “Crystal Mark,” for documents that are easy to read and understand). There were a lot of great tips on the course, but the section on the active and passive voice really stuck with me:

A verb is in the passive voice when the subject of the sentence is acted on by the verb. For example, in ‘the ball was thrown by the pitcher’, the ball (the subject) receives the action of the verb, and ‘was thrown’ is in the passive voice. The same sentence cast in the active voice would be, ‘The pitcher threw the ball.’

– Dictionary.com (definition of the active (https://www...