Design a better form

For desktop & mobile screens

Generic form example on Chrome browser

I’m not going to lie, it sucks to fill out a form.

Once, I got an offer in the mail to apply for a discounted car insurance quote. Semi-annually, I feel financially gutted when paying for car insurance, so I thought it was at least worth checking out. I mean c’mon, they said there was a ‘discount’.

I already knew what it would take to see this ‘discount’…a ~FORM~.

I went to the insurance company website on my laptop, and filled out an extensive multi-step form since they have to see my possible liabilities as a driver. After answering the necessary details in a few sittings (& adamantly saving my work as a draft), I submitted my form to get my ‘discounted’ car insurance quote.

Even with the ‘discount’, it was more expensive than my current car insurance payments 🥲. I fell for a marketing scheme, and gave them all the needed information (that was semi-correct at best) for nothing! Adding salt to my wounds, I had to unsubscribe from a few marketing emails the insurance company added me to after this incident.

Though I didn’t pursue this ‘discounted’ insurance quote, the UX of the form did make me think about what goes into designing a form, and if it’s possible to alleviate user issues, mistakes, and despair while filling out the form.

I‘m not going to lie, it sucks to design a form.

They range in complexity, context, and audiences. Every form’s needs are different, which means the design of every form needs careful consideration to give its users an easy path to completion (while keeping the user’s despair at low levels).

Almost every answer to a form’s design needs is “it depends”.

It depends on the screen size, the length of the form, or what the user is even trying to do. It all depends.

To take some form-designing “it depends” despair away, I have compiled a list of comprehensive tips for form design from user testing as well as tried and true resources.

So let’s build a better form.

Form type terms

Before I get going with the tips, I want to clarify terms on form types I’ll be using throughout the tips.

• Simple form: Includes one to a few related user inputs. All user inputs are shown on one page or tile, which typically fits ‘above the fold’ on desktop devices, and is completed in one sitting. An example is a sign-in page for a website.

Short form, sign-in process for Amazon

• Long form (complex form): Includes many user inputs that must be divided into two or more related sections. All user inputs are shown on one page, with scrolling required to view all inputs, and it can need more than one sitting to complete. An example is a purchase checkout process.

Long form, purchase checkout process for Barnes & Noble

• Multi-step form (complex form): Includes many user inputs that must be divided into two or more sections. Each section is shown on its own page, and distinguished as a ‘step’. It can need more than one sitting to complete. An example is getting a car insurance quote.

Multi-step form, car insurance quote process for Geico

Form layout

