forms best practices
DESCRIPTION
FORMS Best Practices. 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. Forms often stand between a user’s goals and a business’ goals. - PowerPoint PPT PresentationTRANSCRIPT
FORMSBest Practices
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.
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
Commerce Community Productivity
User Objective Obtain Info, Buy Join Community Get Things Done
Business Objective Maximize Sales Grow & Increase Engagement
Increase Consumption & Time on Site
Example Site E-Commerce Social Networks Online Banking
Example Form Checkout Form Registration Form Transfer of Funds
Uses of Forms
Adapted from Luke Wroblewski’s Web Form Design: Filling in the Blanks
The Three Characteristics of Forms
Despite differences in what they do and how they work, all forms have 3 primary characteristics:
1. They establish a relationship between the user and the business.
2. They establish a conversation between the user and the business.
3. 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 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
Relationships & Conversations
7
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
How do you decide what to ask?
8
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?
How do you decide what to ask?
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
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
What matters: what you ask and why.
Appearance: The Six Components of Web Forms
Users have developed expectations for forms. They typically expect forms to have these components:
1. Layout
2. Labels
3. Input fields and controls
4. Actions
5. Help
6. Errors
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.
1The 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.
1Don’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.1Forms 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.2Complex 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 IssuesThe 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
1Make sure the label is near the field so that there is no ambiguity about which label goes with which field.2On 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.
4If 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. 1Radio buttons are appropriate for single choices. Checkboxes are appropriate for multiple choices or a yes/no answer.
2Use 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).
4Avoid free text entry on mobile devices if at all possible.5Take 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)1Make sure that instructional text (e.g., “All fields are required”) is directly in the scan path of the user.2Do 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.1Generally, 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.
1Retain 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.
2Remember 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.
4Drop 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.
1Ideally, allow the user to enter data in whatever format they would like, and parse it on the back end.2Realistically, 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.
1Autocorrect 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.
1If 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).
1Give secondary actions less visual prominence than primary actions.2Align 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”.
1In 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.
1If 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.1Emphasize 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).
2Highlight the field(s) where the error occurred so that the user can easily find what they need to fix.3
51
Errors: Error handling
The error messages in this checkout flow are shown in a pop up window – this means that the user must remember what was wrong once they dismiss the window.
52
Errors: Messages
Error messages should be written in plain language that tells the user:• What the problem is• Where the problem is• How to fix it
1
53
Errors: Inline validation
Inline validation is a great way to streamline filling out a form – the user gets instant feedback on whether the data they’ve input is valid.
1Show both valid and invalid data (e.g., green checkmarks and red “x”s) and include helpful error messages with invalid data.
2Inline validation must perform quickly – it’s distracting if the feedback isn’t virtually instantaneous.3
54
Errors: Inline validation
Facebook immediately validates fields and provides a descriptive error message when the field comes back into focus.
55
Errors: Data persistence
If the form must be reloaded after validation, ensure that all data is retained. This includes passwords, credit card numbers, etc.
1
mediative.com/contact
mediative.com/youtube
mediative.com/linkedinmediative.com/facebook
mediative.com/twitter
mediative.com/googleplus
CONTACT OUR DIGITAL EXPERTS