T21 fields marked with a sign are required. Required and optional fields when filling out forms. Podolsk and Moscow region

It would seem that there is nothing complicated in the design of input fields: draw empty rectangles for entering data, the user will do the rest himself. However, everything is not so simple. Judging by the length of the article, it is clear that there are quite a lot of rules and features. The user needs to be carefully “guided by the hand”, shown everything, explained and helped. Then and only then will we be able to get the desired data from him. Well, let's start!

7+ input field rules

The most basic rule, as everywhere else, is to put yourself in the place of the visitor. Is everything clear? Is it possible to understand at first glance what needs to be entered in the field? Does the field respond adequately to the information entered?

Write descriptions and tips

Hints and descriptions are needed to show what data needs to be entered, how to enter it correctly, and how the site will use this information in the future.

There are several types of hints:

1) Icons

Icons are a universal visual language. They help you understand what to enter even with a quick glance. And yes, icons are a design fetish =)

However, we should not forget that they always need to be explained.

2) Examples

The easiest way to tell how to fill out a field is to show an example. Sample example: " [email protected]»

3) Explanations

This type of description serves to explain how the site will use the data and what it is needed for. For example: “We need mail to notify you about the status of your order. We will not send spam."

Use masks

For fields that require data formatted in a specific way (for example, a bank card number or phone number), masks should be used. Thus, we shift the work of formatting information from the visitor’s shoulders to a soulless machine.

Here are some examples of different masks:

Highlight required fields

If among the optional fields there are fields that are required to be filled in, then they should be highlighted among others and emphasis should be placed on their mandatory completion. As a rule, required fields are indicated with an asterisk - *.

It is better to group all required fields together and place them at the beginning of the form.

By the way, the example above also shows 2 types of tips: examples and explanations.

Focus and keyboard

The active field in which the cursor is positioned must have a distinctive feature. As a rule, browsers independently highlight active fields. However, you should not leave everything to chance and check the functionality of this function yourself.

When the page loads, the first input field should automatically become active. As if inviting you to fill out the entire form. When filling out a form, it should be possible to switch between input fields without using the mouse. This usually happens by pressing the Tab button.

When using hints with auto-completion (for example, in a search), it should be possible to select an item using arrows and confirm it by pressing the Enter key.

When entering secret data (for example, a password), it should be possible to hide and show this data at the user's request.

Use the data already entered

Input fields need to remember things that ordinary people forget. It is rude to ask for the same information twice. If you once subscribed to the site’s mailing list, then when registering, the site should remember you and enter your email in the appropriate field.

Group input fields

For ease of filling out, it is better to group similar fields together. For example, fields for entering personal information (first name, last name, email) are one block, fields with a delivery address are another block.

Be aware of the field size

The field size in most cases serves to estimate the amount of data that is required from the user. Those. where you need to enter a long address, the field is large. So where a 6-digit index is needed, the field is small.

Finally

The design of input fields is not as simple as it seems at first glance. You need to remember many nuances and constantly ask yourself the question: “will everything be clear to the user?”

Many meticulous guys will say that there weren’t 7 rules at all (and some didn’t even notice, ha ha ha). However, many of the rules are small, so I counted them as half. And in general, I just like the number 7 =)

Maximum information in a minimum of words.

The way fields are labeled greatly influences how users perceive the form and how they complete it.

From a psychological point of view, everything is quite simple: pointing out positive aspects is better, because when making a decision the user believes he has a choice.

On the other hand, if you specify required fields, the user will feel trapped, limited, and uncomfortable.

Mark optional fields, not the other way around

Most designers use asterisks to indicate required fields. But you need to stop doing this. Research on this issue clearly indicates that using asterisks for required fields is a common mistake.

It is better to mark optional fields rather than required fields because:

The asterisk is obvious to you and not to everyone, believe me, there are always those who don't understand
There are always more required fields than optional ones
The less visual noise your form has, the more readable it is, and therefore faster to fill out.

Not required vs Optional

If you write a text in English, then remember that in all cases negatives are less clear. Therefore, use the word “Optional” instead of “Not required” to describe optional fields.

Don't ask users to provide useless information. If you have too many extra (non-required) fields, it's bad and you know it. Neither you nor I like toilet paper roll shapes.

