Web form design

From James Van Dyne
Jump to navigation Jump to search

Title: Web Form Design: Filling in the Blanks

Author: Luke Wroblewski

Length: 320

Chapter 1: The Design of Forms[edit]

  • Most people dislike filling out forms
  • Most forms are designed from the "inside out" - requirements of the database table the results will stored in.
    • Example: "Member" of a website is defined as unique combination of first name, last name, email, and password
      • Inside-out: Start with a form requiring first name, last name, email, and password.
      • Outside-in: Start with the perspective of people outside your organization or website. How would they define being a member of your service?
  • "Forms suck. We should design accordingly"
  • Screenshot of Facebook's registration form with half of it being taken by a security captcha

Form Design Matters[edit]

  • Ecommerce and physically shopping in a store are similar in the browsing and putting things in a basket. At checkout one is a friendly social experience and the other is a form.
  • Online all experience become "just a form"
    • Want to join a fun new social network? Just fill in this form
    • Care to share this video with a friend? Just fill in this form
    • Want to response to a blog post? Just fill in this form
    • "And since participation—number of members, number of activities completed, etc.—is how most social applications thrive, the organizations running these sites rely on forms for business success."
  • Web forms stand in the way of user needs and business goals.

Impact of Form Design[edit]

  • Web forms broker crucial interactions - so they have a big impact on business goals
Data Sources To Measure Impact of Form Design[edit]
  • Usability Testing
    • number and location of issues
    • severity of errors
    • completion rates
    • time spent on form
    • satisfaction scores
    • subjective comments about tasks
  • Field Testing
    • Sources used to access information required by forms: documents, software, etc.
    • Environment in which forms are filled: loud office, small screen etc.
    • Additional context
  • Customer Support
    • Knowing the top issues can give clues where to start
    • Common ways to resolve reported problems
    • Demographics and common browsers/OS settings
  • Site Tracking
    • Completion rates
    • How people access
    • Which fields were used
    • Which data was entered
  • Eye Tracking
    • how do people make sense of the complexity of the form
  • Web conventions
    • Survey common solutions / patterns used on the web

Design Principles[edit]

  • Minimize the pain: make completing the form as simple as possible
  • Illuminate path to completion: make it abundantly clear how people can finish the form
  • Consider the context
  • Ensure consistent communication: different groups within an organization (marketing, design, business) are having conversations with customers through forms, make it speak with one voice

Chapter 2: Form Organization[edit]

What to include[edit]

  • Each field in a form requires a parse, formulate an answer, and input their answer. Speed up the process by removing as many questions as possible.
    • Is this information actually required?
    • Is there a way to collect this information automatically?
    • Is there a more appropriate place / timing to collect this information?
  • Different departments have different requirements, but the form still needs to speak with one voice.

    Users care about what they’re asked, why they are asked it, and beyond everything else, whether those questions are appropriate to the context, meaning whatever the user is trying to achieve by filling in the form. – Caroline Jarrett

  • Think about relationships of elements before placement
    • Why are they filling in this form?
    • What is their relationship with our organization?
    • Do they feel good or bad about it?
  • If you've already got a form ask yourself:
    • Why are you asking them?
    • Why _now_ ?
Four Strategies for Better Questions[edit]
  • Keep: Questions where you and your users are in agreement (e.g. asking shipping info after a purchase )
  • Cut: Remove questions that you don't really need the answer to right now
  • Postpone: Ask the question when it moves from unnecessary to necessary.
  • Explain: For information that users may be reluctant to give and you really need it, write a very short but clear reason as to why you're asking
    • e.g. "Asking you this now helps us to process your order more quickly".
  • People before pixels.

Have a Conversation[edit]

  • Forms facilitate conversation between a person and a company or organization
  • Thinking about how a form can be organized as a conversation instead of an interrogation can go a long way toward making new customers feel welcome.
  • Inputs gather responses, labels ask questions.
  • e.g. Consider the label “Issuing Bank.” What is that asking? Now, if we rephrased it as “What bank issued you this document?” odds are that you’d have a quicker answer.
    • Is "issuing" a term people use or something banks use?
    • Perhaps people think "Which bank gave you this document?"
    • "Using the terms your customers use to describe their actions helps frame questions in a more understandable way"

Organizing Content[edit]

The new Yahoo! registration form uses a conversational tone to engage new members. © Rosenfeld Media
  • To keep the conversation flowing smoothly, group your questions.
  • By understanding the context of each form, we can understand if we should have one long page or divide our form into multiple pages
  • When you approach forms as a conversation, natural breaks will emerge between topics.
  • If you can't decide, do a "Web conventions survey" and do a survey of how other websites are handling the same scenario
    • The first page tends to be Sign In
    • The second personal info etc..

