Have you ever wondered where to place your buttons at the end of your form? How you design your button is one thing, but where you place it can also affect form submissions.
There are three types of forms you need to consider: multi-page, multi-section, and single page form. The type of form you’re using will determine where you should place your submit button.
Multi-Page Forms
On multi-page forms, you’ll have more than one button. You’ll have a ‘back’ button that takes users to their previous page. And you’ll also have a ‘continue’ button that takes users to the next page.
Because these buttons behave like pagination, they should follow pagination conventions. Continue button goes on the right while the Back button goes on the left. This maps to the direction users want to go when they paginate.
Multi-Section Forms
Multi-section forms are long and consist of many fields grouped together. Aligning your button to the left can make users think that the action only applies to fields in that section. Aligning your button to the right gives users the impression that the button is an action that applies to the entire form.
Single Page Form
The fields on single page forms are almost always left aligned. Aligning your button to the left on single page forms allow users to find and click the button easier.
Users will scan the fields from left to right going down the form. A left aligned button is directly in their visual path when they get to the bottom of the form. It flows with the user’s scanning pattern so they can click it quickly without having to look for it.
Final Thoughts
Where you place your form buttons is important to consider. The submit button is responsible for receiving user information. If it’s not placed in a location where users expect, you could lose out on form submissions. Know what type of form you’re using and place your buttons where users expect it.
Book
Affiliate
I wanted to read this article in portuguese, clicked the translate to portuguese and received a blank page with the following text:
“Please return to this page in some minutes.”
In an usability site…
Do what I say, don’t do what I do…
Google Translate isn’t working right now because there are too many queries coming from this site.
Very interesting read, this is definitely something to take on board.
I wonder if the right-aligned button for multiple-page forms is to do with it being akin to ‘turning a page’? With a book (or even a real life on-paper multi-page form) you’d be reaching for the bottom right corner to move onto the next step.
The button “back” with another color or the button continue with the link color should be a better efficient.
I disagree with your assessment of the left-aligned button for single page forms. I think the Submit button’s functionality / reason for being is sufficiently different from the various text boxes, lablels, etc that it really needs to be separated from those other elements.
Having the submit right-aligned gives the impression that it is different from the other elements and the extra distance means extra time for any mistakes to register in the user’s mind.
It’s good that you are trying to be logical, but I think you are failing to see the unique context of single page forms. The context is different than multi-section forms, which means the way you think about it needs to be different.
Users don’t have issues when the button is aligned left on single page forms because these forms are often short making the button’s association with the form fields strong and clear. In other words, it’s easy for users to see and understand that the buttons and the fields work together as one piece.
With multi-section forms there are often more elements, more levels and the forms are longer, and because of that, you do need to separate the button to make it clear that it’s function does not correspond to any particular section or form element, but rather the entire form itself.
if you want to be so logical, don’t put a back button on section 1
@Russell Yes! Turning a page is a strong mental model everyone is familiar with.
Interesting thoughts. I’ve had these discussions at my last two gigs, but wasn’t able to put it as succinct. The point about the submit button acting on multiple sections is especially strong. I would go further and say that a right-aligned button actually cues the user that an action will be performed upon the whole page itself, including all the sections, due to the user’s page-turning mental model.
Now I’d like to see some testing that backs up these theories. Anyone know of any?
-isaacw
While I see your point about multiple buttons (2 in this case) on multi-page forms. The other option is as a design decision you can make “Continue” the more important and highlight it someway that sets it apart. That should reduce accidentally clicking the unintended button. The other case of being related to form sections can be handled by having spacing that is greater than that between sections thereby disassociating it from any particular section.
I’m deeply sceptical about your advice here, and I would like to see your evidence from testing real forms with users.
Based on my years of observation of users interacting with forms, my advice is to align the main action button (Submit, Next, etc) with the left-hand edge of the input fields, as shown in your “Single page – short” example.
Any other action buttons then get placed so that they make sense relative to the main action button – but are appropriately diminished in visiblity (or even turned into links) so that the user doesn’t click them by mistake.
Your “multiple selection form – long” example, where you put a single main action button on the right, isn’t a disaster: if your users can’t find the button where it ought to be, then the next place they’ll look is the bottom right-hand corner of the form.
The problem arises when you have other buttons to place, as in your first example “mutliple page form – paginated”. In that example, you’ve put the ‘Back’ button really close to the ‘Submit’ button and with exactly the same visual impact. A proportion of users will click the button without reading it, and your arrangement will mess them up. Don’t do this.
Read my article: http://www.usabilitynews.com/news/article4984.asp which also has a link to Luke W’s useful article on the same topic.
best
Caroline
Caroline, thanks for sharing your thoughts. The problem you’re talking about isn’t that the Back button is next to the Continue button. The problem is that the Continue button doesn’t distinguish itself as the primary action. I agree with you and a lot of others who have mentioned this. To be clear to everyone who brought this up, the Continue button needs to distinguish itself more prominently over the Back button, so that users won’t make the mistake of accidentally clicking the back button. However, the Back and Continue button still should always be together.
I didn’t talk about this matter in the article because the article focused specifically on button placement, not button priority.
Hi Anthony, thanks for the article. On what base (research, usability-test, study) is it based?
LukeW has articles about this as well and his suggestions are based on user research in usability-tests…
If its “just” your own opinion its stil a good read 🙂
Regards
Tobias
He has some interesting data, but I don’t agree with all his conclusions. Many people have the misconception that just because research is done on something, everything that’s said must be true and valid. That couldn’t be farther from the truth. Many people misinterpret research data all the time. However, nobody ever points it out because they’re afraid to challenge ideas held by research. Research is good for getting data and information. However, it will still always come down to the individual to interpret the data correctly. That means you will still have to think independently, and use your logic and intuition to see the bigger picture and finer details. You have to stay objective mentally because truth doesn’t come on a silver platter. Research and testing gives you data and information, not truth. Truth has and will always be left in the hands of the individual.
Regarding those who are concerned with research validity – see Fitz Law. So far, it would seem that the things that Anthony suggests are in compliance with Fitz.
Also, I would like to point out that there is just as much art in software development as there is science. Both art and science give you the flexibility to assume. While science requires reconciliation at some point of your assumptions against reality, both science and research appear to start with the assumptions.
Zeros of the zeta function – assumption until proven.
Relativity – assumption until proven.
((n*n)+n)/2 – assumption until proven.
So, what I’m saying in essence is – leave the kid alone. If you like the ideas, use them. If you don’t like the ideas, don’t.
In fact, I’m getting quite put out by the number of people out there that feel like they have some sort of claim or ownership to the world of software development. Some of us have been writing code longer than many of you have been alive!
You don’t own anything, so give the kid a break and let him express his ideas. (I made some assumptions in this reply that we may only be able to prove a posteriori – such as the age of anthony and maybe some of the others involved in the thread.)
Anthony the reason we perform research is to avoid assumptions. The foundation of UCD is centered around the (um..) user. As a practitioner, we design as much as we can towards validated behavior – if budgets are restrictive then we absolutely need to seek out relative data that can help inform a design recommendation – there’s a lot of books on the topic. I’m kind of shocked about your take on research and, again, how you generalize. While it’s clear that you understand common perceptions of interface design – you need to realize that you have power to influence new designers by what you write. Dissing the findings from a properly conducted test (thats important) is irresponsible – especially when you can’t back it up with anything else but Jedi mind tricks like “truth doesn’t cone on a silver platter” or “truth is… Left in the hands of the individual” or “use your logic and intuition to see the bigger picture”.
Cmon – everything we do is based on context. Luke’s research may not fit my current project but something down the road may. Please stop already.
As much I’d like to believe, using your brain to think objectively is not a Jedi mind trick. 🙂 It’s clear that you believe that it’s humanly impossible for one to reach objective ideas without research. This is 100% false and the history of science proves it.
Einstein reached his scientific conclusions through thought experiments involving his logic, intuition, experience and knowledge. He was a great thinker. He only did research to verify his conclusions after the fact, never before. Newton was the same way. Although, he was wrong about some things, thinking objectively doesn’t mean you are always right. But research is the same way. Research isn’t always right either. In fact, most published research is almost always false: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1182327/
So, your claim that one cannot reach objective ideas without research is absolutely absurd and I will not tolerate it at UX Movement. If you think I made a mistake with any of my ideas and want to prove me wrong with your own research that you have done, I’d be happy to look at it. Otherwise, this discussion is over.
Bruce, research is not the absolute you present it as. It’s interpretation – any researcher will tell you that. Further, you should be using *trends* and the heuristics that evolve from research, not individual research findings – the former increases the likelihood of getting it right, the latter increases the likelihood of getting it wrong.
What do you do if you have the 3 forms in the same application? Because we want to be consistent across the forms.
Thanks.
Just came across this article and comment thread. I had the same question regarding consistency across different types of forms of the same site.
Hi I had a similar problem. I have to design multiple pages with different forms. Sometimes it’s a page with a simple form (then a button under the form seems the correct way to go), then I have a multiple section form with buttons that lie next to certain fields (functional buttons that influence only that field) and I need general buttons for the completion of the whole form (makes sense to put the general buttons under and to the right), and then I have forms that are part of a flow (buttons on left and right that navigate through the flow). The problem this creates is inconsistency. Where does a user or even a person who is building the page know where to put the buttons? I need to create guidelines and am having a lot of trouble deciding on what to go with for the sake of consistency. Should I just create different looking buttons depending on what they do? Help! 🙂
Congratulations for the article!
I have a situation I hope you will help me to solve:
It’s a customization process of a avatar that consist of filling a multiple page form. In each page the user can go forward (Next button) or back (Back button). At this point, I think the best option is to put the buttons in the lower right corner. The Next button on the right and the Back button on the left. http://screencast.com/t/wxaMaOskO
The challenge is where should I place the Save button. If the Save button was only in the final step, it seems clear that it should be instead of the Next button. The problem is that the user can save (to complete the process) in each of the 5 steps! In this case, where should I place the save button?
We tried to place the button under the image, but we realized that many users do not see the button, so that they do not know the final step further.
What do you think? Can someone help me make a decision?
Interesting problem. To solve it, you’ll want to first look at what kind of form we’re dealing with. Then you’ll want to distinguish which buttons are primary and secondary.
We’re dealing with a multi-page form here. There are three buttons – Previous, Next and Save. The primary buttons for successful task completion are Next and Save. Thus, the secondary button is Previous.
Now we want to design and arrange these buttons according to how users can best use them to successfully complete their task. The buttons users will need the most to complete their task are Next and Save. We want to group these buttons together so that they’re both easy to reach and easy to see. Thus, the primary buttons go on the right. The Save button is the one that should be closest to the right corner because it’s the final action that affects the form globally. We want put the secondary button away from the primary buttons because it’s not as important and won’t be used as frequently. Thus, the Previous button goes on the left.
Finally, we want to design these buttons so that users can read and recognize them better. To do this, you’ll want to put arrows on the Next and Previous buttons to show pagination. And you’ll want to put a color on the Save button to show that it’s the final and most important action.
Thanks for the reply!
I agree with you. I think it will be something like this: http://screencast.com/t/qlFAWydc9i
I will keep you informed.
Thanks again.
I think there should be more space between the previous and next button. This shows the primary buttons’ relationship better. When you space them all equally it looks like they all have equal weight, which is not the case. Previous is secondary.
Great! thanks: http://screencast.com/t/EqeXugNBLwv
I’d go with the left one. Combining links and buttons can throw users off. Plus, it’s pagination so they shouldn’t vary in appearance that much.
I totally agree. I think combining links and buttons could be good idea if it is a simple form where the user normaly clicks “Save” and almost never “Cancel”.
Thank you very much for your advisory.
I personally would prefer never to see a button anywhere but inline with the forms controls.
I’m partially sighted and have a low peripheral vision (I believe I’ve lost about 90% of my field of vision). When I’m in front of a screen, I basically see what I am looking at clearly but as for the items all around it, all bets are off. Due to this I can often miss buttons. I will be filling out a form, scrolling down with my eyes as I go. When I get to the bottom of the form, I’ll automatically look under the form fields. If the buttons aren’t there, I have to go searching for them and for someone with poor eyesight, this can be tricky.
The forms you posted did have one huge help though – the line at the bottom of the form. When the buttons weren’t where I expected them, I did the most logical thing and followed the line with my eyes & voila – buttons.
For me that’s the clincher. Where you place you buttons is up to you but don’t assume people will expect them in the same place as you. A simple visual indicator (like a line in this case) from the form fields to the buttons can be a huge help for someone with low vision like me.
Yes, what Lee said. We recently did some usability testing that included a number of disabled participants, on a large corporate customer facing site. Right aligned buttons caused huge problems for people with mild-moderate vision impairment, in one instance preventing the customer from being able to complete the form at all.
1. Differing designer opinions on which way is theoretically marginally better
2. Some research suggesting that together is marginally better, and suggesting that together and left aligned might be very marginally better again
3. Anecdotal evidence of serious problems for people with vision impairments (including screen magnifier users), sometimes resulting in complete exclusion/abandonment
Point 3 makes it completely cut and dry, case closed. The law varies from country to country, but in the UK at least, under the Equalities Act (which applies to all websites) it is illegal to put people with disabilities at a disadvantage when there’s a reasonable alternative… and difference of opinions over marginal usability differences do not prevent it from being a reasonable alternative.