There are many myths and misconceptions in the world of software development. In order to move forward and not stagnate, it is absolutely necessary to destroy them. Today we’re talking about one of the most deep-rooted misconceptions, which is also quite harmful, called “The Myth of Mandatory Sex.”

We will talk about almost any system that uses forms to enter information. A required field is a form field, without which the system will not accept your information. Among the vast majority of software developers, there is an opinion that the required fields should be:

All fields necessary from the point of view of the subject (for example, full name and date of birth of a person, if we are talking about the passport office);
All fields necessary for the functioning of the system (those without which the algorithms will not work - for example, the date from which the provision of services begins in order to make accruals for them);
Important fields are those that are not necessary, but preferably fill in (for example, the rationale for the change being made) - with the motivation that it is better for the user to sweat when it is not necessary than to forget to enter a value when it is necessary.

As you can see, there is a whole complex of myths here that need to be dispelled carefully and systematically. So let's start with two other misconceptions.

Traditionally, programmers believe that they are doing the rest of the world a favor by creating such a great product for them as a “substitute any product name.” Their program is almost a Platonic eidos, a pure abstraction, a mathematical formula, computable, of course, strictly on a set of parameters from its domain of definition. From this point of view, required fields are an annoying little thing that has to be inserted in order to teach stupid and uncouth users how to Right enter information into the system with which they have the privilege of working.

It is also believed that incorrect (incomplete) data is so terrible that even storing it in a database is no longer correct. Well, laziness, of course - from the developer’s point of view, it is easier to check the correctness of the data at the input stage and send the user to double-check their data than to write error handling where this data will actually be used in the system.

What does modern user experience design science have to say about this? Firstly, it became clear (I don’t know to whom and when, but quite a long time ago for sure, see and) that after all, programs are developed for users. In this sense, the programmer no longer dictates conditions, but modestly creates a purely utilitarian product, a tool that people will use to solve their tasks and achievements their goals. Like an iron - if you need to iron something, you turn it on. If, instead of ironing, it modally offers to download updates from the Internet, it is clear where such an iron will fly. Alan Cooper recommends portraying your product's users as very smart but very busy people. They say they are not stupid and will understand how to use your product, the main thing is that you just don’t get in their way.

In general, I believe that every programmer (designer, manager, analyst) should do the meditation mentioned by Sergei Bodrov Jr.:

You stand on the corner of a busy street and imagine that you are not there. Or rather, you don't exist at all. Pedestrians walk, cars honk, shop doors open, passengers change at the bus stop. That is, in principle, the world continues to live without you. This is painful to understand. But it's important...

Of course, I don’t want to say that being a programmer is an unnecessary profession; I’m a programmer myself and I don’t think so at all. It's just a thankless profession. No one will come and praise you for a well-implemented algorithm. If the program is good, it will be used without further questions. This is how it should be, just to be a programmer, you have to get used to it. And these people who walk down the street and take turns at the bus stop are your users. They use things the way they do them needed. Including your product. Without you. They don't know anything about you, don't want to know, and will never know. Sergei Vitalievich, when he is in the polar tundra trying to enter the readings taken from the meter into the system, is not at all interested in why the system tells him that first you need to indicate some type of tariffication, even if at the time of design it seemed to you that without a tariffication type, well there's no way around it. As for the example about the iron downloading updates, it was not taken from thin air - pay attention to how the Firefox browser behaves when turned on.

Will there be anything at all about required fields, Habrowser asks? It's about to start.

The thing is that our real world is not a mathematical model whose parameters are known at any time. Real life is characterized by a lack of information rather than its presence. The person filling out the form may not have the required data - and may not have it within all foreseeable reach, that is, it may not finally exist. This problem cannot be solved by simply making the field mandatory - the value will not be pulled out of thin air. By introducing mandatory fields on forms for the sake of data integrity and completeness, we actually interfering with the use of the system. Faced with such a situation, the user will either not fill out the form (and will not be able to work with the system at all), or will fill in the missing data with fish - fictitious or meaningless data. And this does not indicate that the user is bad or did not try hard, but only that the developed system not flexible enough for use in conditions real peace. What happened in the second case (introducing fish) is a total deception. The system developer can pretend as much as he wants that everything is in order, but in fact it is he who is to blame for this deception. Moreover, it is not clear who won and what - the user had a headache, and incorrect data entered the system. Yes, they got into such a situation that it is no longer possible to detect, filter or clean them up automatically - unlike the case if the user simply indicated that the information was missing.

