INSPIRE Form design principles

Best practices - Form Organization

  • Take the time to evaluate every question you are adding to your forms. Be vigilant about removing everything that isn’t necessary.

  • Strive for succinctness in all the questions (labels) you ask in your forms.

  • When succinct labels may be misinterpreted, look for opportunities to use natural language to clarify the questions your forms ask people to answer.

  • Ensure that your forms speak with one voice, despite questions from several different people.

  • Organize the content on your forms into logical groups to aid scanning and completion.

  • When possible, structure your forms as a conversation. Natural breaks between topics will emerge that can help you organize your form.

  • If a form naturally breaks down into a few short topics, a single Web page is likely to be a good way to organize the form.

  • When a form contains a large number of questions that are only related by a few topics, multiple Web pages are probably a good way to organize the form.

  • When a form contains a large number of questions related to a single topic, one long Web page is generally a good way to organize the form.

  • Consider asking optional questions only after a form is completed. Chances are you’ll get more answers than if these questions were part of the initial form.

  • Consider using Web convention surveys to discover patterns in how forms are organized on specific kinds of sites.

  • 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.

Best practices - Path to completion

  • Ensure that the titles of your forms match people’s expectations and succinctly explain what each form is for.

  • For forms requiring substantial time or information requiring look-up, use a start page to set people’s expectations.

  • Make sure that you illuminate a clear path to completion through a form by using clear scan lines and effective visual pacing that comfortably takes people from start to finish.

  • For mission-critical forms like checkout or registration, remove distractions and any links or content that may lead to form abandonment.

  • For forms with a known sequence of multiple Web pages, include progress indicators that communicate scope, status, and position.

  • For forms without a clear sequence of pages, do not include progress indicators or use more general progress indicators instead of those that set incorrect expectations.

  • Consider the experience of “tabbing” through a form when making form layout decisions.

  • Use the “tabindex” HTML attribute to control tabbing order through a form.

Best practices - Form elements

  • Web form labels should use succinct, natural language and consistent capitalization to make answering the questions they pose as easy as possible.

  • When you are trying to reduce completion times or if you need flexible label lengths for localization, consider top-aligned labels.

  • When your form requires people to scan labels to learn what’s required or to answer a few specific questions out of many, consider left-aligned labels.

  • When you are under extreme space constraints for very short forms, labels within inputs may be a good solution. Just ensure that you have the right interactions and context in place.

  • Make sure that you distinguish clearly between labels and data, especially when using labels within input fields.

  • When considering different label alignments for different forms in a single application, think through the context versus consistency trade-off.

  • Different label alignments in a single form will disrupt a clear path to completion and may confuse people.

Best practices - Input fields

  • Use the right input field for the type of question you are asking: Does it require a yes or no answer; a selection from mutually exclusive options; etc.?

  • Where possible, ensure that field lengths provide meaningful affordances that help people answer questions effectively.

  • Otherwise, utilize a consistent length that provides enough room for correct answers.

  • Try to avoid optional input fields in forms. If most of the inputs on a form are required, indicate the few that are optional.

  • If most of the inputs on a form are optional, indicate the few that are required.

  • When indicating what form fields are either required or optional, text is the most clear. However, the * symbol is relatively well understood to mean required.

  • If you do use * to indicate required fields, don’t forget a legend that explains what it indicates.

  • Associate required or optional indicators with input labels to give people an easy way to see which questions need to be answered.

  • If there’s a natural structure among input fields that provides a valuable clue on how to answer a question, look for ways to group these inputs visually to clearly communicate that structure.

  • When there’s clearly more than one way to format an answer correctly, consider using a flexible input field.

  • Ensure that flexible inputs don’t make providing easy answers more difficult.

Best practices - Help text

  • Don’t use help text to compensate for the shortcomings of your forms. Striving to minimize the amount of help text on your forms will push you toward better design solutions.

  • Help text is best for explaining unfamiliar data requests, such as why certain questions are being asked, security and privacy concerns, recommended ways of providing answers, and indicating optional answers.

  • Concise help text visible and adjacent to the question being asked provides the most clarity for people.

  • Help text within input fields should only be used to provide recommended ways of answering questions.

  • If your form is asking questions people have answers for but may be unsure how or why they should answer, consider using an automatic inline help system.

  • If your form is asking unfamiliar or complex questions, and is likely to be reused by the same people multiple times, consider using a user-activated help system.

  • Unless you have a lot of help text or content (graphics, charts), for each question being asked, use an inline system that avoids page-jumping and rollover problems.

  • If you do have a lot of help content, use a consistent help section instead of an in-line solution.

  • Be as specific as you can with help text. If help text applies to a group of related input fields instead of individual inputs, consider devoting a portion of the page to displaying help to communicate a clear association between the group of fields and the help text.

  • Triggers for user-activated help text, such as icons, links, or buttons, should be placed next to labels and not input fields.

  • When asking for sensitive information, consider including actionable help text that allows people to confirm that their information is safe.

