FORMS Best Practices

1. FORMSBest Practices

2. Best practices are guidelines. Understanding them will give you a good place to start. • They are not hard and fast rules. • Always make decisions that are informed by user knowledge, testing, and feedback.

3. Forms often stand between a user’s goals and a business’ goals. • Forms are the predominant method of online interaction between users and a business. • In his book, Web Form Design: Filling in the Blanks, Luke Wroblewski states that every form exists for one of three reasons: • Commerce • Community • Productivity

4. Uses of Forms • Adapted from Luke Wroblewski’sWeb Form Design: Filling in the Blanks

5. The Three Characteristics of Forms • Despite differences in what they do and how they work, all forms have 3 primary characteristics: • They establish a relationship between the user and the business. • They establish a conversationbetween the user and the business. • They have an appearance that helps facilitate the relationship and conversation. • Adapted from Caroline Jarrett’s and Gerry Gaffney’s Forms That Work: Designing Web Forms for Usability

6. Relationships & Conversations • Relationships are built on trust • Questions and language are appropriate to the stage in the relationship • Conversations follow a logical progression and address one topic at a time • Conversations can be derailed by background noise

7. How do you decide what to ask? • You need to know how the information you’re asking will be used. A question protocol helps you decide which fields are required, and lists: • Every question you ask • Who needs/uses the information gathered in each question • What they use the information for • Whether the answer is required or optional • If an answer is required, what happens if a user enters false data to get through the form • Whether a question is open or closed • If open, how much text is allowed • If closed, what answer options should be provided • Sequencing/conditional information • Whether an answer can be prepopulated from existing data • Whether an answer can be assumed (e.g., based on a cookie or location data), and then the user can edit or confirm it

8. How do you decide what to ask? • Why would you do this? Each question has costs associated with it: • If there are too many questions, you’ll lose conversions • If there are questions that users consider irrelevant or inappropriate, you’ll lose conversions and/or get made-up data • If the form is more work than users expect, you will lose satisfaction • There is a technical cost associated with processing and storing each piece of data • A question protocol lets you determine is that question really necessary?

9. How do you decide what to ask? • Skype asks for a lot of optional personal information during the sign up process. Much of this information could easily be collected once the user has created an account.

10. What matters: what you ask and why. • Users rarely abandon forms because of: • Label placement • Field length • What symbol you choose to denote required fields • Where your button is (unless they can’t find it) • Users often abandon forms or provide false data because of: • Questions they don’t understand • Questions they can’t answer • Questions that they perceive as inappropriate or intrusive • Questions or validations that don’t allow them to use their preferred or correct answer

11. Appearance: The Six Components of Web Forms • Users have developed expectations for forms. They typically expect forms to have these components: • Layout • Labels • Input fields and controls • Actions • Help • Errors

12. Layout: Columns • Present your forms in one column. There is no way a user can be confused about where to go next if everything is in one column. Oh, and they’ll work better on mobile devices, too. • 1

13. Layout: Grouping • Think of the way you would ask questions in a face-to-face conversation. It would be weird to ask someone’s name halfway through. • 1 • The natural pauses in conversation will indicate how to group multiple fields, where to introduce white space, and whether to break the form up over multiple pages. • 2

14. Layout: Input methods • Many users will use the “tab” key to advance through the form – use the HTML attribute “tabindex” to ensure that happens in the right order. This also affects the “Next” and “Previous” buttons on mobile devices. • 1 • Don’t force the user to switch back and forth between keyboard and mouse. Group fields that require one or the other. • 2

15. Layout: Progress bars vs. summary menus • For multi-step forms, always show the user’s progress. • 1 • Forms that follow a logical sequence (e.g., e-commerce checkout, travel booking) should use a progress bar. Users should be allowed to jump around between steps they’ve completed. • 2 • Complex processes (e.g., income tax, business registration) should use a summary menu that updates as the user completes sections of the form in any order. • 3

16. Layout: Progress bars vs. summary menus • The summary menu in the H&R Block iPad app shows the various sections the user needs to complete and his/her progress. • This progress bar clearly shows the steps in the checkout, which step the user is currently on, and which have been completed.

