Forms

The forms pattern typically combines input, select, and button components with other context-specific components or patterns like file upload to enable users to enter information. For longer forms with four or more steps, reference Wizard.

Also known as: Form validation.

Anatomy

A. Form title (required): Brief statement describing the purpose of the form.
B. Form description (optional): Brief description of the form’s purpose.
C. Input field labels (required): Text indicating the purpose of the field and if the information is required.
D. Inline message (optional): Text communicating format requirements or relevant guidance.
E. Calls to action (required): Button components enabling users to submit the form.

Usage

Best practices

• Follow regional and global data regulations and laws. Consult with a Visa compliance expert throughout your process.
• Ensure that people of all abilities can use forms by referring to the Accessibility and Inclusive design guidance.
• Offer helpful information based on settings, user profiles, data, tracked usage behavior—or with the user’s permission.
• Use clear labels and examples to assist users in data entry.
• Reserve open-ended inputs like multi-line text fields for longer responses and match the input field size to the expected length of the entry.
• Communicate errors clearly by letting the user know what happened and give clear next steps.

Form components

Designing a form requires critical thinking about the context to determine the structure, sequence, and components used. The most common components are outlined below.

Input

Input fields allow users to enter text and edit data. The type of input field you use should reflect the length of the content you expect the user to enter. To learn more, reference Input.

• Single-line input enables users to input one line of content, for example: name/username, email, date of birth, and more.
• Multi-line input enables the user to enter multiple lines of content including comments and descriptions which are typically open-ended.

Selection controls

Selection controls give users predetermined options to select from. When deciding on a component, consider how many options you need to provide and how many items the user may need to select.

Calls to action

Calls to action (CTAs) guide users toward the next step—whether it’s submitting a form, saving progress, or moving to the next screen. Clear and consistent CTAs help users complete tasks confidently and reduce friction. Keep the order of buttons consistent throughout all product experiences to maximize usability and prevent confusion.

Client-side validation

Form validation is necessary anytime we accept user input. This ensures that the data entered is in the correct format, falls within a valid range (such as date fields), and isn’t missing information that can lead to errors. When there’s been a mistake or issue, effective and immediate error messaging helps users understand the problem and how to fix it.

Validation before form submission, also known as client-side validation, is an initial check that ensures all required fields are filled out and in the correct format. This method helps limit frustration experienced by the user because it reduces the need to go back, locate and correct mistakes after filling out a lengthy form.

Note: Client-side validation shouldn’t be used as an exhaustive security measure. Data entered should be validated using both methods because client-side validation only makes it easier for malicious users to bypass security.

Validation when the user leaves the field

VPDS recommends validating onBlur, not onFocus for client-side validation. An onBlur event happens when a field loses focus, which happens when the user clicks on, tabs out of it, or does something that makes another field or item within a form the active element.

If a field is left blank or information is entered incorrectly, an inline error message should display after the user shifts focus to another field. Use inline error messages to help the user notice, locate, and correct the error. Once the error is corrected, the error message underneath the field should immediately disappear.

Server-side validation

Once a form is submitted, it’s sent to the server for further validation using one of the server-side scripting languages. After the server-side validation process, feedback is then sent back to the user in the form of a success or error message. Server-side validation is important because it provides additional evaluation of the data entered by the user and helps protect against malicious users.

It’s important to note that there are a few different scenarios that can lead to a server-side error outside of missing or incorrect user inputs such as problems connecting to the server.

Validation messaging

Server-side validation typically results in a success or error validation message. These messages can be presented using a range of components to indicate if the form was successfully or unsuccessfully validated. When unsuccessfully validated, the messages will generate an error.

While validation messages are an effective method to draw attention to errors, it shouldn’t be used as the only form of error indication as it forces the user to search for the field in error. Additionally, the message may come out of view forcing the user to rely on memory to fix the issue.

For additional context on how to create messaging for section messages commonly used to communicate server-side errors, visit Messaging.

Server-side validation: Success scenarios

When information is successfully validated on the server side, the user will typically receive a success message. The type of component used to communicate the success depends on your context. We recommend using a flag if the user is taken to a new page after submission or a section message if they receive the success message on the same page. For specific guidance on how to decide on the right component for your context, where to place it, and its level of disruption, visit Feedback and status.

Server-side validation: Error scenarios

Reference the scenarios below to better understand the different types of unsucessful server-side validation that result in error messages.

One or more fields in error

One or more fields can be in error when the user submits the form but left required fields blank, entered data in an incorrect format, or both. In this scenario, the user submitted the form but left the email field blank and formatted the phone number field incorrectly.

