Form

Overview

Use a form to allow people to enter new information or edit existing records.

Forms can be short and simple or long and complex, or a mix. Forms may display as dedicated pages, side panels, or modals, depending on their context.

When designing a form, think about the following factors:

1. Make sure the user understands what’s asked for, and why. Write labels that your audience will understand. Provide reassurance that sensitive data will be handled with care.
2. Use defaults where possible to simplify inputs. Defaults are best used for inputs that have been filled in before or tend to have the same answer across contexts. Avoid defaults, however, where data may be sensitive or where security concerns exist.
3. Recognition over recall. Choosing from a list can be easier than choosing from memory. If your input requires a specific format (such as a date or address), provide a hint of what the format should be rather than making users guess.
4. Be clear and forgiving about errors. Show an error as soon it’s made and provide clear instructions about how to resolve it. Check out our Error guidance for more information.
5. Consider the context. Is the data familiar to your audience or is it new? Is this a form they’ll fill out frequently or rarely? Answers to those questions might change the defaults and help text you use.
6. Organization and chunking. If your form is long, organize your form into sections of like inputs to ease cognitive overload and make the form feel easier to complete.

Adapted from Designing Interfaces by Jennifer Tidwell (2011).

Variants

Usage Guidance

When to Use

• Use a Form to allow users to add new information, such as a new account, a new record, request, or a new time entry.
• Use a Form to allow users to edit existing information, such as their account preferences, an existing shift, or their benefits information.

When to Use Something Else

• When a form has many inputs that can be chunked into logical steps, is completed infrequently, or is generally completed by new users, consider a Wizard instead.
• Users need to edit inline or stay in context of a page. Consider a Microtransaction instead.

UX Scorecards

The Forms Framework provides a set of UX Scorecards to help evaluate your forms. These can be used by anyone on the team- design, PM, QA, or Engineering!

The Look

The Feel

Applying the Scorecards

Symbol	Label	Score
	Good	1
	Needs Improvement	2
	Poor	3

Two or more evaluators complete the following steps:

• Identify the target user, persona or JTBD (very similar to an initial step in a usability test).
• Determine the critical or top tasks.
• Decompose each task into logical steps and the path(s) this typical user would take to complete the task. Specify what steps your target user will take through the interface. There will likely be disagreement on what path users actually take; use data when available and document judgments.
• Independently score the difficulty/mental effort of each task step using a 3-point scale, referred to as the scoring rubric. Use the recommendations in the scorecards to help guide you!

Best Practices

Organization & Layout

• Most forms display better when inputs are displayed in a single column, which improves scannability.

• Keep it short. Remove any fields that aren’t strictly necessary (or hide them in an expansion at the end of the form).

• Don’t use high density forms for mobile or touch screen devices as it reduces the tap target area.

• Don’t use tabs in forms as this can present challenges with errors or inputs that are hidden from view. Consider a Multi Step Form, expanders, or a Wizard instead.

Inputs & Labels

• Use plain, concise labels in inputs. For more detailed information, refer to the Content Style Guide for Field Labels, Menus, and Radio Buttons.

• Ensure you’ve chosen the correct control for the information you’re asking for.

• Use defaults where possible to reduce the time it takes to fill out a form. Use defaults in cases where most users would enter the same information. (For example, defaulting an employer’s name or today’s date where applicable.)

• Generally, we recommend allowing inputs to fill the full width of their container (stretch spacing) in forms. However there are specific use cases where fixed size inputs shoud be used. See the Forms Framework Documentation for more information.

• Don’t stretch inputs when the expected input length is known or where the input width matches the users expectation, such as zip codes and dates. Conversely, don’t shrink inputs that generally take longer inputs such as last names. Consider globalization and other languages when determining input sizes. See the Forms Framework Documentation for more information.

• Don’t ask for information that’s not truly needed. Respect the user’s privacy. Give some reassurance that sensitive information will be handled with care.

Errors & Alerts

• Inform users of errors as soon as possible.

• Denote errors with clear, specific, and concise language. See our Content Guide on Error and Alert Messages for more information.

Density

• Ensure you’re using the right density for your user. Learn more with the Forms Framework Guidance.

Basic Form

Use a basic form to allow users to enter information in a logical and structured way.

Basic forms may capture a large or small amount of data. Forms that capture a small amount of data can be displayed as a side panel or a modal. Generally, these forms display best with a single column of inputs, to improve scannability, such as this example.

Forms that capture larger amounts of data are generally displayed as a full page or a scrolling modal. Longer forms may display inputs in multiple columns to reduce scrolling. In longer forms, group inputs together logically and make optional sections easy to recognize and skip, such as this example. For examples of columns and grouping, check out the Microtransactions Starter Kit as well.

In forms, content design and affordance should primarily serve to guide a user, but instructional text may be used as needed to provide contextual guidance for the information that users are filling out. Instructional text may be placed at the beginning of a form, such as this example, in context with specific inputs, such as this example.