17. Layout: Field dependence • If one field is dependent on the input of another field (e.g., province or state depending on the country selected), the dependent field should come after the field it depends on. • 1

18. Layout Issues The Nike+ registration form suffers from a number of layout problems: The form uses two columns – though tabbing through the form goes in the correct order, it is more complex. The user must switch between keyboard and mouse input multiple times (password  date of birth  post code  gender). The Date of Birth drop downs cannot be activated using the keyboard. Error messages (besides being mostly useless) are not visually grouped with their field – is “Please fill this out” for the First Name or Email Address field?

19. Labels: Where to put them • Convention suggests: • Easy, short forms: above the field • Easy, long forms: beside the field, right aligned • Complex, long forms: beside the field, left aligned • 1 • Make sure the label is near the field so that there is no ambiguity about which label goes with which field. • 2 • On small screens that zoom in on forms, always put the label above or inside the field. • 3

20. Labels: Where to put them • If you put the label inside the field, make sure that the field can be understood without a label (e.g., once there is data in it). This is especially important if there is a validation error, because the user may not be able to determine what the input should have been. • 4 • If you put the label inside the field, make sure it’s visually distinct from user input and doesn’t disappear until the user starts typing. Also make sure your form doesn’t think the label is data when the user submits the form. • 5

21. Labels: Where to put them • Twitter puts labels inside the field, but they disappear as soon as the field comes into focus. • Because the labels are beside the fields, the user cannot see them when filling out the form on a mobile device.

22. Labels: Words vs. sentences • Do not use a sentence when a couple of words will suffice (e.g., “What is your name?” vs. “Name”). • 1

23. Labels: Words vs. sentences • Amazon unnecessarily uses sentences – words would have sufficed.

24. Labels: Sentence case vs. title case • Write in sentence case. It’s easier to read than title case. Never use all caps. • 1

25. Labels: The “label for” tag • Use the HTML attribute “label for” so that the labels for radio buttons, checkboxes, etc. are clickable. • 1

26. Input: Choosing an input type • Choose an input type that is appropriate to the data. • 1 • Radio buttons are appropriate for single choices. Checkboxes are appropriate for multiple choices or a yes/no answer. • 2 • Use a drop-down menu instead of radio buttons when there are more than 4 choices, but be careful how that drop-down menu acts on mobile devices. • 3

27. Input: Choosing an input type • Predictive text may be a better option than drop-down menus on mobile devices, assuming the user knows what the options would be called (e.g., a list of countries). • 4 • Avoid free text entry on mobile devices if at all possible. • 5 • Take advantage of mobile capabilities – for example, if you need a user’s location, can you use their GPS? • 6

28. Input: Choosing an input type • iPhones cut off long drop down menu options (iOS 7+ is slightly better with smaller fonts, but still only uses one line of truncated text). • Checkboxes are inappropriate for this question, as the user should only be choosing one answer – this should be radio buttons.

29. Input: Mandatory vs. optional • Always indicate required fields (unless they’re all required), and include the indication as part of the label (not the right of the field). Mark optional fields with: • Field label (optional) • 1 • Make sure that instructional text (e.g., “All fields are required”) is directly in the scan path of the user. • 2 • Do not use the colour red to denote mandatory fields – it should be reserved for errors messages. • 3

30. Input: Mandatory vs. optional • LinkedIn nicely marks “Include a personal note” as optional, but it turns out it’s actually required.

31. Input: Text field length • Make sure your fields are large enough to accommodate typical/expected inputs. All input should be visible. • 1 • Generally, all input fields should be the same size (this makes the form more pleasing to the eye). It is acceptable to occasionally deviate from this for certain inputs, e.g., a zip code field should only show 5 characters. • 2

32. Input: Text field length • This form uses the same width for most text fields, except where it is appropriate to accept/enforce a different input length (zip/postal code, phone number, date of stay, feedback).

33. Input: Auto advance • Do not split data (e.g., telephone numbers, credit card numbers) into multiple fields and then auto advance the user to the next field. Use one field that parses the data on the back end or uses an input mask. • 1

