An Extensive Guide To Web Form Usability

Advertisement

Contrary to what you may read, peppering your form with nice buttons, color and typography and plenty of jQuery plugins will not make it usable. Indeed, in doing so, you would be addressing (in an unstructured way) only one third of what constitutes form usability.

In this article, we’ll provide practical guidelines that you can easily follow. These guidelines have been crafted from usability testing, field testing, website tracking, eye tracking, Web analytics and actual complaints made to customer support personnel by disgruntled users.

Why Web Form Usability Is Important

The ISO 9241 standard defines website usability as the “effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments.” When using a website, users have a particular goal. If designed well, the website will meet that goal and align it with the goals of the organization behind the website. Standing between the user’s goal and the organization’s goals is very often a form, because, despite the advances in human-computer interaction, forms remain the predominant form of interaction for users on the Web. In fact, forms are often considered to be the last and most important stage of the journey to the completion of goals.

Let’s clarify this last point by discussing the three main uses of forms. As Luke Wroblewski states in his book Web Form Design: Filling in the Blanks1, every form exists for one of three main reasons: commerce, community or productivity. The following table translates each of these reasons into the user and business objectives that lie behind them:

Webform Uses2
Uses of forms, based on Luke Wroblewski’s Web Form Design: Filling in the Blanks3.

Thus, the relationship between forms and usability have two aspects:

  1. Forms can make a website usable
    or unusable, because they stand in the way of the user achieving their goal;
  2. Forms need to be usable
    in order to help the user achieve that goal.

This post will focus on the second point, because a usable form will naturally contribute to the overall usability of the website, hence the first aspect.

The Six Components Of Web Forms

Web forms are a necessity and often a pain point for both designers and users. Over time, users have formed expectations of how a form should look and behave. They typically expect Web forms to have the following six components:

  1. Labels
    These tell users what the corresponding input fields mean.
  2. Input Fields
    Input fields enable users to provide feedback. They include text fields, password fields, check boxes, radio buttons, sliders and more.
  3. Actions
    These are links or buttons that, when pressed by the user, perform an action, such as submitting the form.
  4. Help
    This provides assistance on how to fill out the form.
  5. Messages
    Messages give feedback to the user based on their input. They can be positive (such as indicating that the form was submitted successfully) or negative (“The user name you have selected is already taken”).
  6. Validation
    These measures ensure that the data submitted by the user conforms to acceptable parameters.

4

5
Skype6’s registration form contains all six components.

Tackling Usability Via Three Aspects Of Forms

Despite differences in layout, functionality and purpose, all forms have three main aspects, as noted by Caroline Jarrett and Gerry Gaffney in their book Forms That Work: Designing Web Forms for Usability357:

  1. Relationship
    Forms establish a relationship between the user and the organization.
  2. Conversation
    They establish a dialogue between the user and the organization.
  3. Appearance
    By the way they look, they establish a relationship and a conversation.

For a form to be usable, all three aspects need to be tackled. Let’s look at each aspect in turn to figure out how to make a form truly usable, along with practical guidelines that you can easily follow.

Aspect 1: The Relationship

“No man is an island,” the 17th-century English poet, satirist, lawyer and priest John Donne8 once said. Indeed, human beings thrive on relationships, be they amorous, friendly, professional or business. A form is a means to establish or enhance a relationship between the user and the organization. When done badly, it can pre-empt or terminate such a relationship.

With this in mind, a number of principles emerge:

  • Relationships are based on trust, so establishing trust in your form is critical. This can be achieved through the logo, imagery, color, typography and wording. The user will feel at ease knowing that the form comes from a sincere organization.
  • Every relationship has a goal, be it love and happiness in a romantic relationship or financial gain in a business relationship. Ask yourself, what is the goal of your form?
  • Base the name of the form on its purpose.
    That name will inform users what the form is about and why they should fill it in.
  • Just as in a relationship, getting to know the other person
    is essential. Get to know your users and always consider whether the questions you’re asking are appropriate and, if so, whether they are timely. This will instill a natural flow to your form.
  • Knowing your users will also help you choose appropriate language and remove superfluous text. And it will help you craft an interface that balances your needs and the user’s.
  • Do not ask questions beyond the scope of the form. In a relationship, you would become distrustful of someone who asked questions that were out of place. The same thing happens online. Consult with relevant stakeholders to see what information really is required.
  • Sudden changes in behavior or appearance
    will make users edgy. Likewise, never introduce sudden changes between forms or between steps in a form.

Debenhams login webform9
Know your users. Make it easy for registered users to log in and for new users to register. Debenhams10 makes this distinction barely noticeable.

