• At the top of the form, there should be a short title that summarises the function of the form, plus a short introductory text explaining what the form is for. Visitors may in fact be led directly to the form and not have read the previous pages.

• Don't just put the instruction/explanation on the page linking to the form (such as a service), because a form can also be linked to directly from another location, or the form can be found via a search function. Even then, it should be clear what the form is for and how/when it should be completed.

• Ask for as little information as possible so that the form looks as short as possible. The more effort it seems to take to fill in the form, the more likely the visitor will drop out. This also applies when the fields are optional: what matters is how the form comes across at first glance.

In the example below, there are far too many fields on the contact form:

• Ask for as little personal information as possible. The more the visitor has to provide something about himself, the more likely the visitor will drop out. If necessary, mention why it is necessary to provide the personal data, or reassure the visitor by mentioning that his data will not be used for purposes other than what this form is for.

• Asking for e.g. gender is considered annoying by some, so only do so if that information is really needed for follow-up actions or certain systems. Where possible, include an alternative in addition to the options female or male.

• Hide fields that do not apply to all visitors, to avoid making a form seem longer than necessary. For example, ask with a yes/no question whether a certain situation applies, and based on the answer, display additional fields or not.

Visitors find filling in forms tedious and are quick to drop out or not start at all. By starting with low-threshold fields and saving the difficult ones for last, you persuade them to start. By the time they encounter the difficult fields, they have already put effort into filling in the form and are therefore less likely to still drop out, as it feels like a waste of effort already put in.

• Start with fields that can be filled in by heart. Save fields that require someone to go look up information or search for and upload a document, for example, until later.

• Save fields asking for personal details until last. For example, let someone choose the sessions they want to attend first, only then ask for their name and e-mail address, and only ask for payment details at the very last.

• Make sure the CMS itself converts various types of input to the correct format, such as removing a space from a postcode or a dash from a phone number.

• Don't make requirements for fields more stringent than necessary. Very complicated password requirements, for example, are not necessary for a Radboud Recharge account we are not a bank, after all, so suppose the account gets into the hands of others, it is not a disaster.

• Sometimes the CMS cannot automatically correct certain entries or it is necessary to impose requirements. If so, state these requirements in advance. It is very annoying for visitors to get an error message and have to fill in a field again.

• Make sure the requirements are visible directly below the field, in the help text. So not hidden under the question mark with additional explanations. This is because the help text is always in view; it does not take an extra click to see the explanation.

• Make the field label so clear that the visitor does not need any additional explanation.
  In the example below, "Job type" would be better as "About what type of vacancies would you like to receive job alerts?", and the help text can be omitted.

• If additional explanations are still needed, use the question mark icon to add additional explanations.

• Use additional explanations only for people who may not understand the field. This is hopefully only a subset of users. If it is about information that all users of the form need to know (such as entry requirements, see point 7), add help text instead of extra explanations.

Each type of form element has a specific function. People know this function from other websites. You could use a form element in such a way that it could also perform another function, but as soon as you deviate from the standard, people get confused. Also, certain types of form elements have specific additional functionalities attached to them, for instance helping to validate the field for the correct form of input, or on mobile phones showing a keyboard with buttons specifically suited to input for that type of field (such as an @ sign directly in view for entering e-mail addresses). If you use a different type of field than intended for the type of input, these benefits will be lost.

• E.g. do not use a text field but a number field for entering numbers. On the front of the form, the field looks the same, but they work differently in terms of data validation and displayed input keyboard on mobile phones.
  
  DON'T:

DO:

• For example, use checkboxes for being able to tick at least one, or several options. Use radio buttons if the visitor is allowed to choose only one of the options. So in the example below, the first is wrong, the second is right.

• In the example below, the first field is actually for free input. The second type of field is specifically for entering times and prevents errors.

• Only wide fields come across as a lot of work to fill in.

• Fields that are too narrow prevent visitors from fully seeing their entries, increasing the likelihood of incorrect entries.
  Example: A postcode field needs to contain only 6 characters and thus must be narrow. A field for an e-mail address must be wide because it must be able to contain many characters.

Form elements that are near each other are seen as elements that are related to each other. Form elements where there is a lot of white space between them, or where there is a separation such as a line between them, are seen as unrelated elements.

• Make sure there is no more distance between form elements that belong together than form elements that do not.
  In the example below, the horizontal radio buttons belong together (select one of the two options), but because there is more distance horizontally than vertically between them, it looks like the vertical radio buttons belong together (select one of the three options) or that all radio buttons belong together (select one option out of six):

• Also, always check how the form looks on desktop computers as well as tablets and mobile phones.

• Decide what is a logical order from a visitor's perspective. For example, alphabetically.

• For very long lists, such as a list of countries, you can also put the most chosen items, such as 'Netherlands', at the top of the list and sort the other items in a different way. Don't do this for short lists.

