Language can teach us about usability

I think that the way people use language can give some insights into the usability of the software we design and build.  By definition, if you’re reading this then you use language, and also use some kind of computer, and in this post I’ll try to show how what we have already observed about language can help us build computer systems better.

Before I start I ought to point out that most people have a view about what’s right and wrong in language, including me, and we don’t all agree.  I shall try to keep my prejudices about this kind of thing to myself as much as possible.  One person’s careful language user is another person’s pedant, and pedantry is rarely fun for anyone other than the pedant.

Mistakes from difficulty

This is immediately into right vs. wrong territory, but I hope it’s not controversial.  There are a few nouns where the plural is easier to say than the singular, just because your mouth has less work to do:

• Phenomenon / phenomena
• Criterion / criteria
• Medium / media
• Stratum / strata

All the singular versions end with the airway closed in some way – either tongue against the roof of the mouth (the first two) or lips together (the last two).  All the plural versions end with a more relaxed sound.  The technical name for this is schwa, which is a neutral kind of vowel sound, and not the same as a more definite vowel sound like in cat or dog.

In my experience, it’s a fairly common mistake to say e.g. criteria rather than criterion. They’re similar words, as they’re both nouns with almost the same meaning as each other.  However, the “wrong” word is easier to say than the “right” one.

It could be there’s a similar common kind of mistake that people make when using your GUI.  Instead of clicking the “right” button they consistently click on the same “wrong” one.  In this case it’s worth examining the two buttons.  Do they look similar, or do similar things, such that when a user’s hunting for what to click on they could reasonably pick either?  Is the “wrong” one easier to click on than the “right” one?  For instance, the user has just clicked on a button to do step X of a task, and is now looking for what to click on for step X+1.  If there’s a plausible looking “wrong” button next to the button they’ve just clicked, and the “right” button is further away or more hidden, then don’t be surprised if the “wrong” button is clicked.

Make it easy to do the right thing, and harder to do the wrong thing.  Make it easy to recover if the wrong thing is done.  The first one can be known as helping the user fall into the pit of success.  The last one can involve providing an undo option, which is nice if you’re a user but can be surprisingly hard to implement.

Mistakes from models

When someone says the wrong word, often it’s quite close to the correct word.  So instead of saying “Please pass the salt”, they might say “Please pass the cucumber”.  It’s less common to say “Please pass the cement mixer” or “Please pass the extravagantly”.  This is different to the previous point about mistakes as it’s not to do with how easy or hard it is to say different words.  Instead it shows that the person is using a mental model to help them use language.  This model contains the syntax rules of the language, but also rules to do with meaning, context and so on.

The person knows they want to say a word that refers to a noun to do with eating, that might be expected to be found on a table, and could be easily passed from one person to another.  Their model of language means that salt and cucumber are both in this category.  A mistake is likely to cause them to stumble from the correct word to a nearby word, such as cucumber.  Salt and cement mixer have much less in common, and salt and extravagantly have even less, so it’s less likely that they will stumble from salt to either cement mixer or extravagantly.

Whether we like it or not, users will have a mental model in their head when they use our software.  This model will help them translate their goals (e.g. sending an email) into a series of actions (e.g. clicking and typing).  So that our users can be successful when using our software, we need to help them easily create a mental model that is an accurate reflection of how the software works.  This means cause and effect need to be obviously linked, conventions should be followed where appropriate, there should be consistency across the different parts of the system and so on.

Note that this extends to testers, who are a special kind of user.  How testable is your software?  Are you getting bug reports that you consider to not be bugs, but are instead the result of a tester’s mental model not matching up with reality?  Why is that?  Can you improve the testers’ chances of forming an accurate mental model?

Consequences

There are phrases like

• That was the best night ever;
• It’s literally raining cats and dogs;
• This is the ultimate driving machine.

The phrases start with one meaning, which is reserved for the extreme version of something: Of all possible nights ever, this was the best one; there are cats and dogs falling from the sky; this car is better than all other cars.

For effect, the phrases are applied to things that aren’t the extreme: That was a very good night, and because I want you to understand how much I liked it I will tell you it’s the best night.

Using the phrases like this has two consequences: the effect happens (I understand how you feel about the night), and the phrases’ link to the extreme version of things is eroded.

For instance, if you say “it’s literally raining cats and dogs” to mean it’s raining hard, what words do you use to tell the other person that there are cats and dogs falling from the sky (and it’s not merely raining hard)?  I’m using raining cats and dogs as a deliberately absurd example – phrases like “I literally died” being used to mean things like I felt really bad are less absurd.

The consequences are different: one is obvious and immediate (the effect), and the other is more hidden and longer term (the change in meanings).  This makes it easier to notice and predict one than the other.

The same is consequences of doing things via a GUI – they’re not all equally easy to spot ahead of time.  If a user clicks on something during online shopping, do they know if they can easily change their mind?  If they delete something, can it ever be brought back?  The user shouldn’t be surprised by your user interface, any more than they should be surprised when they use a hammer or pair of scissors.

Try following conventions, be consistent, and if all else fails add explanatory text and an undo option.

Difference and variability

British English and American English differences can be amusing to people who speak either version: for instance bum bag vs. fanny pack.  Even if people from different areas use the same words, they could pronounce them differently.  There is a famous experiment in sociolinguistics that showed how social class was reflected in the way someone spoke.  I really love Jodie Whitaker singing Coldplay’s Yellow in her own normal accent.  It means the song comes from her heart, not a poor reflection of it coming from someone else’s.

We accept the variability in how people use what’s basically the same language – in this case, English.  However, we often gloss over the variation in users and how they use our product.  This temptation to ignore variation in users is even harder to resist when we use our own product.  Even if you are a user, are you identical to all users?  How do you know this (rather than just assuming it)?  Do all users come to the product with the same goals and experiences as yours?  With the same amount of concentration, the same motor skills and eyesight, using the same device as yours?  And so on.

Don’t design for what you (or your boss) think is good: design for what your users think is good.  If you don’t already know this, find out.