• On desktop devices, place the form in a container with a non-distracting color such as white (#FFFFFF).
• On mobile devices, place the form on a non-distracting application background color. White (#FFFFFF) is also not bad here.
• On desktop devices, if the container of the form is not full-width of the screen, center-align the form container for all form types (simple, long, & multi-step forms).
• On mobile devices, let the form fill the allotted width of the screen, excluding the ~16px margins of the device’s sides.
• Left-align the components/elements within the form container for desktop and mobile devices, excluding the primary button.

Allow the user to focus in on the form while also providing an intuitive path to completion.

Suggested layout for desktop and mobile forms

Single-column

• Use a single vertical column for user inputs on a form, unless the inputs are directly related. ​
• Directly related inputs should be grouped horizontally due to their relationship and user expectation. E.g., ‘City, State, and Zip code’
• For mobile devices, directly-related inputs may need to be placed in a single column due to screen size.

This allows for easy scanning of the form, as well as provides a top-bottom approach for keyboard-only users who use the ‘tab’ key to scan screens.

Use a single column layout, excluding directly related inputs

Form presentation

On desktop devices, a form can be presented in three main ways:

1. Dedicated page: Use when the form is complex and/or long.
2. Modal/popup​: Use when implementing multi-step forms or more simple forms. Do not use a modal/popup if there is a possibility for another modal to appear above the modal containing the form.
3. Side panel: Use only when implementing simple forms that are frequently used by the user.

Form presentation types for desktop screens

No matter which form presentation suits your product needs, be consistent with the form presentation you select.

On mobile devices, the form should always be presented on a dedicated page or a bottom sheet due to the small screen size and larger touch targets required.

Form presentation types for mobile screens

Spacing

• In general, it is recommended to use spacing that is a multiple of 4px to fit within a typical screen’s grid.​
• On a desktop device, the form container’s margins should be 12px to 40px on all sides.
• Spacing between input fields should be 16px to 32px.
• Place a spacing of at least 40px between the last user input and the primary button to add visual distinction.
• The spacing between form sections should be larger than the spacing between input fields. So if the spacing between input fields is 16px, the spacing between sections should be at least 20px.

Suggested spacing for a form on desktop and mobile screens

Titles

• The form’s title​ (main header) should be the largest type size on the form, and should be placed at the top-left of the form container.
• The form section’s titles (sub-headers) should be smaller than the form’s title, but larger than the user input’s labels. These should be placed at the top-left of its corresponding section.
• For form titles and section titles, use short and concise language. If a longer title is needed, use a description below the title or section title.

Example type size hierarchy for a form

Buttons

Buttons, taken from Orbit design system

• Use one primary button for the user’s main action. E.g., submit the form.
• Use a secondary button for the user’s secondary tasks.​ E.g., save the form as a draft​​.
• Use tertiary or ghost buttons for minor actions. E.g., cancel the form​.
• Use action-specific language in the button’s text (‘Report incident’), and avoid generic terms (‘Submit’).

Button positioning

• For a button pairing: Right-align the primary button to the form container and left-align the secondary button either to the form container or the primary button.

Primary and secondary button placement

• For groups of three buttons: Right-align the primary button to the form container, and place the secondary button to the direct-left of the primary button. Then, left-align the tertiary button to the form container.

Button placement for three buttons

In testing, there was not significant user preference in button placement, but ensure the primary and secondary buttons are visually distinct from each other and place the buttons in consistent positions in the product’s forms.

Button behavior

• For simple/short forms, disable the primary button until the field requirements are met.​​

Disable the primary button until all required fields are completed for simple forms

• For long and multi-step (complex) forms, always have the primary button enabled to allow the user to make mistakes so they can be shown how to fix the issues.

Always have the primary button enabled on complex forms so users can see mistakes

• When a user submits a form, provide feedback that they took an action. This can include disabling the primary button or replacing the primary button’s text with a loader.

Provide feedback when a form will take awhile to process

• Do not top-align buttons in a form, even if the buttons are also placed at the bottom of the form.

Do not top-align buttons on a form

• Do not anchor the buttons to the page (FABs — floating action buttons).

Do not use FABs on a form

In testing, top-aligning the buttons as well as FABs made users think they finished all inputs before they reach the form’s end because the buttons were shown above the fold.​ They didn’t attempt to scroll to the form’s end before attempting to submit the form.

User input labels

• All user inputs must have a label present at all times, preferably top-aligned to the input field.
• Input labels should be succinct (about 1–3 words), and should have sentence-style capitalization.
• Do not place a colon after the input label.

Do’s and don’ts of user input labels

Required & optional

• All user inputs must be labelled as required or optional. Don’t make the user assume if an input is optional or required.
• For required inputs, an asterisk (*) is allowed, but provide a legend or instructions telling the user the asterisk meaning in the beginning of the form.
• For optional inputs, spell out the word ‘Optional’ next to the input label, but try to avoid optional fields in general.

Do’s and don’ts of required & optional indicators

User inputs

i. Freeform inputs​

Text fields

• Use to all the user to input individualistic responses. E.g., name or email address.
• The size of the text field should reflect the intended answer.
• Pre-populate known values or provide default answers, if possible.

Text field, taken from Orbit design system

ii. Selection control inputs

Radio buttons

• Use to select only one option from a list of five or less.
• It is recommended to group radio buttons in a vertical column for easy scanning. Only group radio buttons horizontally if there are 3 or less buttons and if vertical space is limited.
• Have a common default option pre-selected for the user.

Radio button group, made from Orbit design system

Checkboxes

• Use to select for a yes/no question (E.g., “Click to agree to terms and conditions”) or use to select two or more options from a list of five or less (E.g., “Select all that apply”).

Checkbox, taken from Orbit design system

Dropdown menus

• Use to select one or more options from a list of six or more.
• Dropdowns should not include an excessive amount of options. If an excessive list is needed, allow the user to search for their intended selection (use a combo-box).

Dropdown, made from Orbit design system

Toggles

• Use to select between two binary options. E.g., On/Off or Show/Hide.
• Users expect their toggle selection to update immediately, so use this input type cautiously.

Toggle, taken from Orbit design system

iii. Bounded-entry inputs​

Date picker

• Use to select a single date or date range from a calendar that appears after clicking on the input’s trigger.
• Provide helper text for how the date should be formatted, and allow the user to type in the date without using the embedded calendar.​

Date picker, made from Orbit design system

Slider

• Use to select a number from a predetermined range. This is best. used for percentages and data visualization.​

Slider, taken from Orbit design system

Input stepper

• Use to increase or decrease a value incrementally. This allows the user to click into the field and type their intended input.

Stepper, taken from Orbit design system

File drop

• Use to upload images or documents. E.g., a profile image or scanned card.
• Have limitations of the file type or size visible before the user tries to upload a document.

File drop, taken from Orbit design system

Help

Helper text​

• Use below the input field, such as a text field or dropdown menu. Helper text is always visible to the user and does not disappear when the user focuses in the on input field.
• Use helper text to tell the user crucial information that will aid the user, but keep it short and specific. Do not use helper text that is redundant to the input label.
• For developers, ensure helper text is announced to the user by using the attribute ‘aria-describedly’. If helper text is not coded properly, it may not be announced when the user is focused on the user input since the helper text is listed after the label and input field.

Helper text is always visible below the input field

Tooltips​

• Use for additional help or explanatory information that is less concise compared to helper text.
• Use when hovering or clicking on a ‘Help’ or ‘Information’ icon next to the input field or form section label.
• It is not recommended to place crucial information in a tooltips since it is not always visible on the screen. If it’s unavoidable, ensure the tooltip is accessible to keyboard-only users.

Tooltip that appear after clicking on an ‘information’ icon

Placeholder text​​

• Also known as ‘hint text’, this appears as default in a text field or dropdown when first opening a form, but disappears after the user clicks on or focuses on the input field.
• Placeholder text is not recommended to use due to its inaccessibility. Forms are more useable without placeholder text.
• If placeholder text is used, do not use it to show critical information, and use helper text instead.
• If placeholder text seems redundant or unnecessary, do not use it. For instance, if an input label says ‘Full name’, do not insert ‘Type your full name’ as placeholder text in the input field.

Text field with placeholder text that disappears after being focused on

​Be proactive by providing help for any input formatting requirements, atypical form fields, or reason why a form field is being requested.

Errors & validation

Common user errors to proactively design for:​

• Incorrectly formatting data (incorrect meaning in a way the server can’t read the data).
• Leaving a required field blank or incomplete.

Data formatting​

• Tell the user explicit instructions on expected data formatting.
• Restrict data entries with input-masking or allow submission of multiple data formats.
• Provide default values if the data input is something that would be a common response. E.g., have a country or company name pre-selected.

Data formatting examples

Inline validation​​

• Use to provide immediate feedback of user inputs as soon as the user input field loses focus. Best used in username and password creation scenarios.
• Allow the user to address any issue before submitting the entire form.
• Do not validate the input before the user has finished their response, and wait until the user has progressed to the next input in the form.

Inline validation for creating an app username

Error messages​

• If the user must submit the form to receive validation, provide clear indication of which user inputs have errors along with error messages.
• Good error messages are clear and concise, help the user understand the issue, and give steps on how to fix it.
• Do not use technical jargon or negative phrasing in error messages.
• Do not blame the user in the error message.

Error message examples

Though not all errors are preventable, be proactive by identifying areas where issues may arise and provide validation or additional help.

Feedback

Success messages​

• Use after the user successfully submits the form, which can be shown with a toast message or snack-bar component.
• Do not add a timer to automatically close the success message, and allow the user to see the success message and act on it.

Use a snack-bar component to show a success message to the user

Confirmation dialogs​​

• If the user has made any progress on a form and tries to cancel or navigate from the form, provide a confirmation dialog/pop-up that lets the user know the actions they are taking.
• Make the dialog/pop-up clear with distinct action buttons. E.g., “Changes are not saved. Are you sure you want to leave?”

Let the user know their work will not be saved if they navigate from the form

Progress indicators​​

• If the form takes more than a couple seconds to upload or is excessively long, provide a progress indicator to let the user know their form has been submitted or of their progress in the form.
• Use a loader or progress bar for this indication.

A progress bar on a multi-step form

Server-side error messages​

• If the server is temporarily down or unavailable and the user cannot submit the form, provide an error message saying the ‘Server is temporarily unavailable and to try again at another time.’
• Make sure to let the user know that the issue is not from their end since the user did not do anything to cause this message.

Provide a server-side error message before the user attempts the form

For each listed feedback scenario, use a consistent component type to display the message type across the product experience.​ E.g., if a snack-bar is used in one form’s success message, use a snack-bar in every form’s success message.

Desktop forms

Simple forms

• For simple forms, present the form on a pop-up or side panel to allow quick completion. (This excludes a login screen).

Simple form appearing on a pop-up

Complex forms

• For complex forms, present the form on a long form on a dedicated page, and provide clear form sections in a logical order.

Complex form appearing as a long form on a dedicated page

• Only use a multi-step form when a form is infrequently completed, if accuracy is more important over efficiency, or if the form is very long. E.g., applying for a mortgage.

Mortgage application for Rocket Mortgage

Mobile forms

Simple forms

• For simple forms, present it on a bottom sheet or dedicated page.

Simple form on a mobile screen

Complex forms

• For complex forms, present it on a multi-step form on a dedicated page.

Use a multi-step form for a complex form

• Only used a long form on a dedicated page if the user does not have reliable cell phone service or Wi-Fi. This prevents the user having slow lag time when loading multiple pages of a form.

No cell service or Wi-fi = bad form experience

Other mobile-specific items

• Show the expected user input keyboard when the user clicks the trigger. E.g., show the numeric keyboard when the user inserts their phone number.

Updating phone number on LinkedIn’s native app

• Use at least 16px (1rem) font size in text fields to avoid the screen automatically zooming into the text field when focused on.

Text field being zoomed into on Blundstone.com

• Provide mobile-friendly shortcuts, such as using a phone’s native features (camera, date picker, & location services).

Well, that was a lot. I hope even one tip can help.

Designing a form is not easy. I know saying “it depends” for what you should design for your user is frustrating, but it’s unfortunately a prominent answer when building a form.

Forms can be as simple as a one-question poll to when lunch works best or as complex as filling out a form for a car insurance quote.

Though falling victim to a marketing ploy by your local car insurance agency may be unavoidable (at least by me), implementing better practices into the product’s form is not.

Let’s try to make the process of getting a (tear-jerking) car insurance quote a little better by making the form easy to read, understandable, and less time-consuming.

But not only for me and other able-bodied users, but for all users. Especially ours users who use assistive technologies. It’s an obligation to make sure your forms are as functional as they can be 😉.

If I gotta fill out a form anyway, let’s make it a good form.