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