What to do? You need to make good programs. Namely, yes, do not put the integrity of the database schema at the forefront, but put the goals and objectives of users there. In other words, accepting incomplete and, in some cases, incorrect data from the user, naturally, with the opportunity to correct them in the future. Contrary to misconception (yes, another one) it is possible, it is not that difficult and it even works. In addition, you still need to help in some way, tell the user where, what data and why he is missing. So that he can see and control the situation.

How many required fields should there be on the form? Ideally, zero. Is this always possible? For me, one of the examples of aerobatics is the operation of creating a folder in Windows. It would seem that you can’t do less than one field here, but no, they managed to implement the creation in such a way that the system does not ask for anything - even though technical limitations do not allow the system to create a folder without a name. This is an ideal to strive for.

Naturally, the system must be minimally intelligent, asking the user only what is relevant to the user's tasks, and not to the needs of the system itself. The system is like a tool, remember? Just about the example with Firefox - Google Chrome, for example, solved the Firefox problem by updating quietly at the moment when the user reboots it. The user does not need to know about this at all - he does not know. A worthy example to follow. I must admit, I didn’t even understand at first, why didn’t he ever ask me when he should update?

There was also a myth about important fields (these are those that are optional, but desirable to be filled out). Here everything is even simpler - you cannot force the field to be filled out. Therefore, even if you mark the field as mandatory, or don’t mark it, they will still write fish, nonsense, unsubscribe if they don’t want to fill it out. There is no interface solution for this problem. The importance of fields must be communicated to field staff. And the developer should mark the field as optional. And let me edit.

Literature:

Alan Cooper about the interface. Fundamentals of interaction design. Symbol-Plus, 2009
Jeff Raskin. Interface: new directions in the design of computer systems. Symbol-Plus, 2005

UPD: In the comments, the main moral of the topic was formulated more clearly: we are talking about the system of drafts, about removing the requirement to enter all the data at once and consistently. That is, yes, make optional even those fields without which the system will not work. Naturally, it won’t work, but at least it will save the data.

UPD #2: Let me clarify one more thing that I myself was not clearly aware of when I wrote the topic. I am not discussing here the appropriateness of certain fields on the form (this is an important, but still slightly different topic than the one I want to convey). Rather, I propose to rethink the very concept of entering information using forms, that traditional approach when you need to fill out the entire form at once and correctly. Instead, I propose that the intermediate state (incomplete, incorrect, contradictory) also be allowed to be saved in the database, explicitly marking such a state as incomplete/incorrect/inconsistent. Thus, all situations “I don’t know everything now, but maybe tomorrow I will,” which are traditionally solved by writing them down on a piece of paper, can be processed using an information system. Naturally, such data should not be allowed into the business process due to its incorrectness - everything remains as before. They will simply lie in the database until better times - they will not be useful, well, God bless them.

All fields necessary from the point of view of the subject (for example, full name and date of birth of a person, if we are talking about the passport office);
All fields necessary for the functioning of the system (those without which the algorithms will not work - for example, the date from which the provision of services begins in order to make accruals for them);
Important fields are those that are not necessary, but preferably fill in (for example, the rationale for the change being made) - with the motivation that it is better for the user to sweat when it is not necessary than to forget to enter a value when it is necessary.

In general, I believe that every programmer (designer, manager, analyst) should do the meditation mentioned by Sergei Bodrov Jr.:

You stand on the corner of a busy street and imagine that you are not there. Or rather, you don't exist at all. Pedestrians walk, cars honk, shop doors open, passengers change at the bus stop. That is, in principle, the world continues to live without you. This is painful to understand. But it's important...

Will there be anything at all about required fields, Habrowser asks? It's about to start.

Literature:

Alan Cooper about the interface. Fundamentals of interaction design. Symbol-Plus, 2009
Jeff Raskin. Interface: new directions in the design of computer systems. Symbol-Plus, 2005

