Form Interface Recommendations

Designing forms can be a real challenge. To get something worthwhile and convenient for users, you need to take into account a bunch of different recommendations and rules. In this article I tried to make a useful list of such recommendations. To compile it, I used my experience and expert articles.

Key recommendations and data entry

• Strive for brevity.
• Make sure that one language is used in the form (turnovers, terms).
• If there is only a form on the page and nothing but it, then when loading the page it is worth putting focus on the first field of the form, this will save a little time (search, login, registration page).
• Maintain a clear way to fill out the form.
• Avoid secondary actions if possible.
• Otherwise, clearly separate the main and additional actions.
• Align the main action as well as the fields of the form, this simplifies the perception of the form.
• The colored background at the main button will make it more visible.
• Disable the "Send" button after the user clicked on it, this will avoid double data sending.
• Better yet, show the send indicator.

Grouping, tabs and multi-page forms

• Place similar fields nearby.
• Group the fields so that the user has to switch the layout smaller.
• Use the appropriate field grouping to organize the contents of the form.
• Use the minimum number of visual elements needed to highlight the form.
• If the form can be easily broken into several short forms, then use one page for it.
• If the form contains a large number of questions related to several topics - use several pages.
• If the form contains a large number of questions on one topic, use a long page.
• For wizards, provide the ability to return to the previous steps.
• In the wizards, avoid nested steps, make them consistent.

Fields

• Assess the appropriateness of having each field.
• Look for opportunities to remove unnecessary fields.
• Do not complicate some fields in order to delete others.
• If it is possible to enter data in more than one way, use flexible input, for example, when entering a phone number.
• Providing flexible input does not make filling simple fields more difficult.
• Use input masks to enter specific data, such as dates.
• Input masks can shorten the time required to fill out a field. some characters will already be entered.
• If only characters of a certain type are expected, then make sure that the user knows about it.
• If you enter the wrong character - noticeably, but not intrusively notify the user.
• Ensure that the default values ​​are consistent with the user's goals.
• Personalized defaults allow returning users to fill out the form faster, for example, remember the email in the comment input form.
• Remember to fill out the form using the keyboard and tab.
• Use tabindex to control the operation of the tab.
• Provide a logical order of filling in the fields when designing forms.
• If the form will be used to manage a large amount of data, then the fields must be turned off by auto-completion, otherwise over time all possible values ​​will be stored this way.
• Fields that are not editable and their fields should look appropriate.

Signatures

• The signature for the field should be placed to the left of the field, or on top (which is preferable), because:
  
  • The signature can be long enough, and if it did not fit on one line while on the left, then it can fit on top.
  • Good for internationalization, in another language the signature may be longer, and will not fit on the left.
  • An empty space appears on the right, which is well suited for clarification or validation.
  
  
• Avoid multi-line field signatures.
• Signatures should clearly reflect expected data.
• Try not to put optional fields on the form, maybe they should not be filled out at all by the user.
• If most of the fields are required - select optional.
• If most fields are optional, select required.
• It is better to highlight required fields with text, but * or font / color highlighting is also suitable.
• The name of the form should correspond to the tasks of the form.
• Minimize the hints and tips you need to fill out the form.
• Help should be contextual - located near the desired field and be useful.
• When requesting a lot of data unfamiliar to the user, use a dynamic help system, tooltips, for example.
• Use alignment and grouping to show how data is related.

Validation and hints

• Highlight the errors that occurred - show them in front of the form and in each field.
• Provide effective ways to correct errors.
• Duplicate error messages visually.
• Provide a clear understanding that the data was sent correctly.
• Use instant validation for fields with a potentially high percentage of errors.
• Report field restrictions.
• If possible, do not limit the length of the field.
• Otherwise, make sure that the data is placed in the field.

Checkbox and radio button recommendations

• The checkbox and radio button are always located to the left of the signature.
• Custom design elements should be as close as possible to the standard representation.
• Arrange lists vertically, with one option per line.
• If several flags or radio buttons are located under each other, then there should be the same distance between them.
• If you need to use them horizontally, with several options on a line, make enough space between them with an element and a signature, clearly highlighting which inscription refers to. .
• Use positive wording for the signatures of checkboxes, so that it is clear what will happen when the user selects it.
• Write signatures so that users can understand what will happen if they choose it, and what will happen if they leave it blank.
• If you can’t do this, then it’s better to make two radio buttons, one to enable the feature, and the second to disable, and write clear signatures for each case.
• If possible, use the radio buttons instead of short drop-down lists.
• Always set the default option for all lists of radio buttons.
• Since the radio buttons allow you to select only one option, make sure that both options do not contradict each other, clearly differ from each other.
• Make sure that the radio buttons completely cover the required data area, if not, add the option “other” and a text field to enter your option. This also applies to dropdown lists.
• Allow users to select the option by clicking not only on the checkbox / button, but also on their signature: it is easier to click on a large target, in accordance with Fitts' law. In HTML forms, you can easily achieve this by simply surrounding each label with a label tag.
• Use the checkboxes and radio buttons only to change the state, and not as an action button or submit a form.

Drop down lists

• If there are more than 2-3 options in the list, then they should be sorted alphabetically, this will speed up the search for the desired item.
• If the “Other” option is intended, then it should be at the end.
• If there are a lot of options, but they are divided into groups according to their meaning, then this is worth doing.
• If the list is long, but there is a group of the most popular values ​​(about 5-7 pieces), you can drag them up the list.
• If the list is sooo long, then you need to use autocomplete.
• If the drop-down list contains only yes / no options, then replace it with a check box.
• If the number of values ​​in the drop-down list is always constant, and it is less than 4-5, then such a list is expanded into a horizontal group of radio buttons.

Recommendations for the Cancel and Clear buttons

• The button “Cancel” in good interfaces is not required at all, because other navigation mechanisms are used - the back button in the browser, breadcrumbs and menus.
• It is advisable to replace the cancel button with a link, emphasizing its secondary importance.
• The clear button is also worth making a link. Place it cost only in the right places for this, for example in filters and searches.
• The biggest problem is that users often mistakenly click the Reset button instead of the Submit button. One click - and all the painstaking work disappeared.
• The presence of two buttons at the end of the form introduces confusion into the interface, and it is difficult for the user to clearly determine their next step. Some time is wasted in looking at this useless button to figure out which of the two buttons to press.
• Even if the user really wants to delete some of the data that he entered into the form, the presence of a dedicated button to perform this function can only slow down his work, as there are two choices before:
  
  • edit fields containing incorrect data, replacing the old text with the new one.
  • press the Reset button and type new text into all the virgin form fields.
  
  
• Additional choices only require additional mental effort, and when working with an optimally configured interface, more time will be saved than lost on additional consideration of actions where you just need to proceed to the next stage. It takes at least one to two seconds to choose one of the two options, so it’s best not to put the user at all before this choice. A second may seem like a drop, but this drop results in 100 millionth losses from a decrease in productivity on a yearly basis for the entire planet.

In preparation, the following materials were used:

• Alertbox by Jacob Nielsen.
• A bunch of topics from ux.stackexchange.com.
• Articles from SmashingMagazine
• Business Lynch.
• Tips from artgorbunov.ru.