Web Interface  |  Inputs


This section is about how to deal with form field states and error messages.

01Focus state

Feedback in the interface is always a good idea. The user needs to understand what's going on now at any given time. It's good to make the inputs have a focus state. It helps to navigate the form and the current action.

The cursor is in the input but there is no focus state.
The state of focus shows what is now happening on the screen.

02Error message

A good error message must not only explain what the problem is but also tell the solution. The user should always understand what's going on and how to fix it in the fastest possible way. So you reduce the likelihood that he will stop and refuse to fill out the form.

There is no explanation of what went wrong and how to fix it.
The error message shows what is entered incorrectly and how to fix it.

03Error state of checkboxes & radios

The rule for single checkboxes is slightly different than other inputs. The checkbox label contains a description of the expected data, so if a checkbox is not selected, this can be indicated by a red border without additional explanations.

It's obvious from the label itself what the problem is.

Showing an error message can be useful in the checkboxes group, especially if it explains why these are required fields.

An explanation of the error can be useful in the checkboxes group.

Radios do not require error messages because they should always have a default choice.

Error messages are meaningless for radios.

04Disabled state

The text on the radio or checkbox label should also be disabled if the input is disabled. If the label does not have reduced transparency, it becomes unobvious that the input field is disabled.

The disabled state is unobvious.
Definitely inputs have a disabled state.