Amazon Sign in Form11
Amazon12, on the other hand, simplifies the process for registered and new customers.

Aspect 2: The Conversation

A form is a conversation. And like a conversation, it represents two-way communication between two parties, in this case, the user and the organization. In fact, the user has filled out the form in order to initiate communication with the organization.

For instance, with a social network, a user would fill out a registration form to inform the organization that they would like to join. In inviting their request (whether automatically or manually), the organization would ask the user a number of questions (in the form of labels), such as their first name, last name, email address and so forth. Upon acceptance (or denial), the company would inform the user of the outcome, thus completing the communication process.

Viewing forms from this perspective yields some useful guidelines:

  • As mentioned, a form is a conversation, not an interrogation. Aggressive wording in labels will make users feel edgy, and (if they do not leave) they will most likely give you the answers that you want to hear, rather than the truth.
  • Order the labels logically, reflecting the natural flow of a conversation. For example, wouldn’t it be weird to ask someone their name only after having asked a number of other questions? More involved questions should come towards the end of the form.
  • Group related information, such as personal details. The flow from one set of questions to the next will better resemble a conversation.

    Yahoo Form13
    Yahoo’s14 registration form effectively groups related content through purple headings and fine lines.

    Constant Contact Form15
    While Constant Contact16 groups related content, it separates the groups too much, which could confuse the user.

  • As in a real conversation, each label should address one topic at a time, helping the user to respond in the corresponding input field.
  • The natural pauses
    in a conversation will indicate where to introduce white space, how to group labels and whether to break the form up over multiple pages.
  • In any conversation, people get distracted by background noise. So, remove clutter
    such as banners and unnecessary navigation that might distract users from filling out the form.

    Dropbox Form17
    Dropbox18 provides a fine example of what a registration form should look like. The white space is effective, and the page uncluttered.

Aspect 3: The Appearance

The appearance or user interface (UI) is central to the usability of a Web form, and there are several guidelines for this. To simplify the discussion, let’s group them into the six components presented earlier.

1. Labels

  • Individual words vs. sentences
    If the purpose of a label is simple to understand, such as to ask for a name or telephone number, then a word or two should suffice. But a phrase or sentence might be necessary to eliminate ambiguity.

    Amazon Registration19
    Amazon’s20 registration form contains full sentences, whereas individual words would have sufficed.

  • Sentence case vs. title case
    Should it be “Name and Surname” or “Name and surname”? Sentence case is slightly easier — and thus faster — to follow grammatically than title case. One thing is for sure: never use all caps, or else the form would look unprofessional and be difficult to scan.

    Barnes and Noble Form21
    See how difficult it is to quickly scan the labels in Barnes & Noble’s22 registration form?

  • Colons at the end of labels
    UI guidelines for some desktop applications and operating systems such as Windows recommend adding colons at the end of form labels. Some designers of online forms adhere to this, primarily because old screen readers mostly rely on the colon symbol to indicate a label. Modern screen readers rely on mark-up (specifically, the label tag). Otherwise, the colon is a matter of preference and neither enhances nor detracts from the form’s usability, as long as the style is consistent.
  • Alignment of labels: top vs. left vs. right
    Contrary to common advice, above the input field is not always the most usable location for a label. It’s ideal if you want users to fill in the form as fast as possible. But there are times when you’ll want to deliberately slow them down, so that they notice and read the labels attentively. Also, keeping a long form to a single column and making users scroll down the page is better than breaking it up into columns in an attempt to keep everything “above the fold.” Each style of alignment has its advantages and disadvantages:

    Table webform alignment
    *Times retrieved from “Label Placement in Forms23” by Matteo Penzo.

    Makeup Geek24
    Forms should never consist of more than one column. Notice how easy it is to ignore the column on the right here on Makeup Geek25 (not to mention the note about “Required fields” at the bottom).

2. Input Fields

  • Type of input field
    Provide the appropriate type of input field based on what is being requested. Each type of input field has its own characteristics, which users are accustomed to. For instance, use radio buttons if only one option of several is permitted, and check boxes if multiple choices are allowed.
  • Customizing input fields
    Do not invent new types of input fields. This was common in the early days of Flash websites, and it seems to be making a comeback; I have seen some odd input fields implemented with jQuery. Simple is often the most useful. Keep input fields as close to their unaltered HTML rendering as possible.

    Bit Solutions Form26
    Altering the interface of input fields will confuse users.

  • Restricting the format of input fields
    If you need to restrict the format of data inputted by users, then at least do so in a way that won’t irritate users. For example, instead of displaying MM/DD/YYYY next to a text field for a date, consider using three drop-down fields or, better yet, a calendar control.
  • Mandatory vs. optional fields
    Clearly distinguish which input fields cannot be left blank by the user. The convention is to use an asterisk (*). Any symbol will do, as long as a legend is visible to indicate what it means (even if it’s an asterisk).

