Does Bad Grammar Make Bad UX?

Tweet

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.

20140131-064821.jpg

No, not that kind of bad grammar.

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.”

choosefile

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.

Robot UX

“Choose file, puny human”

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.

saveandprint

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.

bookdepository

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.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • mikebirch

    The second example doesn’t read well to me. Surely people search “ON” the website “FOR” whatever they’re looking for.

  • Paul Gregory

    As web GUI designers, we can’t actually make the instruction in the first screenshot say “Choose a file” instead of “Choose File”. That’s a browser/OS thing. I can’t take the rest of the article seriously after such an error. If you’re suggesting things that can’t be done, that rather suggests that you’ve not tried these in the field. What use is untested advice?

    Although I’m a fan of good grammar, the web has a grammar of its own. If people are web-literate, they are familiar with the robotic conventions of web grammar. Proper English may actually be more confusing!

    • George Scott Mammarella

      I do not think the author meant it literally that you should change or override the standard browser conventions, but rather communicating her idea through an example piece of interface we should all be familiar with.

      I think it’s silly to disregard the entire article based on “such an error”. Surely, you’ve seen custom file pickers SOMEWHERE. The idea easily applies there, and the example is easily extended elsewhere.

    • Georgina Laidlaw

      Hey Paul,
      Thanks for your comment :) I spend my days making button and form-field text (among other text) more grammatical “in the field”. And most times I’ve mentioned changing browser-controlled text the answer’s been the one you’ve given: doable, but too hard to be bothered with. Does that mean it’s not worth considering, arguing a case for, or doing? I don’t think so :)
      Georgina

      • Paul Gregory

        It’s worth considering, but personally if I’d raised an idea multiple times before and been knocked back most times for it being too hard to implement, I wouldn’t use it as my lead example of “small changes” that “could make a difference to the way your users feel about your service”.

        Out of interest, would you foist ‘Choose a file’ on all users, or just Webkit users? What do you think of the grammar in ‘Browse…’ and ‘Choose’, which other browser users see?

        • Georgina Laidlaw

          Hey Paul,
          Grammatically, it’s a tiny change. And as I mention in the piece, these tiny changes add up.

          In the context of the point I made in this article, Browse and Choose work fine from a voice standpoint, as do pretty much all single-word buttons and labels (though they don’t always work in context). But of course simplifying “Choose file” to “Choose” is, as much work as adding “a”…

          To be honest, I can’t understand the vitriol around grammar and language discussions. It seems you have more of an issue with the way I presented the case in this article, rather than the actual ideas presented. Language—and therefore grammar—is part of UX. It is one of many elements of experience design. I’m not having a dig at designers; as a writer who works with interfaces, I am on your team.

          • Paul Gregory

            What exactly is the case you’re presenting? It seems to be “Users will feel warm and fuzzy if you tweak the language on your buttons and links”.

            I don’t know how articles are subedited here, so I don’t know if you chose the title “Does Bad Grammar Make Bad UX?” yourself. I clicked through to this article based on the title, and I expected the content to provide some sort of answer.

            I expected that answer to be Yes, and I expected examples which would reinforce my existing belief that language usage is important.

            Instead, I got suggestions of tweaks without any evidence to suggest that any users other than yourself actually thought the original experience was bad or that the rewording was better.

            I don’t agree that the grammar featured is bad, and I don’t agree that the UX featured is bad.

            It’s probably worth pointing out that I do not believe that “bad grammar” and “ungrammatical” are the same thing.

            I don’t think I can express just how disappointed I was with this article. Yes, if it was presented differently I may have had different expectations.

            As for vitriol: when you start to argue on nuances, it’s difficult to broadly agree and so it brings out some pedantry and very specific disagreement even from people like myself who agree this is an area worth thinking about. (Maybe even *especially* from people like me).

          • Christian Bonato

            You seem the kind of guy who won’t even bother spending 5 minutes on Stackoverflow and copy-paste a JSFiddle for a standard browser button replacement, and here you are ranting and calling yourself a “Web UI designer” ?

            FYI, the “U” stands for “User”. This article is a good one on a subject too often overlooked by so-called UI designers.

          • Paul Gregory

            Hey, I override browser buttons when it makes sense. When it doesn’t, I respect the user’s browser choice. It’s less to test.

            I wear many hats (including that of user), and thus do not need to make ‘designer of web UIs’ fill all my time.

    • Christian Bonato

      Nonsense. We were dead serious about it in 2000 when I was working at Amazon. As a designer, you can spend a great amount of time considering this or that phrasing. It is not a UI matter, it’s a UX one. Websites such as Mailchimp (I’m not going to mention FB, far too obvious) carefully choose their wording, because they convey the brand’s spirit. And if the wording can establish a connection between the user and the app/website/webservice, then your call-to-action UI elements are more likely to be clicked.

      “I can’t take the rest of the article seriously after such an error” ? Man, you are a robot indeed…

      • Paul Gregory

        Which bit is nonsense? You’re saying phrasing is important. I agree that phrasing is important to UX – I just believe accuracy is important too.

        Here’s what the article says.

        > 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.

        This is not wording that has been carefully chosen.

        Firstly, it’s two spaces and an ‘a’. An error that can be ignored; the spirit is that it is a small change of that scale. It does not say “for the sake of 5 minutes picking up code to override the default”.

        Secondly, because it is a browser override, on some systems it’s a different phrase! I can’t ignore that! You cannot make serious suggestions about After without fully understanding what Before is.

        So yes, I prefer to leave the ‘robotic’ “Choose file”/”Choose”/”Browse” text well alone unless there are other reasons for changing the entire element.

        Is it robotic to think that an obviously inaccurate statement is an indicator that the rest of the article is not trustworthy? To spot the difference between theory and practice?

        Or is it robotic to assume that because I find flaw in the article, I disagree with the premise? Things are not so binary.

  • guest

    I think the author of this article misunderstands the word “ungrammatical”. An ungrammatical sentence would be “Choose one files”. That’s ungrammatical. Shortening a sentence, switching to “telegramme style” by leaving out the article “a” is not ungrammatical. Also, while I agree that a complete sentence like “Choose a file” sounds natural and more human-like, I don’t agree that it’s better. I don’t expect from an interface to sound natural all the time. When it’s telling me to choose a file I don’t need it to sound like a person talking to me.

  • Andrzej Michalski

    The criticism is a little unfair here as I think the general point of this article is valid. In fact I’d say it’s very relevant what with the rapid increase of typically poorly written communication (blogs/tweets/etc). Too many creators of content get obsessed with the layout and graphical elements and don’t pay nearly enough attention to language.

    I’d go further still and recommend that you develop a house style for the language you use: an appropriate voice for your site. Get this right and you’ll find your users are even more likely to empathise with the content.

  • Georgina Laidlaw

    Hey everyone, thanks for your thoughts on this topic.

    It’s particularly interesting to me to see the strong argument *against* what I propose yet no comments provide any argument for *not* giving this a try. Paul says “proper English may actually be more confusing” – and the need for care with this technique is mentioned in the piece – but from what’s here, the disagreement seems to stem from conservatism alone.

    If there are good reasons not to try this where possible, I’d love to hear them.

  • Georgina Laidlaw

    Mike, thanks for your comments – and for arguing a grammatical point. I reckon most people would view articles as a grammatical concept, which is why I couched it in those terms.

    Your example “To waiting room” jars with me, probably because it’s out of context here on the web. I like your “search for” point very much. I’d argue that as well as searching for something, people do understand the context of using a search engine to search *on* a topic or concept or idea. But at that point maybe we’re splitting hairs :)

    • Raith

      Hi Georgina. I don’t think you are splitting hairs but may have run into another hurdle in your quest for more grammatically acceptable button text shortenings… localisation. In the “search for X by Y” example, I know what X and Y will represent. But as a UK English speaker I don’t know what “search on Z” means. I would search FOR books, or search BY title. Search ON title might just work with me, but not search ON a book. I would also sort or filter BY rather than ON. An Americanism I have often heard is to “wait ON X” where X is a person or an event. In the UK we would wait FOR that person (to arrive/finish/be ready) or the event (to happen).

      Abbreviating UI instructions/sentences will require judging which are the most useful words to keep; and that will need to take international usage into account.

      I’d welcome further information on the usage of “on” in US English grammar. It’s unfamiliar to me and I’d like to know if it has usage rules.

    • Raith

      Another word that comes up in user interfaces, and which has kept me awake at night, might also be a US vs. UK English split… “expiration” or “expiry” for dates?

      To me (and this might only be MY personal spin on things) food, licences and vouchers expire on their expiry date. Whereas the day I die will be my expiration date.

      I might be wrong to apply that nuance. But it’s just meant to be another example of localisation getting in the way of UI abbreviating. The fewer words we use; the more meaning each remaining word conveys!

      • Paul Gregory

        Are you saying that when filling in a payment, you have to stop and consider whether you are being asked for your credit card’s expiry date or the date you expect to die?

        • Raith

          Where ambiguity exists, I consider all options :-)

          Some contributors to this thread already dispute that the original points were, strictly speaking, about grammar. We are discussing wider aspects of getting the right message across clearly and succinctly. Although in this case I was just angling for the American preference between expiry and expiration. Do you know?

          I added this question after making a US vs. UK observation in a different post, but the items don’t seem to appear in time order, so my already-tenuous point was stretched even further :-(

          • Paul Gregory

            Actually there’s a good point that comes out of this – if you’re trying to get users to fill in details from their card, it would make sense to use the same language as the card. A Google image search for “Visa usa credit card” and “visa uk credit card” shows that US cards say “Valid thru” and UK cards say “Expires end”. And some Australian cards say “Until end”. (The other date is “Valid from” in all.)

            Most of these could be considered “bad grammar”!

  • Kristen

    I thought I’d offer another view. As the ‘interface designer’ responsible for the ‘save as pdf’ example, I can confirm that ‘as pdf’ was included for accessibility reasons. I’d also add that it was a minor decision made in a very major project. A project that took the importance of writing user-focused content very, very seriously. From memory, the visual treatment of these elements was slightly different, but the time it would take to implement was not feasible. As a ux designer I evaluate all decisions through the lense of ux, but I must also prioritise tasks. Unfortunately sometimes there just isn’t the scope to sweat the details. You accept that trade off and hope that the next person along will have the opportunity to continue the work you started.

    • Christian Bonato

      “PDF” would work. The “save as” is redundant nowadays. We’re in 2014, folks. If you’re aiming to also please your grandma, keep in mind she probably doesn’t know what a “PDF” is in the first place.

      We are responsible as designers to match the present and constantly evolving users abilities. Long are gone the days when people didn’t know how to right-click.

      • Kristen

        A whole bunch of user research would prove you wrong, Christian. I enjoyed the grandma comment though.

        • Christian Bonato

          Give her a hug.

          It’s like imperative and declarative code. Sometimes I think we have to stop reading statistics and polling users : they know they are being polled, how can we expect genuine reactions ? A-B testing on wording ? Who’s got the budget for that ?

          I say we are the ones in charge, let’s simplfy and streamline the interfaces. It’s up to us to play Steve Jobs to persuade the clients that they must adhere to good ideas.

          “PDF” alone, with a proper FontAwesome “save” or “download” icon would work, trust yourself, not some dumb dashboard metrics.

          Honestly, how can we be so slow in educating the users after the iPhone UI has made such a statement for simplicity embraced by the world ? The users have to adapt to your interface, not the other way around.

  • exex zian

    A lot of comments upon argument but I would like to take it as “A Good Reference For Taking Good Points Out of it” as some of the point and the article theme as a whole makes lot of sense.
    Nice Article @georginalaidlaw:disqus

  • Jacqo Le Bourhis

    “Choose file” is fine. It uses the imperative and it’s clear. Short and sweet. “Browse” is imperative and we see it all the time.

  • Jason McGovern

    I really liked this article. Without getting too hung up on the details, I think it’s very good advice to stress being more conscious of how you communicate your message, your content. You want to build a relationship with your customers, viewers, readers, followers, etc. I agree with most of what Georgina recommends. As for the comment by Kristen, in a way I totally get it, because I’ve been there where you have to prioritize things, and hope the next person runs with your work in the next iteration. However, with that said, I think it’s very unfortunate that so many projects do not start with content first. Content is king, it can’t be the ‘thing you slap on at the end.’ Much like mobile first design, content driven design needs its proper due respect. Whether you agree with Georgina’s specific examples or not here, her message is overwhelmingly spot on, which is the voice behind every element of your design needs to be consistent and optimized as much as we would do for the design itself.

  • Grant Wesley Parks

    I don’t think save(pdf) is “grammatical”. To a user it would be less clear than “save as pdf”. The numbered list at the end of the article would have an impact of about 0. “First, the text is small.” WTF? We’re suddenly talking about font size?

  • Raith

    “Login” is horrible anyway. It should be “log in” if we are referring to the action, and it still sounds uncomfortable to me. I personally prefer “sign in”, which at least sounds like something people do when visiting a building. Perhaps it should really be “identify yourself”…?

    • Christian Bonato

      “Identify yourself” sounds a bit HAL 9000 to me :-)

      I’d vote for “Sign in” any day.

  • Raith

    The problem with trying to get the grammar right with technical systems, is that you are starting from a losing position. “Save as pdf” might sound dodgy, but “save as a pdf” is no better. What is “a pdf”? PDF is an acronym for Portable Document Format, so a file in that format is “a pdf file”. What format is that file? “PDF format”?? “HTTP protocol”??? I agree that “Save (PDF)” is the best compromise.
    The tech world has so many names and acronyms that get wrongly used as nouns and verbs, that you have lost the grammar battle before you start. I think we’re even using them as adjectives now… according to my colleagues I am too XML-y!

  • Sam Bennett

    Good grammar, syntax, etc. I believe are as mcu a part of a top of the line website as anything else. Ultimately web sites present content to read. Websites should whenever possible write clearly, without jargon or exclusive words. Sometimes in any field there are words you have to use. But if you think using big words, jargony writing is a sign of expertise, you are sorely mistaken. “Sir, you seem to have eaten a fod that not only disagrees with your stomach, but is offensive to my nostrils. Hey, think you could stop farting in the plane? These are extreme. The former may be good if you’re writing a novel. The latter is something more of us would under understand, even if a bit crude. If you are having trouble finding a suitable replacement, use a Thesaurus.and remember, the average reading level for Americans is barely fifth-grade. If your work requires a dictionary for every word, then you are overwriting and nobody will be able to understand what you’ve written, or why. And after all, isn’t that what we want people to do, use the web to understand the world.

  • Christian Bonato

    Of course. The right-click was an exagerated example. I would never designed a public or intranet interface that requires a right-click somewhere.

    I’m just saying that iOS has introduced some UI idiosyncracies and minimalisms that a great deal of people are nowadays accustomed to.

    But of course it’s all a matter of audience. If I were to build a retirement home website, I would use 24px as the default font size, and stuff like that.

    • Kristen

      Give him a hug.

      • Christian Bonato

        Have you hugged your dev today ? :-)