Required fields on the Internet seem to be as old as the Internet itself. Not many today question the value of required fields, given how prevalent and convenient they are.
And yet the customers continue to dislike required fields. 11% of US adults have abandoned an online purchase because they did not want to fill in required fields. 88% of online buyers had at some point intentionally misrepresented their answers to required questions.
There are three main categories of required fields – evil, postponable, and voluntary. Fields in all of these categories, however, share the same trait, they should not be marked required.
The overarching idea is that it is not the fault of the user that some data is missing and the user does not owe the service anything. Instead, the service should suggest what will go wrong if the information is missing, but be able to proceed without it if at all possible.
Plenty of fields the designers originally considered required are just... not. Surely, for a company planning to send spam, a user’s email address is required. But is providing the email to the company required, or even in the very least useful for the user? I would argue not so.
When a website requires to register for a free account to view otherwise public content, it is clear that the registration is required for the company, not for the user.
When Facebook registration form states the choice between male and female is required (which, by the way, is alienating and possibly offensive), it means it is required for Facebook. There is nothing crucial Facebook will not be able to do without knowing the user’s gender.
What if the field had an explanation next to it why the field is required? It so happens websites do that already. Somewhat. The Escapist, for example, has a very thourough explanation why they must ask for the user’s birthdate. Namely, legal requirements.
Facebook itself tries to explain why the birthdate field is required, even if the explanation sounds a bit like marketing speech.
In this context, what is the user to think when a seemingly needless piece of private information, such as gender on Facebook registration page, is required without any explanation? Perhaps, only the worst.
Many required fields are not really required at the moment of data request. The obvious example is asking for shipping address at the time of user registration in a web shop. Perhaps the user is registering only to use a wishlist functionality or to ensure his cart saved?
Registration itself is postponable. Let the user use the application until he tries to save data or edit his profile. jsFiddle lets the user perform everything without registration, with registration only carrying extra features, such as a list of user’s data.
Another interesting use case are fields that are eventually-required. When a user creates a new email to send in Gmail, the recipients of the email are, obviously, required. That does not prevent the user, however, from just closing the window. His message will be kept intact for future editing in drafts.
With emails it only seems natural, but the notion becomes less obvious once other types of data are concerned. Say the user is editing an invoice in a document management system and does not know who will be the recipient yet. Surely the only time the recipient is really needed is when the user closes an invoice, not when the user is drafting one.
In some cases this can get even better. Should time and date be required fields for creating an appointment in one’s calendar? Surely if the time is missing it should indicate that the appointment is tentative and should happen sometime that day, while if the day is missing, it should happen one of these days at 11am?
Obviously cases like described are extra features and budget might not always allow for them. It is important to understand then that the meaning of required fields changes from you must provide this to we do not support this yet and the blame shifts from the user to the service.
Finally, the only true case for a required field is when a user wishes to provide some information himself.
If the user wants to be identified, he will provide an email address. If the user wants an item to be shipped home, he will provide his home address. If the user wants an email to be delivered somewhere, he will provide recipient address.
There are strong doubts if marking fields as required in these cases provides any additional value, as the need for providing the information is not only obvious, but also initiated by the user himself.
Of course, the application should still let the user know that it is impossible to send a package to his home without knowing his address, but there is no need to indicate that until the user has tried to submit the form. In all likelihood, he will fill the field without being prompted to do so.
The main consideration is the attitude. The user is not required to do anything. Instead, consider that if the user wants to provide some data, he will. If the user does not want to provide some data, but the application really needs it, it should be thoroughly explained. And if the explanation is shady, it would be bad to present it to the user? Maybe the application should not ask for that information in the first place.