Group Distinctions[edit]

  • Communicating meaningful distinctions between content groups doesn’t require a lot of visual difference
  • Using a minimum amount of visual information helps keep the focus on a form’s content and not its presentation
Many distinct visual elements on this form get in the way of seeing the questions the form is asking. Rosefeld Media©
A subtle background color change or thin rule is often all you need to effectively group related content in a form. Rosenfeld Media ©
  • "Information consists of differences that make a difference." Edward Tufte, Envisioning Information, 1990 Graphics Press

Best Practices[edit]

  • Question if every field in your form is necessary. Remove if not.
  • Strive for succinctness if your questions (labels)
  • Look for opportunities where natural language can help prevent misinterpretation of a question.
  • Ensure forms speak with one voice, despite multiple stakeholders requirements
  • Organize forms into logical groupings to help completion
  • Structure your form as a conversation where possible, natural breaks occur.
  • Consider asking optional questions only after a form is completed.
  • Use the minimal amount of visual information necessary to distinguish content groups.
  • Use initial capital letters to make the titles of content groups easier to scan.

Chapter 3: Path to Completion[edit]

  • Form titles should match the calls to action used to reach them
  • When a form will take a significant amount of time or require specific documents (e.g. a driver's license) a start page will help ensure completion and reduce frustration
    • Imaging being halfway through a long form only to find you can't finish it because you need access to document X
  • Clean scan lines provide for a clear path to completion.
An example of clean scan lines
Zig-zagging scan lines make it difficult to parse information.
  • A well-designed scan line has just the right amount of visual spacing between questions to enable an even pace between each label/input pair
    • Generally about 50 to 75 percent of the height of an input field between each question works best
  • Remove extra visual information on your important form pages because it can distract users
    • Your site navigation on your form pages is consistent, but can distract users and prevent them from completing the form
    • Let users focus on the task at hand

Progress Indicators[edit]

  • Progress indicators rarely tell the users the truth
    • Shipping -> billing -> place order (3-steps) quickly becomes
    • Shipping -> Select an existing address -> Add new shipping address -> Billing -> Verify payment (depending on card provider) -> Billing address? (6 steps)
  • Rather than giving specific pages in your progress indicator, favor outlines so no specific expectations are set

Designing Accessible Forms[edit]

  • An accessible form takes into account the unique needs of users who have limited or no vision, limited or no hearing, limited physical movement, or cognitive impairments
    • There's a 25% chance this could apply to your lifetime
  • Up to developers to enable accessible options
  • Accessibility options benefits other users too
    • Closed captioning helps when watching TV in an noisy environment
    • Keyboard-only is great for power users, who don't want to use a mouse
    • Alternative text helps people with slow connections / images disabled
  • Accessibility first requires
    • "Uber-minimize" the pain: Make it ridiculously easy to complete a form
    • "Uber-illuminate" the path to completion: Make it abundantly clear how a user can complete with needing to hear each character
    • "Uber-consider the context": Don't require users input a novel
    • "Uber-ensure consistent communication": Consistency makes life easier for everyone
  • Web Content Accessibility Guideline
    • Specify text for everything that isn't just fluff
      • alternative text for images (like Tooltips)
      • summary tags for tables (a brief summary of the contents of a table)
      • lablels that are implied by their physical relationship
      • titles for frames and pages - make them meaningful and make them unique
    • Make links unique - use labels that makes sense, not "Click here"
    • Don't use only color to convey information
    • Ensure good contrast between text and backgrounds - color blind users can't distinguish between certain colors
    • Make fonts large enough to read at least 14 pt
    • All functionality must be accessible using only a keyboard
    • Clear and precise language
  • Use tabindex to allow smooth tabbing through forms and prevent jumping

Chapter 4 Labels[edit]

Example of forms with top, right, and middle label alignments
Top, right, and middle label alignments
  • Top-aligned, left-aligned, right-aligned labels - the correct answer depends on your constraints

Top Aligned Labels[edit]

  • Quickest to fill out because the path to completion is clear.
    • Moving your eye from label to input, top-aligned: 50ms. left-aligned: 500ms, right-aligned 240ms
  • Good for forms that will be translated because longer translations won't effect design
  • Some designers always recommend top aligned labels because they're the quickest to complete.

Right Aligned Labels[edit]

  • Have some flexibility issues when label width changes
  • Provide for quick enough (170ms) label to input saccade (movement of the eye)

Left Aligned Labels[edit]

  • Unfamiliar data is easier to fill in when left aligned because the eye can scan a single column of labels without distractions of input fields
  • Slowest completion times of the form types
    • Not a bad thing if you want users to slow down and consider what they're inputting

Labels Within Inputs[edit]

  • Tempting to always halve the number of elements on the screens
  • Label needs to disappear when users inputs data
    • Also means that the context for the answer is gone
  • Not good for
    • medium / long forms
    • non-obvious questions (i.e. something the user may want to reference a label while answering
  • Good for
    • Single question forms (search box)
    • very familiar data (address)

Mixed Alignments[edit]

  • Just don't
  • Mixing alignments within an application (or even a single form) will make it more difficult to complete the form (path to completion becomes longer)
  • Users may not remember the alignment of your labels, but they may subconsciously consider your application "hard to use"

Best Practices[edit]

  • Succinct, natural language and consistent capitalization
  • When considering different label alignments for different forms in a single application, think through the context versus consistency trade-off

Chapter 5: Input Fields[edit]

  • Types of inputs
    • Text boxes
    • Radio buttons
      • Should set a default and ensure the label or the button can be clicked to select it
    • Check boxes
      • Make sure the label can be clicked to select it
    • Drop downs

Selecting Form Elements[edit]

  • Design teams often struggle with trade-offs that pit click-efficiency against error prevention, learn-ability against efficiency, majority case against corner case, and flexibility vs clarity
  • When designing a form to sell tickets online (up to 6 total tickets, with 3 different classes (general, child, senior):
    • Fandango used text boxes to input quantity. Simple, but users don't know they can tab between fields and move between keyboard and mouse
    • MovieTickets.com used dropdowns to select quantity - difficult to sue and easy to over look
    • A third solution could be to use radio buttons in a grid to let users select the quantity. But 12 form elements on the page is heavy and a lot to process
    • 3 solutions to the same problem using different input controls

Field Lengths[edit]

  • Affordances give us clues how to use an object. e.g. a handle on a door that looks like it should be pulled is an affordance for using a door.
  • Field length is an affordance for the amount of data that should be input.
    • Email and zip-code fields probably shouldn't be the same length
    • People get confused when fields are too long and think they may be missing something.
  • Use a consistent length for fields that don't clearly benefit from affordances

Required Fields[edit]

  • * next to a field means required on some sites and optional on others. Can't rely on convention.
  • Rather than having a * - add clear text "(optional" etc..) indicating required/optionality.
  • If you do use a symbol to indicate optionality prefer to align it with the label, not the field so it's easier to scan

Structural Design of Forms[edit]

  • Powerful design comes from the reuse of a small number of simple patterns
  • Core of a form is an input.
  • Inputs have many shapes, but pattern is the same: title, data, actions.
  • This structure helps define visual design (font, weight, color) and layout (alignment, margins, padding)
Grouping Inputs[edit]
  • Three basic input groups: Compound inputs (a tab-like input), related inputs (number of lots, items per lot input fields), and Parent/child inputs

Flexible Inputs[edit]

Different ways to input a phone number handled by a flexible input.
  • Many forms can be answer in multiple ways, but requirements require data in a certain format.
  • Rather than forcing the formatting upon the user, flexible inputs accept the user input in a variety of patterns and let a piece of code convert it to the appropriate format for the system
  • Progressive disclosure is also an example of a flexible input
    • e.g. wanting to include a map of the location where to meet, but you don't know the address - add a search field that let's people find the address of the location and thus a map.
    • Allows the simplest answer and more complex answers in a single form

Best Practices[edit]

  • Use the right input for the question you're asking
  • Ensure field lengths provide meaningful affordances to help people answer questions
  • Avoid optional input fields in forms
  • Optionality is clearest with text, but a * is well understood to mean required
  • When there's more than one way to answer a question, consider a flexible input field
  • But also Ensure that flexible inputs don't make easy answers difficult

Chapter 6: Actions[edit]

  • Primary actions enable the most importation action on the form (completion)
  • Secondary actions allow people to retract the data they've entered (cancel, reset, go back etc..)
    • As secondary actions are often destructive, reduce their visual prominence from the primary action (e.g. a link style button) to minimize the risk for potential errors
  • Primary action and secondary should be left-aligned under the form to decrease completion time
    • Putting the secondary action (cancel) directly under the form results in more errors

Actions In Progress[edit]

  • How do you signify that you're done?
    • If nothing changes - people may submit the form twice
  • Warning text like "only click the submit button once" burdens the user and is an "inside out " solution.
  • Better to replace primary action with animation or text message

Best Practices[edit]

  • Avoid secondary actions if possible. Single path to completion is best.
  • Provide clear visual distinction for secondary sections
  • Align primary actions with input fields
  • Clearly communication form "processing"