Skip to main content
UsabilityNews.com - for all the latest in usability and human-computer interaction
BCS Interaction
 
 
The All the Latest section presents all general usability news articles


 
  advanced search
 

All the Latest

Caroline's Corner: Buttons on Forms - where to put them, and what to call them


Source: Caroline Jarrett, 3 September 2008
Submitted by Caroline Jarrett

Caroline Jarrett

Here’s a question that I get asked quite often: “Should we put ‘OK’ button to the left or the right of the ‘Cancel’ button?”

A common variant is to ask the same question with ‘Back’ or ‘Previous’ instead of ‘Cancel’, and to maybe include ‘Next’ in the mixture.

A SIMPLE QUESTION, A COMPLEX ANSWER
I’d love to tell you: put OK on the left. Or on the right. Or something else that’s easy to say and easy to remember. Like so much in forms, the simple answer isn’t really appropriate. And yet, who needs another ‘it depends’? We’ve got far too many of them in usability. The truth, of course, is that ‘it depends’ is the right answer yet again. But we’ll avert our eyes from that and I’ll try to give a few rules here.

RULE 1: LOOK AT OTHER FORMS
The first point is to find out what other forms your users are working with and see where those other programs put their buttons. For example, years ago Jakob Nielsen pointed out that most users spend most of their time on web sites other than yours. Or if you’re creating a program that will be used alongside Microsoft Office applications, then your users are likely to expect your program to follow their conventions. It does get a bit tricky if your users swap regularly between Mac and PC, because unfortunately the two operating systems have conflicting guidelines. Then you’ll have to think carefully about which one you’re going to follow – preferably, after doing some research on what your users do and which applications matter most to them.

RULE 2: PUT BUTTONS AT THE END OF THE CONVERSATION
The big deal with forms is that they ask users one or more questions, after which the user presses a button to say ‘I’m done with my turn in this conversation’. The conversational turn is handed over to the computer to do something. There needs to be a button. It’s usually called ‘OK’, ‘Send’, ‘Submit’ or ‘Next’. The crucial point is that it goes at the end. One common mistake I’ve seen: putting important instructions, or even whole questions, after that final button. A position that’s invisible to users. Don’t do it.

RULE 3: DECIDE WHETHER THE BUTTON IS NECESSARY
A while ago, I wrote a column: “The Piece of HTML created just for me: Reset”. My theme was that ‘Reset’ buttons are rather handy for the forms consultant who regularly hunts for forms on web sites, fills them in and then wants to discard her entries. Sadly, the majority of them are at best useless and at worst deeply annoying for other users. Do you really need other buttons? Do your users want to discard all their work? If you don’t really need a button, then get rid of it.

RULE 4: DECIDE WHETHER THE BUTTON NEEDS TO LOOK LIKE A BUTTON
Sometimes you definitely need two or more possible actions at the end of the form: perhaps, indeed, ‘Send’ and ‘Throw away my work’ or ‘OK and ‘Cancel’. Luke Wroblewski calls the most important action the ‘primary action’ and anything else ‘secondary’. He and Etre did some testing on where to put ‘Submit’ and ‘Cancel’ on web forms, and whether to make ‘Cancel’ into a link or a less prominent button.

Surprisingly, they found that any option that put the two buttons close together worked equally well. The only one that failed was placing ‘Cancel’ right under all the forms fields and ‘Submit’ way off to the right. (An aside: I’d have expected ‘Submit’ right under the forms fields and ‘Cancel’ way off to the right to work just as well as the options where the buttons were all close together, but for some reason that option didn’t get tested).

In terms of time to complete the form, an option with two visually similar buttons worked best. It took users a tiny bit longer to deal with the versions where Cancel was less visually prominent or made into a link. Crucially, though, users preferred those options: “People responded well [to options with a less prominent Cancel] even if these designs slowed them down a little. This suggests that they were more concerned about avoiding losing their data, than they were about submitting it quickly”. My take on this: accuracy and user comfort beats a tiny improvement in processing time in nearly all cases. So I’d reduce the visual impact of secondary actions – and probably make really disastrous actions, like ‘Throw away all my data’, into links on web forms.

There’s a supplement to this rule: make sure the button looks like a button. There’s an online banking application that I have to use regularly and it confuses me every time because the buttons are simple rectangles of orange with text on them – none of the little shading tweaks that make buttons stand out and look like buttons. If you’re feeling short of inspiration, try an image search for ‘web button’ and a vast selection of everything from cool to remarkably ugly will appear. Or, more realistically, just have a look at how your favourite web sites do them.

RULE 5: LABEL THE BUTTON WITH WHAT IT DOES
The last step is to decide what label to put on the button. I’ve so often seen buttons labelled ‘OK’ and ‘Cancel’ when it’s not at all clear what those words mean. Think about those sadly too frequent Cancel boxes: you’ve asked a program to cancel something, and it then gives you a dialogue box with buttons labelled: ‘OK’ and ‘Cancel’. Does ‘Cancel’ here mean, yes, go ahead and cancel or does it mean, no, I don’t want to cancel after all? Note that there’s no rule saying ‘buttons have to have single-word labels’ and definitely no rule saying ‘there has to be an OK button and an Cancel button’.


If you have any comments or suggestions about this article then please contact Caroline at:
Caroline.Jarrett@Effortmark.co.uk
Caroline Jarrett is a usability consultant specialising in forms and improving web content.
© 2008 Caroline Jarrett, all rights reserved.

 


External link to another web site Associated Link:
Effortmark


Other News

All change at the top for System Concepts
Source: System Concepts Ltd, 3 July 2009
 
Leslie Fountain has been promoted to joint Managing Director of leading usability consultancy System Concepts.

Life in UCD immortalised in fiction: you couldn't make it up
Source: UN, 2 July 2009
 
Sarah Herman's fictitious book on life in a user-centred design company has hit the shelves and The Guardian's book pages...

Interfaces Magazine - Issue 79: The Education Issue
Source: Interaction Group, 1 July 2009
 
The latest issue of Interfaces is now available as a free download from the Interaction Website.

Two new Behavioural research Tools from Noldus
Source: UN, 30 June 2009
 
Tool updates make on-site behavioural data collection easier.

Cell Phones that Listen and Learn
Source: MIT Technology Review, 29 June 2009
 
New software tracks a user's behavior by monitoring everyday sounds.

Top Six Don’ts for Usability Testing
Source: FutureNow Inc., 27 June 2009
 
Six tips for creating quality usability tests to ensure useful feedback from testers.

Usability: ‘Lovely software. But I can’t work it’
Source: FT.com, 26 June 2009
 
In a recent survey by Global Graphics, 77 per cent of office workers estimate they lose up to one hour a week because business software is difficult to use.

And what do you do?
Source: Dexo Design, 25 June 2009
 
How do you describe your job role? Here are the results of a recent 'Preferred UX/UI Title' Poll.

Most Doctors cite Usability as critical to Electronic Health Record Adoption
Source: TMCNet, 24 June 2009
 
It's all about 'meaningful use'.

Glossy monitors look good but can hurt
Source: QUT, 23 June 2009
 
A new advisory cites research which suggests high gloss monitors make users sit awkwardly.

 
 

 

home | contribute | subscribe | news feed/RSS | search | contact us | disclaimer

UsabilityNews.com (version 1.41), along with its associated web site and content,
are all strictly © Copyright of the BCS Interaction 2001-2009. All rights reserved.

Joanna Bawa (editor), Dave Clarke (founder, designer and developer). Ian Parry (graphics).