16 Tips that Will Improve Any Online Form. Part 2/4.
Summary: In this part you will find out 16 musts for how to design a way better experience for your checkout form (or any other form), and you will understand why you should do so.
Besides, this article is the second one in the series of articles linked together by one goal and story where I described what I have learned and used to design the completely new checkout process for our SaaS project Fluix.
Chapters 3 and 4. The complexity behind the new checkout form for Fluix. You’ll learn the relationships and dependencies between fields, their input & visual constraints, and a lot of insights about the way I’ve designed the new checkout form for our SaaS project called Fluix.
Let’s dive in.
1. Always ask as little as possible.
Always ask the most relevant info only on one particular step. For instance, if you’re a services provider and a user’s phone number or a home address are not heavily needed on the current step — don’t ask for it! “Less is more” principle works perfectly here.
In that way you are able to decrease the number of questions and as a result:
- Boost up the completion time.
- Dramatically decrease the cognitive load on a user by decreasing the amount of objects on the screen.
2. Pre-fill/auto-detect as much as you can.
Always help your respondent. If you already know some information about him, pre-fill those fields or even don’t show them at all.
For example.
• Most of the times you can easily detect a user’s country and the city by IP or geolocation.
• If a user came to checkout process from your newsletter/marketing campaign, you definitely know his email. Hence, pre-fill the Email field.
Speaking in the context of checkout form for our Fluix, there are 5 of 15 (1/3!) fields could be pre-filled from the very beginning. This is because the current form is for Subscription registration after the trial period has been ended. Hence, we already know some info about a respondent when a trial account is registered.
But we must take into consideration that we work at B2B market where the respondent who manage the product and the person who pays for it might be two different persons. Therefore, I should leave those pre-filled fields editable. More about this in chapter 3.
Also, you should keep in mind the aspects of user security and safety. A lot of pre-filled fields at first might look creepy and create an impression of spying.
3. Use autofocus.
Automatically activate the first field (or the needed one) in the form. In that way you give a hint to a respondent where he should start and as a result, significantly boost the whole process.
Moreover, you save a respondent from one additional click/tap and a bunch of unwanted speculations.
4. Use a single column design.
By using a one-column design, the eyes move by natural direction – from the top to the bottom by one single line. In multiple-column design eyes start zigzagging. That dramatically increases the completion time and the number of eye fixations. That is bad for you, as well as for the respondent.
Moreover, this approach doesn’t cause unnecessary questions like “Where should I start? Which field is the first one? Which is the second: at the bottom or on the right side? Are questions in the left column equal to the questions in the right one? Or they are independent? Why they are separated?”…
The exception here might be only for the information that we used to see in a single line like:
- Our first, middle, last name: Sebasteean van Derlot
- Date and time: 16:30, 21 Feb, 2017
- City and state: San-Francisco, CA
5. Divide fields into semantic groups.
If there are a lot of fields in your form, try to divide them into semantic groups by adding some additional spaces or section titles between them. This approach gives a respondent the feeling of gradual answering and excludes such thoughts as “Too many questions! I’ll leave this for tomorrow…”.
The division into paragraphs performs in the same way. Instead of the solid piece of text, you read it by portions. The same approach is used for a bank card number.
6. Use input constraints for each field.
To significantly decrease the amount of bounce, mistakes, wrong data, etc. you should always use the constraints on what can be inputted into the field:
• min and max length (num. of characters)
• format;
• numeric, alphabetic, alphanumeric, all symbols;
• dependencies, etc.
For instance, could the card number consist of letters or any other special symbols? Of course not. The card number always consists of digits only, so there is no need to allow typing any other symbols. Also, mind the mobile. For the card number field without any input constraints, you force a user to switch between alphabetical and numeric keyboards each time. Of course, this rule is relevant for a lot of other fields.
The detailed overview of the constraints for each field (Country, Zip-code, State, Address, Name, Phone number, Card number, Expire Date, etc.) you will find in the 3rd chapter of this article.
7. Use visual constraints.
Use visual constraints to not cause a subliminal spurious wish to type more than you need to. For instance, if there is only two characters must be typed into the ‘State’ field, no need to make it as long as, let’s say, ‘Address’ field.
Besides, different width of the fields serves as a good anchor for eyes to navigate faster than in a column with the fields of the same width.
8. Be clear in your error messages.
It doesn’t matter what type of validation you use, you should always use inline errors. Use them ‘just right here’, in context. But not somewhere else on the pages. The natural mapping here is your best friend.
And, more importantly, always try to explain the root of the problem. Avoid common messages like ‘Something went wrong. Please, try again later.’ or ‘Error 999’. A user will never understand such messages. Try to use a human language instead and explain what exactly the user/the system made wrong, and what exactly should be fixed/filled. The second one is the best one.
9. Use inline validation with real-time feedback immediately after answering.
The best approach to notify the respondent about the mistake he probably made is to highlight the field and show the error message inline just right after he answered the question.
You might noticed that a lot of online services nowadays use various types of validation (or don’t use any validation at all).
- Someone shows to a user mistakes/errors only when the form is completely filled out and the Continue button has been pushed. It’s called Control Version.
- Someone uses inline validation and shows the mistake while answering or even before.
These options cause a bad experience for the respondent. But worst of all is the second because:
1. After each character typed, a user receives an error that might cause a fundamentally false perception of the situation;
2. Even when the field is empty the error will appear, what is wrong.
Here are some benefits of implementing inline validation with real-time feedback just right after the answered question according to the research made by Luke Wroblewski (this research has been conducted 8 years ago!):
• a 22% increase in success rates,
• a 22% decrease in errors made,
• a 31% increase in satisfaction rating,
• a 42% decrease in completion times, and
• a 47% decrease in the number of eye fixations.
10. Use labels outside the fields. If needed, in combination with placeholders.
The main rule here is not to hide the labels while answering, so the respondent will not loose the context. Therefore, the labels preferably must be outside the field. If there is enough space, use them on the left side of the field.
If you design for the mobile and you are limited by the screen size, you can put the labels on the top of the field. Yes, this approach will cause a pretty long form. Remember, it is always better to make form higher than wider due to the vertical scroll that leads to less cognitive load on our brains.
Or use label inside the field and when it is in the focus — slide out the label to the top-left corner (as shown below). It’s a kind of trend right now and works really well for the mobile. For instance, Shopify use this approach.
In many cases, you might additionally help your respondent by using placeholders in the fields as a hint text. You can show how the answer must look like — the format, structure, etc.
In other hand, it’s better to use masks instead of placeholders or any hints. For instance:
- the date: DD/MM/YYYY
- phone number +1 (___) ___-____
- exp. date: MM / YY
It will works as a constraint and a natural mapping. So a user will understand what he types in at a glance.
But you should care about the clear visual distinction between the placeholder itself and the value typed by the respondent. If not, your design might cause a false perception – the respondent might think that the fields with placeholders are already filled fields.
In the context of Fluix form, I decided to use the prefix “e.g.” for each hint-type placeholder. For instance, for ‘Full Name’ field: e.g. John Smith
And for the clear visual distinction I use the following 3 styles for 3 different states of the field:
— default, empty field: font-weight: 400; colour: #465777
— active, empty field: font-weight: 400; colour: #aeb0b8
— input, filled field: font-weight: 600; colour: #071d49
11. Mark optional fields instead of mandatory.
Frankly, there are a lot of debates on this point. Baymard Institute saying you have to mark both the mandatory and the optional fields. But I’m more inclined to Nielsen Norman Group version. Their advice comes from the very first canon — always ask as less as possible. So the number of optional fields in your form should be down to zero. Therefore, the best practice here is to mark only those fields which are in the minority. For instance, if 9 fields out of 10 are mandatory, then it makes sense to mark optional field only.
In context of our form for Fluix, we do not have any Optional fields now. We are asking for info that we do really need, without any additional questions. So I decided not to mark them at all. But this particular case is quite tricky, because the customer cannot be sure that all fields are mandatory. Hence, I’m going to test that when the form will be completely in production.
12. Don’t take the user out of the checkout process.
Try to avoid any links to other resources on your checkout page. You need to keep the respondent in focus on replies and do not interrupt the process by redirecting to other pages. Otherwise, he will just “get lost” somewhere and simply forget what he initially did.
Use links only in urgent cases or when it’s critical to explain something by redirecting the user to some official sources. For instance, if you use any third-party service, like SalesForce or FastSpring, you should better provide the link on it’s official page, so the user is able to read how the system works.
13. Enable next-step-button only when the form is filled out.
Activate the next-step-button only when the user has responded to all mandatory fields and there aren’t any errors. Obviously, apply this trick only if you use inline validation with the real-time feedback (like described in trick #9). This will keep the respondent focused on the answers and will not let him to skip something important.
More importantly, the animated activation of the next-step-button will work as a visual anchor for the eyes. So the user’s focus will jump to the button at the right moment. And that’s exactly what we need. But to make this approach work properly, the distinction between disabled/enabled states should be very explicit and visually clear.
For Fluix I use grey colour + opacity 0.5 for the disabled state and blue colour without opacity for the activated state.
14. Mind the local differences.
In case your product is only for, let’s say, US market you can forget about local differentiation. Otherwise, you should, no, you must always take into account it. The field labels, placeholders, masks, etc. can be different for different countries or regions.
For instance:
- different phone number formats → different masks;
- ZIP-Code for US, Postal Code for EU;
- states for US only.
15. Always explain why and what for if you ask for specific data.
Always keep in mind that the information you’re asking from a user is a really private and sensitive for him. It’s always about his life, family, finances, etc. So, to prevent unnecessary doubts and questions you must explain why you ask some specific data like the phone number, birthday, weight, spouse name, etc.
Try to guess, what is the Sign Up form shown above?
Yep, this is Facebook. They are asking for your birthday while in the sign up process and explain to you why they need this info.
16. Support colour blind people.
By using colours with a low-contrast level between your foreground and background, you decrease the legibility. Especially for color blind people. Especially on the old type of displays with TFT-matrix which are more popular due to the price-tag. A lot of designers/services forget about such people which approximately 4.5% (2.7 million people) of the entire population only in Britain!
This tool or that one are gonna help you to measure the contrast level of selected colours. So you will know whether your colours passed the W3C tests or not.
In Fluix I use 3 visual states that can be easily distinction on most kind of displays and support people with different types of colour blindness disabilities.
To test your designs in real-time in Photoshop, try these actions by Bjango. Sketch user can use Stark Plugin. Of course, they are not super accurate, but definitely will give you the right sense of how people with colour blindness see this world. They are super easy to use.
Alright. That was must-do “tricks” that are based on a lot of observations and researches by bold companies and other successful guys from our industry. At the end of the last chapter you will find a lot of links to sources that I used/read/learned from.
I’m sure, the information above will be useful for you. But there are hundreds of other creative people whom it might be useful for as well. So Clap! Clap! :)👏🏼
Now, let’s dive into the insights behind the form I designed for Fluix. In this final chapter you will find out tons of practical information about how to properly validate specific fields; why and how to use input constraints and which exactly; what are the relationships between fields; and a lot more. Be my guest ⟶
