Is there any usability study about layout of form buttons?

I have a simple registration process. The user is guided with several forms through the process. Each form has a <next> and a <back> button. Some steps have instead of a <next> a <choice A>, <choice B> and <back> button.

I am aware that the form's button is absolutely needless, as every UA has a native one. But unfortunately web authors removed the user's awareness of that function. So as my last step says "check your data and if necessary edit it". I need to offer users who forgot about the UA's back button an intuitive possibility to navigate back.

Now I'm wondering how to layout out those buttons for best usability. I'm wondering if anybody did a study on this problem already and is willing to point me to that result.

up vote 8 down vote accepted

Luke Wroblewski (author of Web Form Design: Filling in the Blanks) has some great studies on form usability available, based on a lot of sources. "Form Actions" and "Path to Completion" are probably the most relevant parts for the question that you're asking, but hopefully you'll find the other areas interesting as well.

The material from Luke is based upon a lot of different sources:

  • Usability Testing (Errors, issues, assists, completion rates, time spent per task, satisfaction scores).
  • Field Testing (Sources used, environment, context).
  • Customer Support (Top problems, number of incidents).
  • Web Conventions Survey (Common solutions, unique approaches).
  • Site Tracking (Completion rates, entry points, exit points, elements utilized, data entered).
  • Eye Tracking (Number of eye fixations, length of fixations, heat maps, scan paths).

Best Practices: Label Alignment

  • For reduced completion times & familiar data input: use top aligned labels.
  • When vertical screen space is a constraint: use right aligned labels.
  • For unfamiliar, or advanced data entry: use left aligned labels.

Best Practices: Required and Optional Fields

  • Try to avoid optional fields.
  • If most fields are required: indicate optional fields.
  • If most fields are optional: indicate required fields.
  • Text is best, but * often works for required fields.
  • Associate indicators with labels.

Best Practices: Field Lengths

  • When possible, use field length as an affordance.
  • Otherwise consider a consistent length that provides enough room for inputs.

Best Practices: Content Grouping

  • Use relevant content groupings to organize forms.
  • Use the minimum amount of visual elements necessary to communicate useful relationships.

Best Practices: Form Actions

  • Not all form actions are equal (Reset, Cancel, & Go Back are secondary actions: rarely need to be used (if at all), Save, Continue, & Submit are primary actions: directly responsible for form completion).
  • The visual presentation of actions should match their importance.
  • Avoid secondary actions if possible. Otherwise, ensure a clear visual distinction between primary & secondary actions.
  • Align primary actions with input fields for a clear path to completion.

Best Practices: Help & Tips

  • Help & Tips are useful when asking for unfamiliar data, where users may question why data is being requested, where there are recommended ways of providing data or if certain data requests are optional.
  • However, Help & Tips can quickly overwhelm a form if overused. In these cases, you may want to consider a dynamic solution (Automatic inline exposure, user activated inline exposure, user activated section exposure).

Best Practices: Path to Form Completion

  • Remove all unnecessary data requests.
  • Enable smart defaults.
  • Employ flexible data entry.
  • Illuminate a clear path to completion.
  • For long forms, show progress & save.
  • Remember to account for tabbing behavior.
  • Use the tabindex attribute to control tabbing order.
  • Consider tabbing expectations when laying out form (e.g. multi-column forms vs single-column form behavior).
  • Map progressive disclosure to prioritized user needs (e.g. don't show all paths to c ompletion at once if not all are applicable for certain options chosen).
  • Maintain a consistent approach.

Best Practices: User Feedback

  • Use inline validation for inputs that have potentially high error rates.
  • Use input fields that reflect the information asked for (e.g. use a checkbox for Yes/No response, not a free-form text field).
  • Communicate field limits (e.g. characters allowed, field length).
  • Clearly communicate an error has occurred: top placement, visual contrast.
  • Provide actionable remedies to correct errors.
  • Associate responsible fields with primary error message.
  • “Double” the visual language where errors have occurred.
  • Provide indication of tasks in progress.
  • Disable “submit” button after user clicks it to avoid duplicate submissions.

Best Practices: Data Submission

  • Clearly communicate a data submission has been successful.
  • Provide feedback in context of data submitted.
  • Thanks for that great answer. Indeed I find the other points very informative. – Markus Malkusch Oct 28 '13 at 13:37

Depending on how much information you have to display on the final review screen, it would be much easier on the user to allow them to edit their data inline on the final review screen instead of them having to travel back through the registration process to edit data.

If you feel that it's necessary to have the user navigate back through the registration screens in order to edit their information, you might want to utilize breadcrumb navigation. That way you would allow the user to jump back to a previous session in one click instead of having to repeatedly press back buttons.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.