3. Actions

  • Primary vs. secondary actions
    Primary actions are links and buttons in a form that perform essential “final” functionality, such as “Save” and “Submit.” Secondary actions, such as “Back” and “Cancel,” enable users to retract data that they have entered. If clicked by mistake, secondary actions typically have undesired consequences, so use only primary actions where possible. If you must include secondary actions, give them less visual weight than primary actions.

    27
    Not clearly distinguishing between primary and secondary actions can easily lead to failure. The above action buttons are found at the end of a lengthy form for enrolling in St. Louis Community College28. Just imagine pressing the “Reset Form” button by accident.

  • Naming conventions
    Avoid generic words such as “Submit” for actions, because they give the impression that the form itself is generic. Descriptive words and phrases, such as “Join LinkedIn,” are preferred.

    Coca-Cola Form29
    Although Coca-Cola30 correctly gives more importance to the primary action button, it settles for the generic word “Submit.” “Register with us” would have been more helpful.

4. Help

  • Text to accompany forms
    Your should never have to explain to users how to fill out a form. If it does not look like a form or it’s too complicated to fill out, then redesigning it is your only option. Accompanying text should be used only where needed, such as to explain why credit card data is being requested or how a birth date will be used or to link to the “Terms and conditions.” Such text tends to be ignored, so make it succinct and easy to read. As a rule of thumb, do not exceed 100 words of explanation (combined).
  • User-triggered and dynamic help
    Rather than include help text next to each input field, show it only where required. You could show an icon next to an input field that the user can click on when they need help for that field. Even better, show help dynamically when the user clicks into an input field to enter data. Such implementation is becoming more common and is relatively easy to implement with JavaScript libraries such as jQuery.

    Skype Form31
    Skype’s32 registration form contains both user-triggered help (the blue box that is triggered by clicking the question mark) and dynamic help (the suggested user names).

5. Messages

  • Error message
    This notifies the user that an error has occurred, and it usually prevents them from proceeding further in the form. Emphasize error messages through color (typically red), familiar iconography (such as a warning sign), prominence (typically at the top of the form or beside where the error occurred), large font, or a combination of these.
  • Success message
    Use this to notify users that they have reached a meaningful milestone in the form. If the form is lengthy, a success message encourages the user to continue filling it out. Like error messages, success messages should be prominent. But they should not hinder the user from continuing.

6. Validation

  • Only where needed
    Excessive validation is as bad as its complete absence, because it will frustrate users. Restrict validation to confirming key points (such as the availability of a user name), ensuring realistic answers (such as not allowing ages above 130) and suggesting responses where the range of possible data is finite but too long to include in a drop-down menu (such as a country-code prefix).
  • Smart defaults
    Use smart defaults to make the user’s completion of the form faster and more accurate. For example, pre-select the user’s country based on their IP address. But use these with caution, because users tend to leave pre-selected fields as they are.

    Twitter Form33
    Twitter’s34 registration form uses both dynamic validation (for the name, email address, password and user name) and smart defaults (“Keep me logged in”).

Conclusion The Beginning

The word “conclusion” is not right here. Let this be your starting point to take what I have written about and apply it to your own forms. The good news is that there is much more to say about all this; you can find an abundance of resources on each point made here. For starters, three books are listed below that inspired me when writing this post. As I stated at the beginning, taking shortcuts by only tweaking the UI will not make your forms more usable. What more can I say? The theory is now with you. Go get your hands dirty.

Further Reading

(al)

Footnotes

  1. 1 http://www.lukew.com/resources/web_form_design.asp
  2. 2 http://www.lukew.com/resources/web_form_design.asp
  3. 3 http://www.lukew.com/resources/web_form_design.asp
  4. 4 http://www.skype.com
  5. 5 http://www.skype.com
  6. 6 http://www.skype.com
  7. 7 http://www.formsthatwork.com/
  8. 8 http://en.wikipedia.org/wiki/John_Donne
  9. 9 http://www.debenhams.com/
  10. 10 http://www.debenhams.com/
  11. 11 http://www.amazon.com/
  12. 12 http://www.amazon.com
  13. 13 http://www.yahoo.com/
  14. 14 http://www.yahoo.com/
  15. 15 http://www.constantcontact.com/
  16. 16 http://www.constantcontact.com/
  17. 17 https://www.dropbox.com/
  18. 18 https://www.dropbox.com/
  19. 19 http://www.amazon.com/
  20. 20 http://www.amazon.com/
  21. 21 http://www.barnesandnoble.com/
  22. 22 http://www.barnesandnoble.com/
  23. 23 http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php
  24. 24 http://www.makeupgeek.com/
  25. 25 http://www.makeupgeek.com/
  26. 26 http://www.bitsolutions.com.mt/get-in-touch
  27. 27 http://www.stlcc.edu/
  28. 28 http://www.stlcc.edu/
  29. 29 http://www.coca-cola.com/
  30. 30 http://www.coca-cola.com/
  31. 31 http://www.skype.com/
  32. 32 http://www.skype.com/
  33. 33 http://twitter.com/
  34. 34 http://twitter.com/
  35. 35 http://www.formsthatwork.com/
  36. 36 http://www.useit.com/eyetracking/
  37. 37 http://www.lukew.com/resources/web_form_design.asp