34. Input: Smart defaults • Where possible, infer or assume default content. E.g., if most of your users are based in North America, put Canada and United States at the top of the country list. • 1 • Retain user information from one page/step/section to the next. E.g., if they enter a postal/zip code in a shipping estimator, use that to prepopulate address information in the checkout flow. • 2 • Remember that your users may not all fit into the box that you define for them (e.g., what if they don’t have a province/state?). Make sure you provide an option to provide the correct data. • 3

35. Input: Smart defaults • Marketing consent should always be opt-in (the user has to consent to being marketed to), not opt-out. In several countries, opt-in is now required by law. • 4 • Drop down menus should have a default “null” option – if the user forgets to select an appropriate answer, this can be checked on validation. • 5

36. Input: Input masks • Never require the user to do work that the server can do. Forcing a user to a particular format (e.g., 555-123-4444) is just lazy programming. • 1 • Ideally, allow the user to enter data in whatever format they would like, and parse it on the back end. • 2 • Realistically, use input masks to control the format in which data is entered. For example, a phone input mask – (_ _ _) _ _ _ - _ _ _ _ – would ignore any non-numerical input, even if the user types it. • 3

37. Input: Input masks • These fields use input masks to control data entry. The user can easily see the expected format, and unacceptable data is simply ignored.

38. Input: HTML5 keyboard types • HTML5 lets you specify a specific keyboard type for input fields so that an appropriate keyboard is displayed. These include “number”, “tel”, “email”, “url”, and “date”. • 1

39. Input: HTML5 keyboard types • For a complete list of HTML5 keyboard input types, see http://www.w3schools.com/html/html5_form_input_types.asp

40. Input: Autocapitalize and autocorrect • Autocapitalize should be turned off for email addresses, URLs, usernames, passwords, and anything else that might be case-sensitive. • 1 • Autocorrect should be turned off for any field that may accept non-standard spellings (e.g., names, email addresses, URLs). • 2

41. Input: Splitting names • Do not split the user’s name into separate “First Name” and “Last Name” fields. You may have users whose names do not fit this pattern. • 1 • If you really require a piece of data that allows you to address a user by name, consider adding a “Given Name” or “What do you like to be called?” field. • 2

42. Actions: Primary vs. secondary • Where possible, omit secondary actions. They’re typically actions that have undesired consequences if clicked by mistake (e.g., Cancel, Reset). • 1 • Give secondary actions less visual prominence than primary actions. • 2 • Align the primary action with the left edge of your fields. Put the secondary action somewhere out of the way. • 3

43. Actions: Primary vs. secondary • In this form, the “Cancel” button is completely unnecessary, is right where users will click by default to submit the form, and is not visually distinct from the primary call to action (Submit).

44. Actions: Language • Just because the default text on a submit button is “Submit” doesn’t mean you should use it. Use descriptive words and phrases like “Get the whitepaper”, “Join the community”, or “Place your order”. • 1 • In multi-step forms, don’t just use “Continue” or “Next”. Tell the user what’s coming next: “Continue to Shipping Information”. • 2

45. Actions: Language • The Microsoft Outlook Web Access password change form has two “primary” actions – “Change Password” and “Continue”. It is not at all clear what “Continue” might do.

46. Help: Instructions • Your form should be pretty self explanatory. Any instructions that you do need to provide should be at the top of the form. Keep them short and succinct, and know that users will tend to ignore it anyway. • 1

47. Help: Instructions • The “all fields required” instruction (red arrow) on this contest entry form is buried right in the middle of a whole bunch of text that users most likely won’t read.

48. Help: Dynamic help • Instead of showing help text with each field, show it when requested. Include a “?” icon or display the help text when the user focuses on the field. • 1 • If you are asking for a sensitive piece of information (e.g., social insurance number, birthday), display a reason why directly on the form and adjacent to the field. • 2

49. Help: Dynamic help • Facebook provides dynamic help when they ask for your birthday.

50. Errors: Error handling • Errors must be displayed on the page where the form is, not a separate page and not a pop up window. • 1 • Emphasize error messages through colour (usually red), icons (usually a warning sign or exclamation mark), and prominence (usually at the top of the page in a large font). • 2 • Highlight the field(s) where the error occurred so that the user can easily find what they need to fix. • 3