On naming buttons

‘Jim’

The End.

Okay, maybe not. What I’m actually talking about is the language we use in the software we design, specifically when it comes to buttons. Gone are the days of ‘Click here to ‘ and now, we as designers and researchers spend much more time getting the wording on action buttons correct. Fabulous. The only problem is that we can spend an awful lot of time applying this on a case-by-case or project-by-project basis going round and round on a ‘Nononono, it should say *this*!’ point. So, is it possible to save ourselves some time by coming up with a set of principles that can then be applied to most-if-not-all instances?

To explore this, we must first understand the role buttons play within the context of the site/piece of software. At its simplest level, interacting with software is a conversation between two parties. It comprises the user (or customer) who wants to request a service, accomplish a task or look for information, and the software (the customer service bod, for the sake of argument) that politely welcomes them and provides them with information, appropriate guidance and facilitates the accomplishment of tasks. It should be like good customer service minus the idle chitchat or comments about the weather.

Testing testing

The role of an action button in the conversation is two-fold: It provides an invitation to the user, to which the user can then respond. It also provides the vehicle for the user to respond. Essentially, it asks: ‘Do you want to do a thing?’ and allows the user to respond ‘Yes, I want to do a thing’. The text on the button needs to cater for both posing the question and allowing the user to answer.

Armed with this, you can use the ‘test’ button text to see if it fits this model.

Amazon’s product page passes with flying colours. We have two buttons: Add to Basket and Add to Wish List. ‘Would you like to [add to basket]?’ ‘Yes, I would like to [add to basket]’. The wish list button adds some more information to the question: ‘Would you like to add to wish list? If so, the default or another one?’ ‘Yes I would like to add [this] to a wish list’.

Facebook passes the test too. Have a gold star.
Expandites/default/files/blog/assets/uploads/2014/03/Facebook.png”>

Microsoft’s OneDrive distils labels down to just the verb, the key action, letting the context of the page and the current point in the user’s journey (here, selecting a file within OneDrive) fill in the rest. It’s still effective. ‘Do you want to download [the file you have selected]?’

There are some that get it wrong. Very wrong. Google’s ‘I’m Feeling Lucky’ isn’t greatly helpful, but it wouldn’t be the ubiquitous Google homepage without it, and it’s an exception that proves the rule.

Verbs, verbs, verbs

The verb is the most important element. It’s the action on offer, and it satisfies the ‘Do you want to’, ‘Yes, I want to’ test and can be effective as the sole piece of text on an action. Try and keep button text as concise as possible, using the surrounding context of the task/journey/site/page to support this. Words can be implied too, e.g. ‘Find new friends’ can be distilled to ‘Find friends’.

My/Your

As a final point, and to address another common issue that crops up with button text: the ‘my’, ‘your’ problem. This is one that’s been around the houses a bit but they both have a place in different circumstances. The MS Windows UX Interaction Guidelines suggest:

“Use the second person (you, your) to tell users what to do.” – Use ‘your’ for requests for information during stepped processes. E.g. ‘Choose the pictures you want to print’.

“Use the first person (I, me, my) to let users tell the program what to do” – Use ‘I’ for instructive ‘Do something for me’ text. E.g. ‘Print the photos on my camera’.

Following these guidelines has saved many a long, agonising and unnecessary discussion.

For more information on creating good link text, see A few tips on accessible links.