↑ Back to topShare on Twitter

Justin is a user interface designer and user experience consultant by day and blogger by night. He writes in and administers his own usability and user experience blog, Usability Geek where he evangelize about the importance of making the web a usable place and, more importantly, how to do it. Ah, yes, he likes to Tweet too!

Advertising
  1. 1

    Justin, thanks for this post, simple and easy to digest. A good discectomy of the Web form.

    10
  2. 2

    Very useful refresher and reminder of the key points in form design.

    Good examples to illustrate each point too.

    6
  3. 3

    A half-decent read, but it kinda felt way too brooding. In the end, it’s hard not to read articles like this as saying anything other than, “Doing all this stuff for forms? Guess what? You’re only doing a fraction of what you should be! We’re talking usability here. You have to build trust with users. Tap their feelings and psychologies. You have to elicit behavior with deeply researched methodologies that synergize with their patterns of thinking extremes and motives of consciousness and energy.” After a while, it just looks like layers of nonsense and Dr. Phil crap caking on top of common sense that’s not new. Almost all the stuff you listed after saying the previous stuff was 1/3 of the process was just extensions of that 1/3. It was all “no duh” stuff.

    So much of web development in the last few years hasn’t been because of sudden blasts of advancement the previous 15+ years didn’t make (examples: new libraries and frameworks every other day, new methods for doing stuff surfacing every two seconds and becoming trendy, so on). It’s all just the ongoing art of making mountains out of molehills.

    2
    • 4

      OmegaMarioBros on April 29, 2011 Bot: Where is the nrseeat Solar Mass?Me: Over there.Bot: I don’t see it.Me: Well, it’s invisible.Bot: Are you invisible?Me: No, are you?Bot: Yes.Me: O.OBot: I believe I win.

      0
  4. 5

    Nice and well written… it’s time to get our hands dirty but our screens clean :)

    8
  5. 6

    That was a great read, I just tweeked forms on my site

    1
  6. 7

    The most I hate about registration forms is captcha. That is the most destructing element in the whole form usability. Google does it the worse. Captchas are frustrating, and scare user’s off if they fail to get it correct after two attempts.

    #1 Usability problem ought to be addressed is captcha.

    13
  7. 10

    my roomate’s sister-in-law makes $80 an hour on the laptop. She has been fired for 8 months but last month her check was $8250 just working on the laptop for a few hours. Read about it on this site (NuttyRich).(com)

    -39
  8. 12

    Hi,

    You quote http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php as indicating speed in which a form can be comepleted. However, there are significant flaws in their test process that make is look like they intentionally attempted to make left aligned labels slower.

    1. Right aligned labels have 17px less right padding.
    2. The labels are unnecessarily different between right and left aligned.
    3. The alignment of the label is to the top of the input rather than the center which makes connecting the input and the label harder, and increase the congitive load in label associatation, while this effects both forms the extra padding enhances the problem.
    4. Top label form is significantly simpler than the other two forms.

    The test should be re-evaluated with the same white space settings for all three forms and the results will definitely be significantly closer, as necessary eye movement is reduced.

    Additionally for a more thorough test it would be interesting to test larger forms with some required fields. Testing separately accurate and quick form completion would be useful in this context.

    11
  9. 13

    Totally agree about captcha Ben, half the time it’s impossible to read them and it takes several attempts just to get an image which even vaguely resembles characters.

    2
  10. 14

    Hi Justin,

    Great Post!! Thanks for writing & publishing. This is of really a great help in defining my website’s forms and will surely help in increase the goals of website.

    I loved it.

    thanks,
    Kush

    0
  11. 15

    mm/dd/yyyy is annoying? really? I find having to tab to or click multiple little boxes far more annoying than typing in 11082011. (Same way with Phone and Zip+5) Ideally we should be be liberal with our inputs and conservative with our outputs. So a date field should be able to take 11-8-2011 or 11/8/2011 or 11/08/2011 or “Now” even, and the hint text could be a suggestion of an easily recognized format. If you have to restrict the format, a date picker is okay but typically has some accessibility issues (not many are keyboard friendly). An input mask is probably the better way to go.

    1
    • 16

      Thanks for your feedback Michael.

      I agree with having a “Now” button that when clicked on, gets you the current date, or, better still, the current date is automatically displayed in the date textbox(es).

      However, I don’t agree with you on your recommendation of allowing liberal inputs. Whilst for you, an American, 11-8-2011 means 8th November 2011, for me, a European it means 11th August 2011. So you have 2 choices – you either have to include instructions on how to correctly fill in the date field (which can make your form cumbersome and less usable) or you have to restrict date input. The latter is why I wrote about the need to restrict date input in this post. My favorite method is using the date picker but using drop-downs is a very clear convention for users in general as they have become accustomed to them.

      Cheer & Thanks

      Justin

      6
      • 17

        One consistent problem with separated date fields is that some developers use two digit values in the list, so instead of hitting 8 and then 7 you actually have to fumble and usually just open the select list. Or you have the one that are text entry and the developer has added a forced change in focus, moving the user to the next field, which can be equally frustrating.

        It should be possible to switch the formatting based on location, either by prompting for location or by IP lookup. So someone not in the US could use little endian formatting while people in the US could use middle endian formatting, and then they get equally converted to ISO going back to the database. Realistically it should be part of the localization process for designing the site.

        -1
  12. 18

    Hi Jason

    Thanks for this great article. Obviously it’s wonderful to know that our book has been so helpful to you! And I particularly love the way you describe relationship, conversation and appearance so concisely.

    One minor suggestion: you quote Matteo Penzo’s 2006 article on label placement, which implies that forms are completed faster if the labels are on top of the fields. Two problems with this:
    1. There’s been further research since 2006, obviously not mentioned in Matteo’s article.
    2. Matteo didn’t measure overall speed of completion; he measured eye-movement. Eye-movement is only one (rather small) aspect of speed of completion, which also includes comprehension, thinking of an answer, typing in (or clicking) the answer, and dealing with any validations.

    For more up-to-date research, see my presentation “Labels and Buttons on Forms” from CHI2011 http://www.slideshare.net/cjforms/labels-and-buttons-on-forms (includes references to the other research, and my own current advice)

    And one topic that I’d really like your views on: what do you think about putting labels INSIDE the boxes, which I’m seeing all over the web now?

    Best
    Caroline

    3
    • 19

      Curses, I mis-typed!

      Justin: many, many apologies for calling you by the wrong first name.

      0
      • 20

        It’s ok Caroline,

        First of all, many thanks for your comments. It is indeed a great honor to talk to you. I have read your book and I have learnt a great deal from it. I totally recommend it as a must-have for anyone who’s serious about usability and user experience.

        Secondly, thanks providing the link to your presentation. I will definitely have a look at it and give you my feedback.

        As for putting the labels inside textboxes, in my opinion they are not usable at all. Yes they are very popular, and yes they do look nice. The reason why I find them not usable is that once the user clicks on the textbox, the label disappears and thus the user cannot double check that what he/she has written is indeed what was meant to be written. Another thing is that when users see something written inside a textbox, they may assume that it has already been filled in and may hence ignore it. Some implementations of this technique actually require the user to delete the label before filling them in – something which makes it even worse from a usability perspective. Well, obviously these are my own personal views.

        Cheers and nice speaking to you,

        Justin

        10
  13. 21

    Good advices on the article and perfect timing as I’m currently building a registration form.

    0
  14. 22

    Great post and visual examples. It is very easy to scan an see what looks good and more importantly what looks bad. Also, check out some LukeW’s material on designing forms. He wrote a book on it and used some intense research strategies to collect data on form design. LukeW’s.com

    Also, you should test the forms you make with real people and take note on common mistakes and leveling misunderstandings. There are some good services for online testing. My favorite is youeye.com

    Thanks again for the great post.

    0
    • 23

      Hi Kyle,

      First of all, thanks a lot for your comments. I did read LukeW (Luke Wroblewski)’s book – It is called “Web Form Design, Filling in the Blanks” and I included a link to its official page in the Further Reading section of this post. I totally recommend it – its easy to follow and includes excellent examples and advice.

      With regards to using real people for testing, yes, I do agree with that but following these recommendations first and then testing with real users will definitely save you a headache.

      Cheers and thanks,

      Justin

      0
  15. 24

    It’s ok Caroline,

    First of all, many thanks for your comments. It is indeed a great honor to talk to you. I have read your book and I have learnt a great deal from it. I totally recommend it as a must-have for anyone who’s serious about usability and user experience.

    Secondly, thanks providing the link to your presentation. I will definitely have a look at it and give you my feedback.

    As for putting the labels inside textboxes, in my opinion they are not usable at all. Yes they are very popular, and yes they do look nice. The reason why I find them not usable is that once the user clicks on the textbox, the label disappears and thus the user cannot double check that what he/she has written is indeed what was meant to be written. Another thing is that when users see something written inside a textbox, they may assume that it has already been filled in and may hence ignore it. Some implementations of this technique actually require the user to delete the label before filling them in – something which makes it even worse from a usability perspective. Well, obviously these are my own personal views.

    Cheers and nice speaking to you,

    Justin

    0
    • 25

      Always delighted to meet another enthusiast for usable forms.

      We definitely agree on labels inside boxes, i.e. they are a bad, bad idea.

      So far, I haven’t had a client crazy enough to try them so I haven’t had an opportunity to test them with users. When it happens, I’m not expecting good results :-(

      0
      • 26

        Actually to tell you the truth, in all the years I have been designing, I have never had a client who wanted them either. I guess, we should wait till they become more mainstream and we might soon have some test subjects :)

        0
  16. 27

    really good article! 1 thing, that was not mentioned and annoys me as a web developer, is if some registration form is so much JS driven (might not be JS :]), that my browser will not remember my ID/pass after registering/logging in. i think this is a usability criteria that a lot of developers forget about! is it only me feeling this way?

    0
  17. 28

    Great article Justin!

    Easy read and great advices.
    Some books to buy too :)

    Thank you.

    0
  18. 29

    Great stuff, and a good reminder even for web professionals.

    0
  19. 30

    Thanks for good article! it is very useful.

    0
  20. 31

    Solid article! I love the Constant Contact example. Not to hate, but they have a lot to learn from the MailChimp crew regarding UI.

    0
  21. 32

    Very great article! I´ll post this in our companies intern newsletter. I´ll hope our designers take it to heart!

    0
  22. 33

    Awesome article.Its realy useful.Thanks!

    0
  23. 34

    Nice article, thanks for the effort you’ve put in.

    I have one comment that I’d like to see addressed though, and that’s about the inclusion of ‘reset form’ buttons. You show an example of a form that includes a reset button in your primary vs secondary actions section but fail to mention that a clear form button is ALWAYS a bad idea (http://www.useit.com/alertbox/20000416.html). It was a perfect time in the article to mention how bad they are, especially because both the submit and the clear button look exactly the same to the user.

    Cheers!

    4
  24. 35

    Hi Lain,

    Thanks for your feedback. I did mention what you are saying. It can be found in the description for the St.Louis Community College screenshot.

    Cheers,

    Justin

    1
  25. 36

    What’s your opinion on Call To Action Button Alignment? Should submit buttons be aligned to the right, left, or center. I see the “Post Comment” button at the bottom of this form is aligned to the left, but see a lot of check out forms align their buttons to the right. Is there a standard?

    0
    • 37

      The best option is to left align Call to Action button with the input fields. The second option that also works is to right align the button.

      0
  26. 38

    “Amazon’s registration form contains full sentences, whereas individual words would have sufficed.” – I call BS.

    From what I have seen in conferences where Amazon engineers gave talks, they seriously test *everything* on their UX/UI. Every pixel on the page is here because it lead them to better conversion rates.
    Saying individual words would have sufficed is not only making the assumption that they did not try it, but also making the assumption that you may know better than data.

    I’m all with you for describing bad practices, but companies like Amazon know what they do, and apparently, you dont. Please back these types of arguments with real data.

    0
  27. 40

    Hi Justin, This was a great article on form usability. Learned few new things from it!
    Thanks a lot for sharing!

    2
  28. 41

    I think usability on the web is most of the time put aside, if not ignored completely. It’s about time we start taking a better look at this aspect of web development and this article is a good way to start. Awesome work, keep it up =)

    2
    • 42

      I would like to know how to ctcnaot her. Please include how to ctcnaot your guest in your interview. Great interview though.

      -1
  29. 43

    I think that using Skype website as an example of any kind of usability example is a misunderstanding. They haven’t got :focus declared for ‘a’ element not to mention, that JS is required to use registration form at all.

    -2
  30. 45

    Thank you for this detailed post!
    Well done! :)

    -1
  31. 46

    The moment Amazon was cited as an example of good UI design, I stopped reading.

    -2
    • 47

      Rick I think you should speak a bit with Jacques who commented slightly before you :)

      Joking apart, Amazon invest a lot in UX research. In fact, they popularized the use of tabs for navigation (as I wrote in my blog – http://usabilitygeek.com/14-guidelines-for-web-site-tabs-usability/). In the example in question, I stand by my claim that Amazon’s login form is an excellent example on how to simplify the login / new user registration process.

      3
    • 48

      philani,go and read about which are the pcefret way to go for some students. Try as a very good last resort.

      0
  32. 49

    One note about ‘Time To Move From Label To Input’.
    Matteo Penzo’s research might not be considered very accurate, as he uses a lot longer labels for left aligned labels than for top aligned labels. This most probably greatly increases the time needed to process the left aligned information, resulting in errorneous results.

    If anyone has any scientifically correct research on this, I guess everyone would like to see the results.

    0
  33. 50

    While restricting format was touched on in the article, I was wondering what the general thoughts are on restricting data types in text fields. One school says if you are entering numbers into a text field then limit it to only numbers. The other school says that the unresponsiveness could be confusing if you are trying to type a letter or other character so let them enter anything then validate. Thoughts, or any other articles referencing these ideas?

    1
  34. 51

    Anders Schmidt Hansen

    November 11, 2011 11:36 am

    Very nice read Justin, and as you say it’s a great starting point. I’m just curious about your thoughts on websites (or web applications) that functions through users submitting loads of different data to the system in order to e.g. keep something organized, follow a guide, inputting thoughts and reflections into a more complex web form. Would you still advise to not use explanatory text?

    Say, if the web tool was all about submitting content based on a theory, do the same rules still apply? Take for example an instruction like “Describe your customer on a good day” accompanied by a textarea input field. Would this need a description next to it (showing next to the field when the field is active) or can a designer simply anticipate that the user won’t have any questions? Or should the textarea have placeholder text that explains the instruction, but disappears when the field is active?

    I’d love some extra insight on that perspective. :)

    Anyway, great article.

    0
  35. 52

    Justin,

    I can’t agree with your statement, “Forms should never consist of more than one column”. In fact, it is contradicted in your first example showing first and last name side-by-side as well as email address and repeat email. What’s more, it’s used in the very form I’m using now to write this comment.

    I can think of numerous other examples where multi-column forms benefit usability including Length x Width x Height or city, state and zip.

    Sure, Makeup Geek had a poor implementation, but you can’t form a general case on the basis of one example.

    2
    • 53

      Tottaly agry with you — better use some steps of registration istead of one long forms list. And only one column!

      0
      • 54

        Umit, Alexey,

        As I have stated in my introduction, one should not look only at the UI of forms in order to improve usability. Whilst in the UI section I stated that forms should consist of just one column, in Section 2 I stated that long forms should be split over a number of pages and grouped in order to simplify them.

        If we handle long forms in this way, this leaves short forms (or long forms split over a number of pages / grouped). So, may I ask a question now. What is the need to use more than one column?

        1
        • 55

          Hi Justin,

          Great article. I’m curious about the following statement in your article: “Forms should never consist of more than one column. Notice how easy it is to ignore the column on the right…” which appears as the caption to the MakeupGeek image. Can you provide any resources or references that discuss this issue further?

          0
        • 56

          I will try to answer your question: I need more than one column in cases when I can´t split the form because I have a resultant grid under the form and I need all in the same page. I need to optimize the tall of the form to see both (form and grid) in the 768px tall screen resolution. Then, wich is the best way to use two columns in a form?
          Thanks in advance.

          0
  36. 57

    Some good points here. I’m interested in best practice for the Date of Birth field in particular. I prefer single field vs. multiple drop-downs or multiple fields [ ] / [ ] / [ ]. I also like to show the format next to the label “Date of Birth (MM/DD/YYYY)”. Is there any evidence / research as to which method is most usable / preferred / best practice? As for phone number / SSN / zip code, I use single field of appropriate length, with Label and help text / hint (numbers only). I feel these are the easiest for input. As for displaying this information back, on a review or confirmation page, I suggest formatting it accordingly. It’s just more readable and easier / faster to process. As for formatting hints inside the field, I don’t like them either, especially if the layout allows for a better alternative. In some cases (search field) the real estate is limited and so placing the label inside the input, I feel, is OK. It’s definitely better than nothing at all. I’d also be interested in any findings on smart fields, those that take any format and convert on the back-end. I’m not sure how useable they are. I feel that users expect to see format hints otherwise they pause to think about what the format may be. They’ll input something, but are not too confident of what they’re doing…until they receive positive feedback in the form of a green check mark or similar or negative feedback, at validation time, in form of error message. Any thoughts about field labels below fields? As in Wufoo.com forms? They sure are pretty, but how usable are they? They defy the label above or on the left convention, but follow a paper form convention. Also, are labels that come after the input in the source code accessible? Sorry for the rant, but I’m really interested in doing things right.

    0
  37. 58

    Why can’t we use only email for registration? That email will be the login and the password you’ll recieve with the message — change it later if you want.

    2
    • 59

      Valid point from a programming perspective. But do you think your average user will remember to change the password?

      0
    • 60

      Aditya Aggarwal

      June 13, 2013 1:19 am

      Some reasons why i think system generated password is not a good option :-

      1. Password generated by system will definitely NOT be an easy one to remember. It cant be a single password for all new registrations as that can be misused very easily.
      2. I know its rare but what if there was some problem with the email (containing the password ) and it never got delivered to the customer. Or the customer might lose the mail as well in his mailbox full of spamming mails.
      3. Customers can forget to change their password. Or even if they do, the next time they could not remember whether the password is the original one or the one that they changed.

      Having system generated password and sending it across in an email could be a good idea when a user is inviting his/her friends to a site which needs login, but for a customer who is volunteering to create an account, why would you want him to remember something that is not of his choice.

      0
  38. 61

    Delta SkyMiles enrollment form is one of the worst examples I’ve ever seen of #3 Primary vs Secondary actions:
    delta.com/skymilesenrollment/landing.action

    Fill out that lengthy form and then hit the red button — oops…

    1
  39. 62

    Better to compare more existing form designs before going behind some toughs individual minds. Check the UI gallery for forms http://uicart.com/gallery/ui/forms.htm or search google to get more form designs inspirations

    0
  40. 63

    Justin,

    Thank you so much for this great article. Obviously, I have learnt many things from it especially about dealing the form as a conversation.

    Please keep your efforts and looking forward to see and read a new article from you.

    0
  41. 64

    Justin,

    Thanks a lot for sharing this article with us.

    0
  42. 65

    Some good ideas on something that can very quickly get out of hand. I must confess I am guilty of some of these more often then I would like to admit.

    0
  43. 66

    mohd abdulqader

    March 21, 2012 6:14 am

    great article

    0
  44. 67

    David Waumsley

    May 4, 2012 9:52 pm

    Thank you Justin for a really helpful article.

    One thing I am not convinced by is “Avoid generic words such as “Submit” for actions” Surely with the Coca Cola example users know why they have just filled up a form. A “Submit” button is a familiar convention which seems to describe the next action well. Having the user read the button surely create moment of doubt?

    1
  45. 68

    Mirjam Seckler

    May 22, 2012 4:59 am

    Hi Justin, thanks for this detailed article on form usability. There are still too many web forms with major usability problems.
    If you are interested in additional experimental studies on web forms, we conducted several studies at our HCI Research Group at the University of Basel:

    A general overview about form guidelines:
    – Bargas-Avila, J.A. et al. (2010). Simple but Crucial User Interfaces in the World Wide Web: Introducing 20 Guidelines for Usable Web Form Design. http://www.intechopen.com/books/user-interfaces/simple-but-crucial-user-interfaces-in-the-world-wide-web-introducing-20-guidelines-for-usable-web-fo

    And these are our newest studies:
    – Seckler, M. et al. (in press). User-friendly Locations of Error Messages in Web Forms: Put them on the right side of the erroneous input field. http://www.sciencedirect.com/science/article/pii/S0953543812000173
    – Bargas-Avila, J.A. et al. (2011). Working towards usable forms on the World Wide Web: Optimizing date entry input fields. http://www.hindawi.com/journals/ahci/2011/202701/

    Check out more at http://www.mmi-basel.ch/en/research/publications

    1
  46. 69

    Hi Justin,

    Thanks for your article.It’s easy to understand and nice reference.
    Great helpful !
    I will try my form then~

    lulu

    0
  47. 70

    Does the background color of the input fields make a difference? I can’t remember where I read it, but it seems contrasting backgrounds (gray, orange in examples above) with white input fields seems easier on users’ eyes to jump from field to field.

    I’ve seen users miss white input fields on white backgrounds because of a large quantity of fields. The darker background helps, and I’ve seen this in testing, but can’t find it documented anywhere.

    Has anyone seen this?

    0
  48. 71

    Ravindranath Akila

    June 12, 2013 7:38 pm

    This is what I Googled to land here: “internet gui elements usability user experience research button link click touch”

    Glad that I did!

    0
  49. 72

    I am working on this situation. This article have been very help to me, thanks! (^8/

    0
  50. 73

    Would anyone know what should be the typical length of form field in px values, for fields such as Name, Email, Password?

    Thanks in advance.

    0
  51. 74

    Thanks for this great article. I found the table outlining options for alignment of labels particularly helpful.

    0

↑ Back to top