Does Bad Grammar Make Bad UX?

Ever since we started creating graphical user interfaces, we’ve been trying to make them friendlier and more usable. Sometimes those two goals coincide; sometimes they don’t.

When space is at a premium, and you need to minimise ambiguity, the most direct approach is often best — which is why the button in this interface says simply “Upload” and not something fluffier like “Upload this file.”

But to me, “Choose file” sounds unnatural. Why? Probably because it’s ungrammatical.

Before you roll your eyes, know that grammar can make your interface text shorter, clearer, and easier to comprehend. We rely on grammar for communication every day: in written and spoken texts.

So why not in your beautifully crafted interfaces?

Let’s go back to the example above. Be warned: I’m going to explain an aspect of grammar in the next paragraph. Remain calm.

As I said, “Choose file” is ungrammatical. We can command someone to “Play ball” or “Eat Spam” because in those contexts, ball and Spam are what we call collective nouns — they’re not referring to a specific ball or a particular tin of Spam. But the noun “file” can’t be collective: it’s either singular or plural.

So grammar dictates that the singular form must have an article — like “a” or “the” — before it.

The bottom line? For the sake of two more spaces, we could make the instruction say, “Choose a file”, which to the average user sounds much less like a robot and much more human.

Add small changes like this up over thousands of interfaces, and you can start to see how it could make a difference to the way your users feel about your service.

Great! Easy! Well, not always…

Striking a balance

Designers know that using one font for all H3 headings, for example, indicates to users that the information under each heading sits at the same level of “depth”, or has equal “weight” to the others in the overall scheme of a piece of content.

So the interface designer has given equal weight to the two user options shown below: they take the same font, and each has an image.

But the text gives more weight to the “save as pdf” option — why isn’t it just “save”, to match the other choice’s single-word label?

I’m guessing accessibility would have been the motivator. Print means print, but the word “save” doesn’t indicate the format on its own, and since low-vision users might not see the PDF icon, the text needed to repeat that information. So maybe this isn’t a case where parallel construction is possible. There’s no point expanding the “print” label for the sake of adding words.

What about good old grammar? Constructions like “save as pdf” and “save to pdf” are both ungrammatical — we’d never write them in prose. We might say “Save this as a pdf” or “Save it in pdf format”. But you can see how once you start down this road, you can quickly find yourself adding needless bloat to interface text.

Instead, I’d go to the other end of the spectrum, and make the label: save (pdf).

It’s simple, it’s shorter, it expects the same level of understanding of the user, and — yes — it is grammatical.

Look who’s talking

So far we’ve looked at small, straightforward interface examples. If you’re the kind of designer who thinks your CMS interface, for example, doesn’t need to talk to users in their own language, you might be thinking none of this applies to you.

So let’s look at a retail example: the Book Depository.

Remember how I said a lack of application of grammatical techniques like articles can add up? Here’s a great case in point. Applying the couple of principles we’ve already discussed, let’s see how we can make these labels less like something a robot would say, and more like something an approachable brand would say:

1. Login/register

   Login or register OR Login | Register

2. Search for books by keyword/book title/author/ISBN

   Search on a book title, keyword, author or ISBN

3. Find book

   Find books OR Search for books

4. Currency selection

   Choose a currency

5. Go to basket/checkout

   View your basket OR Checkout

If you were really going the whole hog, you might also consider making “Track order” “Track an order” or “Track your order”.

One of the main issues with the labels in this header is the use of slashes. A label that says “Login/register” isn’t going to jump out at a scanning first-time user who’s looking for a typical Register call to action. Similarly, “Go to basket/checkout” is just plain confusing. Which is it: the basket or the checkout? Why not just call it that?

And that Search instruction is truly mind-boggling. First, the text is small. Using slashes instead of commas and spaces makes the whole thing run together, making it even more difficult to read. And in the context of this being the Book Depository, and that big fat “Find book” button, we can probably dispense with the first instance of the word “book” in the instruction.

The alternative text I suggested above is shorter than that on the published page, as well as being easier to comprehend. Win:win.

Clearer interfaces, clearer communication

It’s true: sometimes grammar is the interface designer’s nerdy but smart friend!

Don’t waste time and energy creating a gorgeous, friendly brand, but let computer-speak creep into your interfaces. With the kind of grammar we already know, we can carry those brand values through to the smallest snippets of interface text — sometimes making them more compact, but in every case making them more communicative.