If possible, it is useful to already fill in as many fields as possible for the visitor, because it saves effort. But fields that already contain input are more likely to be overlooked, resulting in the input being sent unadjusted.

• Only fill in fields fixed for the visitor when you are sure it is the correct entry, for example because you have received this information from the visitor before.

• Don't put a sample entry in a field.

• Do not set a default value for form elements such as radio buttons.

• Do not show an instruction in a dropdown box, as in the example below:

• Omit the confirmation field. Every extra field makes less sense to enter. Most visitors just copy and paste entries from the first field into the second field anyway, so this field is rarely useful.

• If the visitor needs to read additional information, such as general terms and conditions or additional explanations, show these in an overlay window, for example. Don't just link to another page. Even if the data already filled in the form is automatically saved, the visitor does not know that. The visitor may be afraid to click away for fear of having to fill everything in again.

• Turn on intermediate data saving to prevent accidental deletion of entered data if something goes wrong before the visitor has had a chance to submit the form.

• For long/complex forms, for which a visitor needs more time (e.g. because they need to request documents from another body to add as attachments), make it possible to save the data already entered and return to the form at a later time, to still complete it.

• If saving for later is not technically possible, indicate at the beginning of the form what data is needed, for example in a bulleted list, so that the visitor does not find out only in a later step that he does not have all the required information to complete the form.

• If a form consists of multiple steps, show at each point how many steps there are, what these steps are, and which step the visitor is in.

• It should always be clear to the visitor at what point they finally submit a form, and when they merely move to the next step in the form.

• If the button goes to a next or previous form step, add an arrow to the button. For example, '< Personal data' and 'Choose courses >'. If the button sends the form, do not add an arrow. For example, 'Sign up'.

• When moving to the next step in a form, state which step the visitor is going to. So not 'next' or 'previous step', but for example 'to address details', 'back to personal details', 'specify availability' or 'choose courses'.

• Make sure the text on the submit button tells you as specifically as possible what will happen when you click it. So not 'send' but, for example, 'apply', 'confirm registration' or 'change password'.

• Make the button to continue in the process stand out more than the button to go back (or to another less desirable option). That way, the visitor intuitively chooses this option.
  In the example below, it has been done exactly the wrong way round:

In most cases, a cancel button is not useful. The visitor can simply close the page or click the back button. Moreover, it is common for visitors to accidentally click the cancel button instead of the submit button and thus lose everything they just filled in.

Getting an error message is already very annoying for users, so make sure it causes as little additional frustration as possible.

• Formulate error messages in a customer-friendly way, not in a technical way. So not like this:

• Make sure the error message is displayed not only next to a field, but also where the visitor looks when he clicks the submit button. If the form is long and the visitor has scrolled down, and the page does not refresh after a button click, there is no point in showing the error message at the top of the page because it will not be displayed. If it is a long form and the page does reload after a button press, then you don't want to show the error message at the submit button.

• Be specific. Indicate at which field(s) the error is and what is wrong. So not "Not all fields are filled in correctly", but "You have not entered a valid postcode" or "You have not entered a telephone number".

• Make sure the confirmation text is on screen so that the visitor sees it without having to scroll after clicking the submit button.

• Formulate the confirmation in terms of the purpose of the form: not what was sent, but why was it sent. So not "The form has been sent", but "Your request has been submitted", "Your notification has been sent", or, if there is an automatic action attached to the form: "You are now signed up for the newsletter".

• If there is no automatic action attached to the form, but a manual action by an employee is required, also tell what the next step will be. So not just "Your application has been submitted", but "Your application has been submitted. We will contact you within two working days", "We have received your application. You will receive your registration certificate by post next week.", or "Your notification has been sent. We will investigate the problem and resolve it as soon as possible."

• Make it as personal as possible. For example, thank the visitor. "Thank you very much for signing up! We will now start working for you to [...]"

If the visitor and/or administrator receives an e-mail confirming the data sent, or a notification that a new form has been received, it should be pleasant to read.

• Make sure the e-mail's salutation and conclusion are neat: don't just list the details you have entered.

• If you know the recipient's name, use it as the salutation.

• Put all entered data in a logical order and conveniently under each other. Start with the field label and then the entered data.

• For visitors: at the bottom of the e-mail, state again what the next step is (see point 20): what is this confirmation of and what has been automatically initiated or what will happen next?

• For visitors: Include contact details and whether this is an e-mail address that can be replied to.

• For administrators: mention where in the CMS the completed form can be found. (Perhaps we should also include whether there is a deadline for retention under the AVG and therefore when things should be cleaned up?)

All forms on the website should be set up in the same way, regardless of which organisational unit the form comes from, so that the visitor has a consistent experience.

• Always give the same type of fields the same field label on all forms.

• Format fields and text in the same way. For example, always non-italics instead of sometimes non-italics and sometimes italics or bold.

• When writing text, stick to the general guidelines for good online content and the RU writing guide.

See also Conventions for form.