When to use
Forms are a fundamental part of user interfaces, and their design continues to evolve alongside advancements in input methods and the growing use of mobile and tablet devices. You might design a form to help users:
- Input data
- Sign up for or log into an account
- Register for a service
- Adjust settings (e.g. enable notifications)
- Complete a survey
- Purchase a product
- Submit feedback
Respect the user
Forms are designed to gather information and guide users with minimal friction. To help users scan and complete forms efficiently, follow these best practices:
- Ask only what’s necessary – Respect GDPR and other privacy regulations by requesting only the information required for the task.
- Group related content – Use section titles to organise related fields and provide clear context, making the form easier to scan.
- Follow a logical order – Arrange fields in a predictable sequence (e.g. first name, then last name) to reduce user confusion.
- Minimise input switching – Let users complete tasks with as few changes in interaction method as possible (e.g. from keyboard to mouse).
- Support auto-fill features – Design with browser autofill and password managers in mind to improve efficiency and accuracy.
- Use progressive disclosure – Reveal additional fields only when necessary. This helps reduce cognitive load and keeps the interface clean. See the Designing for longer forms section below for more on this.
- Labels – Clarify what each input field is for.
- Free-form input – Allow users to enter free-form text.
- Data input – Let users choose from preset options, like checkboxes, radios, selects, date pickers, switches, and more. Visit individual component pages for specific behaviours and visual states.
- Support text – Provides in-context guidance through assistive / helper text, placeholders, or tooltips.
- Actions – Enable users to submit, cancel, or exit a form.
Labels
Concise, well-written labels help users understand what information is being asked of them.
- Use sentence-style capitalisation – capitalise only the first word unless referencing a proper noun or product name.
- All input components must have a label, even if visually styled differently.
- Labels should clearly describe the required input.
- Do not use colons ( : ) at the end of label text.
- Keep labels brief and to the point, ideally one to three words. More is acceptable when posing a question. Use helper text separately to provide additional guidance if needed.
Top-aligned labels
Buckholt uses top-aligned labels by default. This arrangement places the label directly above the input field, creating a consistent left edge and maintaining close visual proximity between label and input. Top-aligned labels support better scannability and help users complete forms more quickly. Left-aligned labels are not currently supported.
- Advantages of top-aligned labels
- Supports faster form completion by improving scannability.
- Accommodates longer or variable label lengths, such as translations or localised content.
- Ideal for forms collecting familiar information, where users are less likely to make data entry mistakes.
- Best suited to shorter forms with fewer fields, where space is less constrained.
Required vs optional
Form fields can be either required or optional, and how they are labelled often depends on the form’s complexity and intended audience.
Simple forms
Shorter, user- or consumer-facing forms, such as sign-up, contact, or checkout flows, tend to have mostly required fields. In these cases, only optional fields should be explicitly labelled as (optional).
Complex forms
Longer, product-focused forms often contain many properties and settings. These tend to have mostly optional fields, with only a few required. In such cases, only required fields should be labelled as (required).
Usage guidance
The overall structure of your product or feature should guide how you label fields. The approach should be applied consistently across your product, or at a minimum, within each form type.
- If most fields are required, label only the optional ones.
- If most fields are optional, label only the required ones.
Reducing visual noise makes forms easier to scan and complete. Where many optional fields are necessary, consider grouping them in a separate section to minimise repetition and improve readability.
When to use
DO mark fields (required) when the majority of the fields are optional.
DON’T mark fields (optional) when the majority of the fields are optional.
Best practices
Apply a consistent pattern for required and optional fields across your product. Consider the overall balance of field types. For example, if most of your connection property forms contain mostly optional fields, all similar forms should use the same labelling convention (e.g. marking only required fields).
Refer to the Default values and Designing for longer forms sections for techniques to simplify and streamline form use.
Deciding what to use
|
Control
|
Usage
|
Context
|
|---|---|---|
| Text input | Entering short pieces of text | Names; phone numbers; addresses |
| Text area | Entering longer, multi-line responses | Feedback; support requests |
Data inputs
These form controls allow users to provide information by choosing from predefined options or within a constrained range of values. Buckholt provides a variety of data input components, each designed for specific use cases, such as selecting one or multiple values, picking from a dropdown menu, or setting a value on a range. Use the most appropriate input type to support accurate and efficient data entry.
Selection controls
Selection controls present users with a set of predefined options. When choosing a component, consider how many options need to be shown and whether users can select one or multiple items. These factors will guide which control is most appropriate. Common selection controls include checkboxes, radio buttons, select lists and dropdowns, switches, and file uploaders.
Deciding what to use
|
Control
|
Usage
|
Context
|
|---|---|---|
| Response button | Select one or more options using visually styled button inputs | Choose options; answer questions |
| Checkbox | Select one or more options | Agree to terms; select multiple items; add extras |
| Radio | Choose a single option from a list | Choose plan type; select shipping method |
| Switch | Switch between two states | Enable settings; turn features on/off; show or hide |
| Select | Choose one option from a list | Job title; preferred contact method |
| Dropwdown | Choose one or more options from a list or type to find an option. | Country selector; Long lists |
Radio
- Preselect a default option when appropriate; selecting another will automatically deselect it.
- If a “no selection” state is valid, include an option labelled None.
Radio and checkboxes:
- Place labels to the right of their controls.
- Arrange items vertically for easier scanning.
Switches:
- Always label switches clearly; don’t rely on colour alone.
- Use for single on/off options.
- Ideal for instant updates without submission.
Select
- Use when presenting more than five options.
- Prefer over checkboxes or radio buttons for long lists.
Dropdown
- Use when presenting a long list of options.
- Allows multiselect and type-ahead.
Bound entry controls
Bound entry controls allow users to input numeric or time-based data, such as dates, times, or quantities, using components like number inputs, date pickers, and sliders. These controls limit input to valid values only, reducing the need for manual validation. They typically support both keyboard and mouse interactions, offering a balance between precision and ease of use.
Date – coming soon
Deciding what to use
|
Control
|
Usage
|
Context
|
|---|---|---|
| Number input | To increase or decrease incremental values | Quantities |
| Slider | To select one number from a numerical range | Percentages, volume, timelines, data visualization |
| Date picker | To input/select a single localized date or a date range from a calendar | Selecting due dates, policy updates. |
Assistive / helper text
Assistive text sits directly below the input label and provides brief, contextual support that complements the label, such as offering a short explanation of what’s being asked. It helps set expectations before the user interacts with the input.
Helper text appears below the label and helps users enter the correct information. It’s always visible, making it ideal for essential guidance. Use placeholder text or tooltips for optional or contextual information.
- Do
- Treat helper text as essential, secondary information that supports the label.
- Keep it short, specific, and easy to scan.
- Use only when necessary to avoid cognitive overload.
- Don’t
- Don’t use helper text as a replacement for field labels.
- Avoid helper text that’s longer than the input width.
Placeholder text
Placeholder text offers hints or examples of what to enter (e.g. ddmmyyy). It disappears once the user starts typing, so it should never contain essential or required information. Use placeholder text when the expected format might be unfamiliar or needs clarification.
- Don’t
- Use placeholder text to convey complex instructions (e.g. password rules), use an infotip instead.
- Include placeholder text when it adds no value.
- Replace field labels with placeholder text, labels are always required.
- Don’t
- Use placeholder text to convey complex instructions (e.g. password rules), use an infotip instead.
- Include placeholder text when it adds no value.
- Replace field labels with placeholder text, labels are always required.
Default values
Default values can be set for any input type. Use them when a common or expected value is known, to reduce user effort. Defaults should not cause errors if left unchanged.
- Examples
- Pre-select the user’s country in a “Country” dropdown based on location.
- Pre-fill known values, such as company name or current date.
- Set typical or minimum values for quotas, limits, or numeric inputs.
Buttons
Use a primary button for the main action (e.g. Submit), and a ghost button for opposite actions (e.g. Cancel or Discard).
Button alignment
Button alignment (left or right) depends on the form type. By default buttons appear on the left. More details are provided in the form layout guidance below.
Button emphasis
Button emphasis refers to the placement of the primary button in relation to secondary and ghost buttons. When multiple buttons are used in a form, their positioning should follow the button set guidance. The appropriate placement of the primary action depends on factors like the page layout, form type, and overall alignment.
For in-page forms and most standard layouts that don’t follow right-aligned patterns, the primary button should be left-aligned and placed before any secondary or ghost buttons.
In contrast, within progressive forms, wizards, or structured containers like modals and side panels, the primary button should be right-aligned, appearing after the secondary or ghost buttons.
Avoid top-aligned buttons
Avoid placing form buttons at the top of a dedicated-page form. While this trend has emerged, it introduces several usability issues:
1. Forms should guide users through necessary inputs.
We should only ask for essential information and present it in a clear, concise manner. It’s reasonable to assume users will scroll through the form before reaching a point of submission. Placing the submit button at the top interrupts this natural flow.
2. Dedicated-page forms do not trap the user in a workflow.
Unlike modals, dedicated-page forms allow users to navigate freely. A back link is usually provided via breadcrumbs or a progress indicator if the form is part of a multistep flow. The browser’s back button is also available. Therefore, “Back” should not be a secondary action, secondary actions are typically used for cancelling a task.
3. Top-aligned buttons create a poor experience at the point of completion.
When users finish filling out a form, having to scroll back to the top to submit it creates an awkward and inefficient interaction. If persistent action buttons are needed, consider using a pinned footer or tray to house the button group instead.
Do arrange primary and secondary actions at the bottom of the form.
Do not top align primary and secondary actions in your layouts.
Naming actions
Avoid vague terms like “Submit,” which can make the form feel generic or impersonal. While button labels should be brief, they should also clearly communicate the result of the action. Use verbs that describe what will happen next, for example, “Send message,” “Create account,” or “Save changes.” This helps users feel more confident about what they’re doing.
Do use task-specific language in your buttons.
Do not use vague language to describe an action.
Validation
Clear and timely error messages help users understand what went wrong and how to fix it. Start by explaining the issue, then offer actionable guidance to resolve it. Always display error states within the form itself, prefer inline errors whenever possible to ensure issues are visible and contextual.
Client-side validation
Validating input data before a form is submitted improves usability and prevents avoidable errors. This type of real-time validation, also known as client-side or inline validation, should be triggered when a field loses focus (on blur). This allows users to identify and correct issues as they go, without waiting until submission.
Validation messages should clearly describe the issue and what needs to be done to resolve it. For example, if a password must contain at least 16 characters, and the user only enters six, the message should read: “Password must be at least 16 characters.”
- Typical client-side validation errors include:
- Improperly formatted input
- Mandatory fields left blank
- Partially completed mandatory fields
Server-side validation
Server-side validation occurs when a user submits a form and the system processes the data before returning any errors. These errors are typically identified after submission and may trigger a page refresh or a message returned from the server.
In these cases, use an alert notification positioned above the form actions to communicate that errors have occurred, and pair it with inline error messages that point to the specific fields needing attention. This dual approach ensures users are informed at both a summary and field level, making it easier to identify and resolve issues.
Inline error messages should automatically clear once the user has met the correction criteria for the field.
Enabling and disabling buttons
- For short forms that rely on server-side validation, disable the primary action button until all required fields are completed correctly.
- For longer forms, avoid disabling the primary action button, error messages and the button itself may not be visible at the same time, making it harder for users to understand what went wrong.
- Once a user submits a form, disable the primary action button to prevent accidental resubmissions.
- If the form submission is likely to take time, provide clear feedback through progress indicators (such as spinners or progress bars) and messaging that sets the user’s expectations.
In-line editing
In-line editing allows users to modify form content directly where it appears, without navigating to a separate page. This improves efficiency by eliminating the need to reload or revisit the full form to make a simple change.
Designing for longer forms
Product designers often wonder how long a form should be, but there’s no universal answer. The right length depends on your users, their goals, and the context of your product. Instead of aiming for a specific number of inputs, focus on making the experience as efficient and purposeful as possible.
For longer forms, consider using design techniques that reduce friction and help users stay focused. The following strategies can help make complex forms feel more approachable and manageable.
Progressive disclosure
Progressive disclosure helps simplify the user experience by revealing additional content or inputs only when they become relevant, based on the user’s prior selection. This approach keeps forms focused and prevents users from feeling overwhelmed, allowing them to concentrate on the task at hand without unnecessary distractions.
Nested inputs
Nested inputs are a specific application of progressive disclosure. These are additional inputs that appear directly in response to a user’s answer to a parent input. They are contextually dependent and should only be shown when the user’s response makes them relevant.
Because nested inputs are directly related to the parent input, they should be positioned immediately after it and clearly grouped, visually and semantically. For example, selecting “Yes” to a question like “Do you have another vehicle?” might reveal a nested group of fields asking for make, model, and year.
Use nested inputs to keep the form streamlined and conversational, while still collecting the detail needed. Avoid deeply nested chains, limiting to one level of nesting helps maintain clarity and usability.
Accordion forms
Accordion forms enable users to expand and collapse sections of related content within a single form. Similar to progressive disclosure, they help reduce visual clutter and allow users to focus only on the relevant information, without needing to switch between screens or pages.
As a best practice, don’t use accordion forms in modals layouts.
Research shows that accordion forms can significantly improve form completion time and overall page performance. However, findings also indicate that users may become confused about how primary action buttons behave, particularly whether they apply to individual sections or the form as a whole.
Multistep forms
Multistep forms divide input fields across multiple screens and include a progress stepper to show a user’s position within the flow. Each step should group related fields logically, and the overall structure should follow a clear, linear progression.
This format is particularly useful when saving progress throughout the form journey. It also allows users to navigate back to earlier steps to review or amend their entries without losing their place.
Form headings
A form heading should clearly describe the purpose of the form and use the largest type size in the hierarchy of the form. When the form appears within a container or modal, use a smaller heading style such as the $headline-01 token. For standalone forms that occupy the entire page, opt for a larger type size to establish visual prominence.
You can optionally include a short description below the heading to provide additional context or guidance.
Group and section headings
Group or section headings are used to label related sets of form controls and fields, helping users make sense of what is required in a clear, structured way. Headings should be concise and clearly describe the content they introduce.
The heading’s type size should sit between that of the overall form heading and the field labels, large enough to stand out from the form controls, but subordinate to the main form heading. When needed, include a brief description below the heading to clarify the purpose of the section or offer additional guidance.
Spacing
Clear, consistent spacing helps users scan and complete forms with ease. Inputs placed too closely together can cause confusion, so use margins, gutters, spacers, and alignment conventions to maintain clarity.
Form context
The layout and spacing of a form are influenced by where it appears, whether on a dedicated page or within a container such as a modal, side panel, or card. In general, dedicated-page forms can support more complexity and offer greater flexibility in spacing.
Individual form fields typically default to 44px / 2.75rem in height across products. For dedicated-page forms, we recommend using a 32px / 2rem vertical spacer between input fields. In more compact, contained forms (such as modals or side panels), this spacing can be reduced to 24px / 1.5rem depending on the available space.
Separating inputs, actions, and sections
Vertical spacing between grouped sections should relate to the spacing between individual inputs. For example:
- If the spacing between single fields is 24px / 1.5rem, use 48px / 3rem between groupings.
- If individual field spacing is 32px / 2rem, increase group spacing to 64px / 4rem.
As a general rule of thumb, place 64px / 4rem space between the final form input and the primary action button or button set. This may be adjusted for mobile layouts or more compact container forms.
Rules
Dividers, or rules <hr>, are often used by designers to separate groups of related information within forms. While this can help with visual clarity and reinforce hierarchy, Buckholt currently does not offer consolidated guidance on rule styling, such as width, thickness, or vertical spacing.
Until formal guidance is available, we recommend using rules sparingly and consistently. Consider the surrounding spacing and context to ensure that dividers support, rather than interrupt, the overall flow of the form. More detailed usage recommendations will be provided in future updates.
Variants
Forms can appear as full pages, in side panels, or in modals, depending on the task and context. Choose the format that best suits the complexity of the form and the user’s workflow.
Deciding what to use
|
Variant
|
Usage
|
context
|
|---|---|---|
| Page | Used for complex or multistep input tasks | Creating a new service; completing data capture forms |
| Modal | For important, occasional inputs related to editing or management | Updating user permissions; upgrading a service |
| Side panel | Ideal for recurring tasks where users need to reference surrounding content | Editing row data in a table; adjusting settings in context |
- Modal forms
- Best suited for forms with fewer than five inputs.
- Avoid hiding fields in accordions or tabs.
- A dedicated modal pattern with further guidance will be published soon.
- Side panel forms
- Recommended for forms with more than five inputs.
- Do not place inputs inside accordions or tabs.