Best practices - Errors and Success

  • Clearly communicate when an error is blocking someone from completing a form. Error messages are arguably the most important element on a form when present. Make sure they appear that way!

  • Display error messages in context so they can be resolved quickly.

  • Provide actionable remedies that enable people to resolve errors easily.

  • Top-level error messages should indicate an error has occurred and how it can be resolved. If multiple errors exist, they should be listed in the top-level message.

  • If any input fields are responsible for an error, clearly mark them with a double visual emphasis to ensure they are noticeable.

  • Visually associate any responsible form elements with a top-level error message to clearly communicate they need to be resolved in order to continue.

  • Reserve red text and warning icons for error messages.

  • On short forms, it may be possible to omit either a top-level message or indicators for responsible input fields. If you choose this approach—do so thoughtfully.

  • Clearly communicate when a form has been completed successfully and what happened as a result using success messages.

  • Provide success messages in context so as not to block any further progress.

  • Consider dynamic success messages to highlight the results of a successful form submission.

  • Avoid success message page dead ends.

Best practices - inline validation

  • Consider using inline validation to confirm or suggest valid answers and to help people stay within limits.

  • Inline confirmation works best for questions with potentially high error rates or specific formatting requirements.

  • Inline suggestions work best when there is a large set of valid answers people can pick from.

  • Inline quality indicators can guide people to better answers to complex questions.

  • When validating people’s answers inline, do so after they have finished providing an answer, not during the process.

  • If you need to change people’s responses into a specific format, make sure you do so after they have finished providing an answer, not during the process.

  • When input limits exist, communicate their boundaries using real-time, dynamic updates.

Best practices - Unnecessary inputs

  • Carefully examine all the questions being asked in your form for opportunities to eliminate unnecessary inputs.

  • Look for patterns in how people answer questions that allow you to infer answers accurately.

  • Be mindful not to complicate questions for the sake of removing inputs.

  • Smart defaults can help people answer questions by putting default selections in place that serve the interests of most people.

  • Because people are likely to leave default selections in place, ensure they align with most people’s goals.

  • Whenever possible, include a default selection in a set of radio buttons. If no clear default exists,

  • chances are that people will still understand they need to make a choice. But if they don’t, they’ll get an error.

  • Personally relevant default selections enable return customers to complete forms faster because their answers are “sticky.”

  • Think through where personalized defaults make sense. It won’t be every input on every form.

Best practices - Additional inputs

  • Additional inputs can be used to provide added or advanced options to the people who need them without getting in the way of people who don’t.

  • You should map additional inputs to prioritized customer needs. Primary use cases should be up front and visible; secondary use cases may be a click away.

  • Additional inputs are usually more welcome when invoked by people (user-activated) than when automatically surfaced.

  • Ensure that the actions that trigger additional options are clearly worded. If additional options are triggered automatically, try to provide a clue (icon, text) that sets expectations.

  • Within a single form, try to maintain a consistent approach to additional inputs.

  • If you need to expose a large number of additional inputs, consider using an overlay instead of exposing them inline to avoid page jumping and disorientation.

  • Ensure that overlays don’t cover the input fields they are helping people fill in so people can still enter an answer on their own.

  • When additional options need to be considered in isolation, consider using a modal overlay.

  • Make sure that there are clear ways to close or cancel a modal overlay and return to the form.

  • Show the choices made in additional input overlays to people when they return to the form.

  • When your primary goal is to engage customers, additional inputs can be a captivating way to step people through choices.

Best practices - Selection dependent inputs

  • Page-level selection-dependent inputs are probably your best bet when the number of additional options for each initial choice is large.

  • Though you need two Web pages to break up the form, the dynamic hiding and showing of additional inputs won’t confuse people, and they won’t need to question whether or not their choices are mutually exclusive.

  • Vertical and horizontal tabs actually perform quite well in all-around usability, satisfaction, and eye-tracking metrics but come with the gnarly problem of mutual exclusivity. I’ve gotten conflicting data on which of these options resolves this issue so they both seem to be stuck with it. If you can get around mutual exclusivity through clever interaction or visual design, good performance is yours to be had with these solutions.

  • When you have a long list of initial options (more than 4 or 5) each with its unique set of selection-dependent inputs, using a drop-down list and visual grouping for the additional option is likely a good way to go.

  • If you only have a few additional inputs for each initial option, exposed below radio buttons or exposed within radio buttons might be your best option. I’ve seen both of these options cause confusion with excessive page jumping and disassociation between initial choices, so tread carefully. But if you really only have 1–3 additional fields per initial choice, I’d go with exposed inline radio buttons. Just make sure you use clear visual associations and transitions, if possible.

  • All options exposed as inactive or all options exposed are basically nonstarters because people are quickly overwhelmed by too many options that don’t map to their goals

  • Overall, hiding irrelevant form controls from people until they need them results in forms that are easy on the eyes and completed quite quickly.

  • Overall, displaying initial options and their selection-dependent inputs in close proximity to one another seems to lead to high satisfaction ratings.

  • In all cases, maintain a clear association between the initial selection options. Don’t let people lose sight of their initial top-level choice.

  • In all cases, clearly associate selection-dependent inputs with their trigger. All the examples outlined in this section do so with either yellow backgrounds or gray outlines.

  • In all cases, avoid excessive page jumping that disassociates selection-dependent inputs from the initial set of options.

Best practices extracted from the book “Web Form Design” by Luke Wroblewski

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2013-10-22 - JavierMartin
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Inspire All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback