h1

User Assistance in Web Forms

April 8, 2009

Luke Wroblewski spoke on this topic on the second day of the WritersUA 2009 Conference in Seattle. Luke is always an entertaining speaker, with examples that lead to some great ‘ah ha!’ moments. Here are my notes from his session:

  • (Most) Forms suck.
  • The primary goal for every form is completion. Show progress towards completion in long forms.
  • Eye tracking studies show that left-aligned forms are simplest to scan, and have a clear visual path to completion — straight down the page, not zig-zagging from side to side.
  • Top-aligned labels are faster to complete as users process the label and the accompanying field in one pass. Ideal where data being collected is familiar (e.g. name, address).
  • Use left-aligned labels were data is unfamiliar as this slows down the user, allowing them time to think.
  • Use right-aligned labels where vertical screen space is a constraint; otherwise, don’t use at all.
  • Labels within input fields: Disappear as user starts to enter data; make sure the UA goes away if user doesn’t input anything; clearly distinguish UA from data (e.g. —your selection—)
  • Required fields: If all are required, don’t use an indicator for each (confusing); if most are required, only use an indicator (e.g. ‘(optional)’) for those that aren’t required; if some are required, use an indicator such as an asterisk; associate indicators with labels, NOT input fields.
  • Only use Help and Tips in these situations: when asking for unfamiliar data; if users might want to know why data is being requested; where there are recommended data input formats. Do not overuse as they can be overwhelming.
  • Validation: Provide direct feedback as data is entered. A study Luke was involved in showed that a form is 87% more effective with inline validation. Inline validation is especially useful for fields with potentially high error rates.
  • Commands: Not all form actions are equal. Reset, Cancel, Go Back rarely need to be used, so can be omitted or relegated to lesser importance using faded color, smaller size, etc. Primary actions directly responsible for form submission include Submit, Continue, Next, Save etc. Make these larger or a brighter color to emphasize their importance, and align such that they are part of the clear path to completion.
  • Actions in progress: Provide feedback where an action may take some time to process (e.g. form submission, data calculation, uploads); disable ‘Submit’ button while action is occurring to avoid duplicate submissions; consider streamlining legal requirements (e.g. instead of a check box to confirm that the user has read the terms and conditions, make it a statement and associate it with the submission button — “By clicking Register, I agree that I have read the Terms and Conditions” or similar.
  • Errors: Clearly indicate an error has occurred by placing the error in a conspicuous place with a conspicuous color (this ‘doubles’ the visual language for an error); provide information on how to correct the error.

My other conference links:

[Links last checked April 2009]

5 comments

  1. […] User Assistance in Web Forms: Luke Wroblewski (https://cybertext.wordpress.com/2009/04/08/user-assistance-in-web-forms/) […]


  2. […] how can this process be improved? Luke Wroblewski, in his session at the 2009 WritersUA Conference, gave many guidelines, of which two in particular are relevant to this initial […]


  3. […] User Assistance in Web Forms: Luke Wroblewski (https://cybertext.wordpress.com/2009/04/08/user-assistance-in-web-forms/) […]


  4. […] User Assistance in Web Forms: Luke Wroblewski (https://cybertext.wordpress.com/2009/04/08/user-assistance-in-web-forms/) […]



Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.