The user might have been provided with client-side inline error messages but still submitted the form resulting in the server-side validation error. In the example below, we provided feedback in the form of an error section message highlighting that an error occurred and used inline messages draw attention to the fields in error and tell the user how to fix them.

Empty form submission

Generally, VPDS doesn’t recommend disabling the “Submit” button when information is incorrectly formatted or left blank. In this scenario, the user submitted the form without entering an email or phone number, which are required fields. They also didn’t receive client-side inline messages since they didn’t interact with any of the fields before submitting.

In the example below, we provided feedback in the form of an error section message highlighting that required information is missing and used inline messages draw attention to the fields that need an input.

Note: While this is technically client-side validation, it’s referenced in the server-side error framework.

Invalid form page level error

In this scenario, the user has completed the form and the input formatting criteria is correct, but due to security reasons you aren’t allowed to identify exactly which field is mismatched.

In the sign in example below, we provided feedback in the form of an error section message highlighting that required information is missing and used inline messages draw attention to the fields that need an input.

Note: While this is technically client-side validation, it’s referenced in the server-side error framework.

Error occurs after the user clicks submit.

Resubmit form

As mentioned, there are a few different scenarios that can lead to a server-side error outside of missing or incorrect user inputs such as problems connecting to the server, connectivity issues with the software, misconfigured settings, or problems with the code or scripts that run on the server. In this scenario, the user has completed the form and the input formatting criteria is correct but the server is having issues connecting and sending the data successfully.

In the example below, we provided feedback in the form of an error section message to communicate that we are experiencing connectivity issues and suggest the user either try to submit the form again or to try again later.

Optional vs. required labels

Always ensure required fields are clearly labeled. While this may seem repetitive, it helps users scan for necessary information and reduces errors. There are two methods for labeling required fields based on your use case. Whichever method you select, use it consistently across your experiences.

Note: Previous VPDS guidance recommended only marking optional fields. Our guidance has been updated to reflect current Nielsen Norman Group recommendations. Learn more about optional vs. required labels in Forms.

When required is implied

Although it’s usually recommended to label required fields, there are cases where it’s implied that the field is required. This is common when there’s a one or two fields fundamental to completing of a task, like the username and password fields on a login screen. In these cases, marking the fields required isn’t necessary but can add additional clarity.

Labeling optional fields

It’s not generally necessary to mark which fields are optional. While doing so can support clarity, it also adds unnecessary visual noise. Whatever you choose, apply the choice consistently to avoid confusion.

Layouts

The form pattern features a single, full-page layout designed to provide a consistent and user-friendly experience. This layout ensures all form elements are easilty accessible, promoting a seamless flow from start to finish.

Full page (default)

The full page default layout offers a straightforward, intuitive structure for all forms. It maximizes space for content ensuring users can focus on completing their tasks without distractions.

Columns

The single-column form design creates vertical momentum and maximizes usability. When possible, avoid using multi-column layouts as this approach may create confusion around the logical sequencing of the fields. However, in some cases, multi-column forms may work well when gathering certain information, such as address entry. When planning your layout, consider the amount of fields, the presentation of the form, and field groupings.

Content

• Use sentence case for all content except proper nouns or acronyms.
• Reference Button for guidance on button formulas and creating button labels.
• Follow content guidance in Input when writing inline messages, including errors.
• Review Messaging for specific guidance on how to craft content in success, warning, and error messaging.

Form titles and subtitles

• Use short, concise, and scannable titles with no punctuation.
• Limit titles to three to five descriptive words. If your title can’t be condensed, consider using a subtitle with your title.
• Limit subtitles to one to two short sentences with punctuation.
• Use sentence case for both titles and subtitles. The only exceptions are proper nouns or names.
• Avoid repeating the same words or phrases across the title and subtitle. If struggling to simplify, omit the subtitle.
• Use subtitles to describe why the information being collected is relevant or to give instructions about the form as a whole.

Form labels

• Limit labels to a maximum of three words.
• Use sentence case and no punctuation. The only exceptions are proper nouns or names.
• Use plain, concise, and descriptive language to help users understand what the corresponding field means.
• Use parallel structure across labels. Although nouns like first name, last name are typically used, in some contexts it may make sense to use verbs such as “Enter email”, or “Confirm password”.
• Don’t use placeholder text within the input field instead of a label.
• Avoid abbreviations or jargon that aren’t widely understood by global audiences.

Related guidelines