Once a basic form is submitted, users should see a confirmation that their changes have been saved. If they try to submit a form with errors, display an alert & inline error messages on the inputs that contain errors. Learn more with our Errors and Alerts article. If users try to navigate away from a form without saving their changes, display a Confirmation Modal prompting them to save their changes.

Anatomy

A form consists of:

1. Form Title: Forms should always contain a title. Depending on the context, the title may be placed in the Workday header or in the form itself. Instructional text can be provided, if needed. When deciding whether to include instructional text, refer to the Instructional Text section of the Content Style Guide.
2. Instructional Text (Optional): Text applied to the top of the form or inline to help users understand how to complete the form, indicate any required or optional input, and other necessary information that can reduce confusion and minimize the chance of errors. When deciding whether to include instructional text, refer to the Instructional Text section of the Content Style Guide.
3. Inputs: Inputs should be placed in a logical order that follows standard conventions, such as putting the Text Input for First Name before Last Name. Keep input labels concise and to the point to help users understand what information is being requested of them. Where labels may need extra explanation, customers may configure Quick Tips, as seen in this example. For content recommendations refer to the Content Style Guide for Field Labels, Menus, and Radio Buttons.
4. Required Inputs: Required Inputs: Required fields are marked with a red asterisk. If a value is not selected when the user submits their form, an error message is triggered in response. Required attributes must be applied to required fields for screen readers.
5. Section Title (Optional): Long forms with many fields can be overwhelming. Grouping related fields can help users make sense of information they need to enter. These groups help users focus on smaller, more manageable tasks and makes it easier for users to scan the form.
6. Inline Error and Alert messages: Errors and alerts that are associated to specific elements on the page use a combination of message and visual cues to help the user locate and address them. If possible, provide immediate inline validation when a user shifts focus from an input. This allows the user to fix these issues quickly and proceed in filling out their form in a linear order. More detailed information on error and alert messages, as well as examples, can be found in the pattern article on Errors and Alerts.
7. Action Buttons: Allows users to submit or leave the form. Action buttons should be clear and obvious and are a crucial component to allow your user to submit their form or advance in their process. Use Primary Buttons for main actions and Secondary Buttons for additional actions such as Cancel.

Once a form has been submitted, display a confirmation message in the form of a toast or other success message to let the user know their content has been submitted successfully. See our Content Guidelines and Tooltips and Toasts for more information. If a user tries to navigate away from a form without submitting or saving their information, prompt them with a confirmation to either save their changes or cancel.

If there’s an error submitting the form, such as a server error on submit, use a dialog to alert the user to the error.

Usage Guidance

When to Use This Variant

• Basic forms will be used in most cases where users are entering new data or editing existing data.

When to Use a Different Variant

• When users need to reference a document, such as a PDF, when entering data, or when a form has extracted information from a document. Use the Form + Reference variant instead, to allow people to fill out a form in context.
• When a form could benefit from being split into two logical steps (for example, when input from one section relies on input from the last) use the Multi Step Form variant. When the form can be split into three or more logical steps, consider the Wizard pattern instead.

Best Practices

• For forms with a small amount of information, display inputs in a single column to improve scannability, such as this example.

• For forms with more information, use chunking to group related information into smaller sections, improving scannability and reduce overall cognitive load, such as this example.

• For forms where specific inputs may rely on what was inputted before, consider progressive disclosure, where specific inputs are displayed only after other information has been entered.

• For longer forms, if there are specific inputs or sections that are rarely used, consider hiding these in an expander.

• Do not use tabs in a form. Consider sections or expanders instead. If more chunking is required, consider a Multi Step Form or a Wizard instead.

See more Best Practices on the Overview Page.

Responsive Web

When forms display in responsive web and WebViews, the following changes are applied:

• Forms display in a single column of inputs.
• For the most part, inputs stretch to fill the full inner container.
• Lower density is applied to allow for more space between inputs.
• Input heights are increased to 48px to accommodate touch target recommendations for fingers.
• Text (including input labels, placeholder text, input text, form & section headers) is increased by a factor of 1.25.

See the spec for Forms Framework and the Layout Recommendations for WebView spec for more information.

Responsive Forms examples. Source: Form Layout Grid Spec (Figma)

Native Mobile

In Native Mobile, forms generally display in a new screen. Forms should display in a single column and inputs should take up the full width of the inner container.

Some considerations for mobile are:

• Choosing the correct keyboard. Ensure that the correct inputs bring up the correct keyboards. Mobile keyboards include: alphanumeric, numeric, email, and phone. Ensure the input brings up the right keyboard.
• Ensuring inputs aren’t covered. When a user taps into an input, ensure that the keyboard doesn’t cover the input they’re interacting with.
• Touch Targets. Ensure that touch targets on interactive components such as buttons and inputs are meet the recommended 48dp by 48dp touch target minimum. Check out the Canvas Mobile Figma Library or the iOS and Android components on the Canvas site to see examples of components that meet the recommended touch targets.

