Forming a form

CZ
Made by Munsters
Published in
7 min readApr 4, 2018

A user interacts with your site, awesome. A user fills out your form, even better. That’s the goal right? Because having the user fill out a form improves conversion rates. In this article I will in-form you (get it!) about best practices for website forms in terms of layout, validation and accessibility.

Layout

Form layout is crucial to the user’s experience in efficiently filling it out. When designing and developing the form remember to keep in mind structure, labeling, placeholder text and action buttons.

Structure

Forms should be presented in a single column layout to prevent the user from interpreting the fields inconsistently. Having more than one column interrupts the vertical momentum the user gets while moving down the form. Use logical sequencing in a way that makes sense to the user and have them fill out the most common fields first. For example, the user should be filling out their name, before they fill out their credit card information.

On larger forms, group like-things into sections. For example, section 1 has “Customer Information”, which asks for the name and address, and section 2 has “Credit Card Information”, asking for that magical credit card number and all that comes with it. In smaller forms, if you have a first name input and last name input, keep them in the same line. You could also combine the “First name” and “Last name” fields to become “Full name” to minimize the number of fields. Fields like city, state, and zip can be presented in the same row, as well. Use radio buttons instead of a dropdown for information that only has two or three options. The goal of the structure is to keep the user flowing through the information.

Labeling

Labels tell the user what information belongs to a given form input. They are usually positioned outside of the input but close to the associated text field. Avoid large spaces between labels and inputs, since items that are near each other appear related. Wider forms may have the label on the right of the input, but on smaller devices put it above. I like to keep it consistent and always have the label above because it’s easier to read through.

Also, note that labels should be one or two words and are there to provide a label for the input, not a sentence long hint. Try using sentence case (ex: “Full name”) instead of title case (ex: “Full Name”) since it is easier to read, but try to avoid all caps. In a small form that is familiar to the user like a search box, you don’t need a label, you can use an icon to indicate that it’s a search box. However, things like login forms that need an email and password, might need a label in case the user forgets if they sign in with a username or email.

Placeholder text

You can find placeholder text inside of the input to give the user a hint or example of the information required. Using placeholders to replace labels provides a bad user experience because it removes the guide of the input or the user might think that input is already filled in. If you must use a placeholder to replace a label, try using a floating label, like the example below.

Floating label example from Dribbble

Using a placeholder with a label can provide the user with a little more guidance and can help improve form completion and conversion rates. However, according to the Nielsen Norman Group, “user testing continually shows that placeholders in form fields often hurt usability more than help it”. At first this caught me off guard, but as it turns out, form fields with information already in them are less noticeable and eye tracking studies show that users are drawn to empty fields.

Action buttons

This is the golden button of form submission, so make the “submit” button stand out. It’s a good idea to leave the button disabled until the required items of the form are filled out to prevent the user from prematurely submitting the form. Getting the user to click this button means that user has completed the form and is now ready to give you their information. Don’t let them think there is another button better than the “submit” button, aka avoid buttons that reset or clear the form. However, you can provide a less prominent “cancel” button to prevent the user from deleting all of their information accidentally, and they will abandon the form all together. Some forms, like search bars, may not have a button at all, and the user is expected to just hit “enter”.

Validation

Form validation is everything when it comes to receiving the data the way it is intended to be received. That being said, the user needs to know how it is intended to be received. They need to know the format, which one is required, and why the form won’t submit the information.

Required Input Fields

Having the user understand which fields are required is important because they need to know what needs to be filled out in order for the interaction to be completed successfully. Limit the number of optional fields, but make sure you distinguish the difference between a required or optional field with a label or key.

Correct Format

Inputs that require a specific format should have instructions for what is required. For example, passwords that require an uppercase, lowercase, and a hair from your great, great grandfather should be noted. If your phone input requires parentheses, you can just automate it for your user to avoid confusion. In other instances, an input may not be required but if it is improperly filled out, the user needs to be made aware. For example, if an email is not a required field and the user fills it out but forgets the “@email.com”, they should receive feedback that informs them that what they typed in is “not a valid email address”.

Confirmation

Feedback communicates the result of an action. When a user is filling out a form, they need feedback to confirm the status of their action. You don’t need to provide the user with a success message for each field while they are filling out the form, but it’s really important to show error feedback for each field when there is an error. In doing so, identify each issue with the input it relates to. Don’t group all of the errors together and display them at the top of the form.

Error feedback is more than using red as the background or border of an input with an error. It’s about how to guide the user to recover from the error. They need to understand what the issue is, why the information wasn’t accepted, and how they can fix it. Use descriptive information to explain why an input was rejected. For example, saying “Not enough digits for a phone number” or “Name requires 3 or more characters” is more descriptive than saying “too short”. And on that note, avoid using negative words like “oops”, “error”, “wrong”… you get the point. The user doesn’t need to think they made a huge mistake … it’s a form field and they’re filling it out so you can get their information.

Accessibility

In a previous blog post, I wrote an article about My Experience with Accessibility where I talked about the importance of building websites and applications to fit users of all needs. Creating an accessible web for everyone includes having accessible form fields.

As stated before, things like structure and organizing content in a logical manner, also apply to accessibility rules. It’s also important to make sure the form is keyboard accessible. Keyboard and screen reader users use tab key navigation, which allows the user to tab through the interactive elements. Using a <div> or <span> prevents keyboard users from accessing these elements. aria-labelledby identifies the element (or elements) that labels the current element. For a list element like a group of radio buttons, you can use aria-labelledby and give the label id the same value.

When it comes to labeling, make sure you use the <label> attribute, so the screen reader knows that it is a label. Adding a for=”__” attribute to the label that matches the input’s id, tells the screenreader that the label and input go together. Adding required to the input is acceptable for a screen reader to understand that an input is required.

Remember before when I said using placeholders as labels was a bad idea? It’s extremely irritating for users that navigate with a keyboard, since the input doesn’t have a label. Moral of the story… don’t do it!

And last but not least … validation. This is extremely important because the user needs to know if a form field is not valid. Let’s say you are checking if an email address is valid and just like before, there is no “@” symbol. The input needs to have a value of true for aria-invalid. Another point to consider when it comes to validation is color blindness. If you were to only use a red border to show an error, users that are colorblind may have difficulty differentiating it as an error, so include another hint like an icon or error message next to the form field.

So there you have it. Website forms. The portal between the user information and you. Providing the user with a form that has good structure and labeling, accurate validation, and is accessible to everyone will boost your conversion rates.

--

--

CZ
Made by Munsters

Mountaineer. Gator. UI Developer👩🏽‍💻.