Form Interface Recommendations

Designing forms can be a real problem. To get something worthwhile and user-friendly, 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.

Basic recommendations and data entry

• Aim for brevity.
• Make sure that the form uses one language (turnovers, terms).
• If there is only a form on the page and nothing but it, then when loading the page it is worthwhile to focus on the first field of the form, this will save some time (search page, login, registration).
• 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 form fields, it simplifies the perception of the form.
• The color underlay on the main button will make it more visible.
• Disable the "Send" button after the user has clicked on it, this will avoid double sending data.
• Better yet, show the send indicator.

Grouping, tabs and multipage forms

• Place similar fields nearby.
• Group the fields so that the user has to switch the smaller layout.
• Use the appropriate grouping of fields to organize the content of the form.
• Use the minimum number of visual elements necessary to highlight the shape.
• 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, ensure that you can return to the previous steps.
• In the wizards, avoid nested steps, make them consistent.

')

Fields

• Assess the feasibility of having each field.
• Look for opportunities to remove unwanted fields.
• Do not complicate some fields in order to remove others.
• If it is possible to enter data in more than one way - use flexible input, for example, when entering a phone number.
• Ensuring flexible input does not make filling simple fields harder.
• Use input masks to enter specific data, such as dates.
• Input masks can reduce the time it takes to fill a field, since 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.
• Make sure that the default values ​​match the user's goals.
• Personalized defaults allow returning users to fill out a form more quickly, for example, remember the email in the comment entry form.
• Remember to fill out the form using the keyboard and tab.
• Use tabindex to control tab operation.
• Provide a logical order for filling out fields when designing forms.
• If the form will be used to manage a large amount of data, then the fields need to disable autocomplete, otherwise all possible values ​​will be stored over time.
• Fields are not editable and their fields should look accordingly.

Signatures

• The caption to the field should be placed to the left of the field, or above (which is preferable), because:
  
  • The signature can be quite long, and if it does not fit in one line from the left, 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 explanations or for validation.
  
  
• Avoid multiline field captions.
• Signatures must clearly reflect the expected data.
• Try not to put optional fields on the form, maybe you should not fill them in at all.
• If most fields are required - select the optional.
• If the majority of the fields are optional, select the required ones.
• It is better to select required fields with text, but * or font / color selection is also appropriate.
• The name of the form should correspond to the tasks of the form.
• Minimize the tips and tricks needed to fill out the form.
• Help must be contextual - located near the desired field and be useful.
• When requesting a lot of unfamiliar data for the user - use the dynamic help system, tooltips, for example.
• Use alignment and grouping to show how the data is related.

Recommendations for validation and hints

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

Recommendations for checkboxes and radio buttons

• 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 view.
• Place the lists vertically, with one option per line.
• If several checkboxes or radio buttons are located under each other, then there must be the same distance between them.
• If you need to use them horizontally, with several options on the line, make enough space between the element and the signature, clearly highlighting which inscription refers to where. .
• Use positive wording for the checkbox signatures, 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 empty.
• If you can’t do that, it’s best to do two radio buttons, one to turn on the feature and the other to turn it off, and write clear signatures for each case.
• If possible, use radio buttons instead of short drop-down lists.
• Always set the default option for all radio button lists.
• Since the radio buttons allow you to select only one option, make sure that both options do not contradict each other, they are clearly different from each other.
• Make sure the radio buttons completely cover the required data area, if not, add the “other” option and a text field to enter your version. This also applies to drop-down lists.
• Allow users to select an 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 the Fitts law. In HTML forms, you can easily achieve this by simply surrounding each label with a label.
• Use checkboxes and radio buttons only to change state, and not as an action or form submit button.

Drop down lists

• If the options in the list are more than 2-3, then they should be sorted alphabetically, this will speed up the search for the desired item.
• If the option “Other” is supposed, then it should be at the end.
• If there are a lot of options, but they are divided into groups by meaning, then it 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 autocompet.
• If in the drop-down list only yes / no options, then replace it with a checkbox.
• If the number of values ​​in the drop-down list is always constant, and it is less than 4-5, then such a list expands into a horizontal group of radio buttons.

Recommendations for the "Cancel" and "Clear" buttons

• The Cancel button in good interfaces is not required at all, since other navigation mechanisms are used - the back button in the browser, breadcrumbs and the menu.
• It is desirable to replace the cancel button with a link, emphasizing its secondary importance.
• The clear button is also worth making a link. To place it cost only in the right places for this, for example in filters and searches.
• The main problem is that users often mistakenly press the Reset button instead of the Submit button. One click - and all the hard work disappeared.
• The presence of two buttons at the end of the form brings confusion to the interface, and it is difficult for the user to clearly define his next step. Some time in vain is spent on examining this useless button to figure out which of the two buttons you have to press.
• Even if the user really wants to delete some data that he entered into the form, having a dedicated button to perform this function can only slow down his work, since there are two options before:
  
  • edit the fields containing invalid data, replacing the old text with a new one.
  • press the Reset button and type new text in all pristine form fields.
  
  
• Additional choices only require additional mental effort, and working with the optimally configured interface will save more time than is lost on additional thinking about actions where you just need to go to the next stage. The choice of one of the two options takes at least one or two seconds, so it is better not to put the user in front of this choice at all. A second may seem like a drop, but this drop translates into 100 million losses from a decrease in performance on a year-wide scale for the entire planet.

In preparing the materials used:

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