UPD: In the comments, trijin and zhindetz formulated the main moral of the topic more clearly: we are talking about the draft system, about removing the requirement to enter all the data at once and consistently. That is, yes, make optional even those fields without which the system will not work. Naturally, it won’t work, but at least it will save the data.

January 13, 2011 at 01:09

Interfaces

Translation

Web forms play a big role in the daily use of the Internet. If you develop websites, then most likely they are present in them: be it a simple feedback form or a sophisticated web application. Here are some tips to help you create easy-to-use forms.

1. Clearly mark required fields

It's annoying when a user submits a completed form and later finds out that they missed required fields.
It is common practice to mark required fields with an asterisk (*) next to their name. Explicitly indicating whether a field is required or not is a good idea.

On the Zappos.com registration form, required fields are marked with an asterisk (*). Optional fields are also clearly marked.

2. Use clear and detailed error messages

I'm sure you hate it when, when you fill out a form incorrectly, error notifications appear saying, “You must complete all required fields,” instead of providing more detailed information, such as, “You forgot to fill out your email address.”
Using real-time validation of entered data is a good solution. For example, immediately after filling out an email address, the web form should check that the entered format is correct, and if something is wrong, then immediately notify the user.

3. Use client-side data format validation (JavaScript)

Using JavaScript data validation saves the user time and also reduces the load on the web server, freeing it from processing incoming form field values. Client-side validation allows users to see that they have just made an error and not after submitting the form. This is true for any fields that are not linked to your database. Such as checking the format of an email address or the number of digits in a phone number.

The SurveyGizmo registration form lets you know if the email address you entered is not in the correct format.

4. Visually highlight fields to fill out so that the user doesn’t get lost

Make sure that you can visually determine which field the user is currently filling out. This can be achieved using the focus: pseudo-class selector in CSS.

A Wufoo web form visually highlights active elements with a background color.

At a minimum, implement a highlighted border for fields - browsers will do this for you by default, but make sure the color is different from the site design (background).

Google Chrome highlights the active element with a yellow frame. Firefox light blue.

5. Show progress results

If your web form is large and consists of several pages (or has several steps), make sure that the user is constantly informed about the progress of the actions being performed and how much more time they may need to complete. This often occurs in cases of an online survey (research) with many questions or during the process of placing an order in an online store.
All you have to do is write “Step 4 of 5” or something like that. If users keep clicking the “continue” button without clearly understanding when the last step will be, they will stop filling out the form sooner than you might expect.

The Amazon checkout has 4 pages. The form tells you where you are now and how much time is left until completion.

Of course, a better alternative would be to shorten your web form - if this can't be done, then at least give the user information about how close they are to completing the actions being performed.

6. Periodically save (cache) form data

Forms with multiple pages or steps can often make mistakes. To avoid data loss, you need to implement a way to save user-entered information for each session. This increases the reliability and percentage that the form will be filled out even after situations where the user leaves the page (for example, clicks the back button in the browser). Having to fill out all the form fields again can cause users to leave.

7. Do not use the standard “Submit” text (send)

Instead of having your form button called “Submit,” use text that reminds the user of their actions. For example, “Register”, or better yet, let the user know about the benefits after filling out the form.

On the Basecamp registration form, the “Submit” text has been replaced with something more useful.

8. The “Cancel” button makes you hesitate

Imagine that you are buying a new shirt in a store and the seller asks you: “Do you really want this particular shirt?” Will you still buy it? Most likely no. You may have doubts, thinking that the seller considered the shirt unsuitable.
The same thing happens with web forms: using a “cancel” button can make your users think twice about what they are filling out.

9. Show users fields in the correct format

If you ask users for specific information - such as a phone number or credit card - let them know what you expect. If the password must have a certain number of characters or it must contain a certain set of characters, clearly describe these requirements. This reduces ambiguity and speeds up the filling process.

Geico's registration form provides clear instructions on what format the input data is expected to be in.

10. Single-column form is the best solution

According to eye movement research from user experience design agency cxpartners, scanning a form downwards is preferable to scanning from left to right. This reduces the amount of eye movement needed to complete the form.

Single column form

Backpack's registration form is a single-column form.

Form with multiple columns