Example of a form on native mobile, using Canvas components. (Left: iOS, Right: Android)

Example of a form on native mobile, using MAX. ( (Left: iOS, Right: Android)

Accessibility

• Any form instructions (like explaining how required fields are represented visually in the form) must be provided near the top of the form.
• Field-specific instructions and formatting requirements must be included as part of the label or hint text to ensure that assistive technology will describe the necessary instructions or requirements to users.
• Labels for most form controls must be positioned to the left or directly above the form control; radio buttons and checkbox labels must be positioned to the right of the control
• Use of disabled form controls should be kept to a minimum. If a form control is disabled, provide an explanation for why it is disabled and how users can enable it.
• For additional accessibility considerations for Forms, refer to Accessible Forms.

Technical Implementations

The Forms Framework seeks to improve & modernize forms at scale at Workday by creating a coherent, comprehensive, and rationalized system to fix forms in a holistic way.

Considerations

• Be sure not to use the stretch properties for inputs where the input is fairly predictable, such as date or numeric inputs.

Documentation & Resources

• Docs.Build: Forms Framework (Dev & Design Docs)
• Forms Framework Figma Spec (Figma Spec)

Product Examples

Form + Reference

Use a Form + Reference to allow users to reference a physical document or other UI element when entering data.

Use a split view to display a form and the reference element side by side. Both containers should be able to be interacted with independently and should scroll independently.

A common implementation of this variant is to display a form alongside a PDF preview of a document that’s been uploaded and read using OCR. The PDF previewer should have independent controls allowing users to zoom in and out and traverse the document as needed. Ideally, when users traverse fields in the form they’re interacting with, they should be able to traverse the same fields in the document they’re interacting with. It can be helpful to allow the reference PDF to pop out into a new window as well.

Usage Guidance

When to Use This Variant

• When users need to reference a document, such as a PDF, when entering data.
• When a form has extracted information from a document, display the form and document side by side to allow users to review information in context.

When to Use a Different Variant

• When a form could benefit from being split into two logical steps (for example, when input from one section relies on input from the last) use the Multi Step Form variant.

Best Practices

• Both containers should scroll independently

See more Best Practices on the Overview Page.

Accessibility

• Users must be able to pan and zoom the reference document independant of the webpage. Explicit buttons must be provided for pan and zoom functionality.
• Provide a way to either view the reference document in a new tab/window or to download the reference document.
• For additional accessibility considerations for Forms, refer to Accessible Forms.

Globalization

When generating PDF and other formatted references, consider specifying relevant font, character encoding and character set to output supported language based documents without displaying issues.

Product Examples

Multi Step Form

Use a Multi Step Form when a form could benefit from being split into two logical steps; for example, when input from one section relies on input from the last.

Common examples include: selecting courses for an academic semester in one step, and reviewing those selections in a second step; selecting an initial set of parameters related to pay in one step (such as location & position), then in step two, selecting additional parameters that rely on parameters from step 1 to model an employee’s pay; selecting a country of origin in a first step, then filling out contact information in a format that matches the country in a second step.

Multi Step forms may display in a Modal, Side Panel, or full page. Consider adding “Step X of X” to the title of the modal to inform users as to where they are in the process. Users will enter information using various inputs (see our Inputs pattern article for more information) in the main portion of the modal. Calls to action on the modal should be “Continue” (or “Next”) and “Cancel” in the first step. In the second step of the process, the actions should be “Finish” (or “Submit”), “Back” (or “Previous”) and Cancel.

Usage Guidance

When to Use This Variant

• When users are filling out a form that can be split into two logical steps, where one step depends on the previous step.

When to Use a Different Variant

• When users are filling out a form that has multiple sections, but the sections don’t depend on previous sections. Use a Basic Form instead.
• When a form is split into more than two steps, consider a Wizard instead.

Best Practices

• Show users where they are in the process by adding text such as “Step 1 of 2” to the title.

• Indicate what will happen next in the actions of the modal. On the first step, the primary action should be “Continue” (or “Next”). On the last step, the primary action should be “Finish” (or “Submit”).

• If the Multi Step form uses a modal, ensure that the modal is a fixed size from step to step if possible. Maintain consistency in control placement to avoid disrupting muscle memory. Keep controls fixed at the bottom of the page or container as people progress through steps.

• Don’t prevent users from accessing previous steps to update their information. On the second step, provide an action called “Back” (or “Previous”) to allow users to continue.

See more Best Practices on the Overview Page.

Accessibility

• Multi-step forms must include a progress bar, step count, or percent complete indicator so users can understand their progress through the task.
• For additional accessibility considerations for Forms, refer to Accessible Forms.

Technical Implementations

None yet.

Product Examples

Product Examples