01 Focus

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, especially when users use the keyboard to move through the form fields.

The choice of colors for the focus state is very limited. It is blue or purple. All other colors may look inappropriate and strange.

Usually, the focus state is indicated by a border or focus ring for all design elements with keyboard interactions.

02 Hover

The hover state is not necessary for input fields. Moreover, it is rather an annoying effect for the user. Many people will automatically hover over a form before they start filling it in, and the input hover effect only frustrates them with its unreasonable attention.

When hovering over the label text of checkboxes and radios, changing the cursor from default to the pointer is good. This gives an understanding that the label is clickable.

Unlike other interfaces on the web, it is expected that if something is clickable, then the cursor changes its appearance to the pointer.

03 Error

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.

The length of the error message can be anything. There is no point in trying to make it shorter. On the contrary, the user should read the full description and understand everything than guess what the form wants.

It is best to make the text in the input field red if it contains an error. This helps make everything more consistent and clear.

04 Error 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 or background without additional explanations.

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

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

05 Success

Usually, there is no need to state the success of the form field. It is evident to the user that the input is filled in.

But in complex and large forms, you can use the success state to show the progress of the form. This would be a great feedback and helper for users.

The same applies to input fields with complex data. Where a specific set of characters is required, as, say, when entering a card number.

In that case, it's not a bad thing to show a success state right away.

Generally, guiding users and motivating them with small wins enabling on success state for input fields they have already passed, is better. This makes it easier to fill out the form and create a gamification.

06 Disabled

Disabled state in input fields is a weak design decision. It means that the designer failed to plan the form to make it usable, understandable, and logical.

In fact, disabled states are never needed and should never be in the form. If something in the form should be available to be filled in after certain actions, hide it and show when it is needed.

Input fields with disabled states always cause questions from the user, and usually, he never understands why this field is not available for input. So this form is like a quest, where user has to solve riddles to unlock fields.

Disabled checkboxes and radios are as incomprehensible as normal state input fields. Why aren't they clickable? Or is the form broken? What do I have to do to turn them on? And do I have to do anything at all?