As we’ve discussed already, interaction means anything that allows the user to communicate to the computer. Often, this refers to simple controls like links, buttons, or scrollbars that allow the user to tell the computer what action they wish to take (like visiting a new page, opening a dialog, or scrolling down to see more content). But sometimes it’s necessary for users to communicate information that is more dense and more structured. For these cases, we use forms.
Forms are special kinds of interactions for gathering specific structured information from a user.
Forms are very common on the web, in mobile apps, and in desktop software. You might think of a payment form on an e-commerce site, or a contact form for sending a message, or a signup form for creating a new account. But you might be surprised about some of the places we use forms without really thinking of them as forms. The interface you use to write and send an email—that’s a form. The fields you fill in when posting to a social media feed—also a form. The bar where you write and send a text message on your phone—yep, also a form.
Fields and Labels
Forms are made up of fields into which the user inputs a specific piece of requested information. For instance, a login form usually has three fields: one for a username, one for a password, and a button to submit the login attempt. By adding different fields, a form can be made to gather any kind or amount of information.
Every field should be accompanied by a label to indicate what information the user should enter. It’s incredibly important that labels should be clear, consistent, and readable. Otherwise, the user would have no idea what you are asking of them. And missing or unclear labels can be even worse for non-sighted users who are experiencing the form through a screen-reader. The effect can be quite disorienting!
While it’s common to see forms that user placeholder text inside of the form fields instead of labels outside of the fields, this is actually pretty bad for usability.
To understand why, consider that when the user clicks in a field with only a placeholder as the label, the label disappears, so the user has no way to double-check their work. Additionally, placeholder text is usually not read aloud by screen-readers, so non-sighted users get no information about what they are expected to put in any field labeled this way.
Tips for Designing Forms
Forms are used for many different purposes in many different contexts, but here are some general guidelines for designing relatively standard forms:
- Because users can easily get lost or become overwhelmed when filling in forms (just think of doing your taxes!), it’s a good idea to keep the layout as simple as possible so there is no confusion or getting lost. In general, this means most forms should be a single column, top-to-bottom, with no fancy formatting.
- Another way to help users avoid feeling overwhelmed is to break up the form into small sub-sections. You can add headings for the sections, or you can simply break them up with a bit of extra vertical space. (Remember, because of the Law of Proximity, the user will perceive fields that are relatively close together as groups, while fields that are separated by extra space will be perceived as more separate.) This is especially important when forms are longer than just a few fields.
- Use the size of a field to indicate how much input is expected from the user. For instance, if you are looking for a two-letter state abbreviation, only make the field wide enough for two letters to fit comfortably. This helps the user to quickly understand what to do.
- Labels should be closest to the field to which they refer. Remember the Law of Proximity.
Standard Field Types
There are many different kinds of form fields, from the standard single-line text input to fancy things like file pickers. It’s important to provide the right kind of form field based on the kind of information being gathered and other related considerations.
Here are the standard field types that are commonly used across most operating systems and the web.
The single-line text field accepts any text: letters, numbers, or other characters.
Because it is a single line field, it affords a limited amount of input. The length of the field may further indicate to the user how much content is expected.
The field imposes no limitation or validation of what the user may input.
The email address field looks and behaves nearly identical to the text input; however, it validates the input and will give an error if the submission doesn't seem to be a valid email address. (Typically, it looks for the presence of an @ symbol.)
On touch-screen devices, the field calls up an on-screen keyboard that includes the @ symbol.
The number field only accepts numeric input. In most browsers and other formats, it shows increment arrows on the right side when hovered or focussed.
The number field can be set to accept certain increment sizes, such (10, 20, 30 or 5, 10, 15, 20), but there is no limit on the range of numbers accepted.
On touch-screen devices, this field calls up an on-screen number-pad keyboard.
Like the text field, the password field accepts any characters as input, but dots or stars are usually used to obfuscate (visually hide) the input to protect the security of the user.
The search input is functionally the same as the text input, but after something has been typed an "x" icon appears to allow the user to clear out the field.
This field accepts numbers, dashes, and parenthesis, and has validation that looks to see if the input has the correct number of digits to be a
On touch-screen devices, this field calls up an on-screen dial-pad keyboard.
The URL field validates the input to look for the presence of "http:" or "https:" to indicate the presence of a URL
On some touch-screen devices, the field calls up an on-screen keyboard that includes a ".com" key.
Multi-Line Text Area
The multi-line text input field accepts any text input and allows many lines of input and keyboard-returns for line breaks. In most browsers, an internal scrollbar appears if the input is too long for the visible area. Some browsers allow the user to resize these fields.
This field is a good candidate for longer input without restriction.
By default, the select field is in a closed state where the options cannot be seen. When toggled open, it a list of options for the user to choose between. The user is limited to a single choice.
The select field is a good choice when the user must select between mutually-exclusive options and the list isn't especially long. Because the options aren't visible when the select is closed, it isn't the best choice when the options are important or need absolute clarity.
Select Dropdown with Grouped Options
This is the same as the select field above, except the options in the dropdown are organized into groups under headings.
The multi-select is similar to a normal select, but the user can select as many options as desired, and the choices aren't hidden behind a dropdown.
To select more than one option, the user must hold shift while click on options. Because this behavior is less obvious, this field type is often avoided.
The auto-complete field looks like a normal text field, but it is associated with a list of options. As the user types, the field suggests matching options. The user is also able to type in a completely custom value.
This is a good choice for inputs where there is an especially large number of options, so the user doesn't have to scroll to find the desired value.
A checkbox is essentially a binary input: it is either checked or it isn't. For this reason, it is often used for situations where the user must indicate a yes or no value, such as opting in to notifications or acknowleding agreement.
Checkboxes are often grouped, which allows many options to be selected. This is good for situations where a user might want to indicate multiple choices or preferences.
Radio buttons are associated with a series of mutually-exclusive options; the user may only select one. Unlike the select field, all of the options are shown on the page without the need to toggle open a dropdown.
Radio buttons are good for situations in which users must choose one of several options and those options need to be more easily readable than a selct field allows.
The purpose of a button is to trigger an action. Actions may include, submitting a form, saving work, canceling an action, or triggering an interaction.
The range slider field allows the user to select a value along a spectrum of values with a minimum and a maximum allowed value.
The allowed values along the range can be restricted to increments if desired.
This field is a good choice for sutuations where there is a linear spectrum of choices between a min and a max value.
Date, Time, and Date/Time
Date, time, and date/time fields allow the user to choose a point in time. Most browsers offer built-in UI for making the selection, but the specifics can vary significantly.
The color picker field allows the user to choose a specific color value. Most browsers offer built-in UI for this field, but the specifics can vary significantly.
The file uploader field allows the user to select a local file for upload when the form is submitted. Usually, this takes the form of a file selection button and the name of the file queued to upload, if any.
These fields can be set to restrict what type of file they will accept or a maximum allowed file size.