In my recent analysis of insurance quotation forms I found that some websites had half the number of fields in their forms than others. If all the forms had the same purpose, and they needed the same information from customers, why were some half the length?
Some of the sites were smarter about requesting and calculating information and reducing the burden on the user. On paper these sites will have a lower abandonment rate, and higher form conversion rate.
In this blog I share the smart ways to improve a long form, along with other tips on how to improve conversion rates for forms that are of a significant size.
Should you split long forms in to multiple steps?
Long forms kill conversion rates as users will abandon them because they believe significant effort is required. However some users will abandon when they see that too many steps are required. When does a form become too long, and how many steps should you split it in to?
I’ve seen performance data that shows that long forms are better when split into multiple small forms, and other real-world data that proves the exact opposite. There is no global right or wrong way to split, or not split, a long form but there is an answer for your market, demographic and your site that you can find through testing.
Users hate the effort, or perceived effort, needed to complete a form. If you’ve run out of optimisation opportunities that are focused on reducing effort on a long form then try a test of splitting it into multiple steps. If you have a pipeline of optimisation tests that you believe will fix form problems and make it easier for users then carry on testing those first.
Insurers took a wildly different approach to splitting long forms, here’s what I found in my research:
- The highest number of fields is 76, split over four steps. The lowest is 39, split over six steps
- Across the 31 insurers that I analysed the median number of fields was 58, across an average of 7.13 steps
- There was an average of 9.29 fields per step
- 64.5% of forms unfurled new, required, fields
How should you split a form into multiple steps?
There are natural break-points for forms as you request different types of information. In my car insurance research these were generally split as “Your Details”, “Your Car”, “Insurance Type and Quotation” and “Payment”. These splits reduce the number of fields that a user sees, the length of the page and they also make it easier for the user to think of answers. The same logical splits occur in e-commerce checkouts, with a front-loading of questions about the individual (title, name, sex), then contact details (email, telephone) followed by address details and finally payment information.
Some questions in a long form will require the user to really think about the answer, and draw that information from a different part of the brain. If you can group these questions together then you’re minimising the cognitive load time, and reducing the chance that a user will think “this is too much for me” and leave.
Later on I talk about generating as much data from the user as possible, and there are some great examples of forms that top-load certain questions in order to use that data later in the form to make it quicker. Some insurance companies ask for the registration of your car as an early question so that they can pre-fill later questions (like what make and model the car is). Considering what questions you can ask to generate answers to multiple questions down the line may mean you move away from the traditional order or grouping of questions in steps, this should be tested rather than relied upon.
If I split my form in to steps, how should I order them?
Most sites go for light questions like “who you are” first, so name, sex, title etc. Most sites leave payment details (credit card and bank details) to the end. User’s don’t just expect your website to work in a certain way, they expect it to have a similar flow to other sites. Some sections have to be in a certain place, otherwise the user will become anxious. Moving the payment details to the first step in a checkout process and the user will think “But how do you know where to ship my order”.
My advice is to keep things natural and go light first, payment last. Exceptions would be if toploading a question made the rest of the process easier, if your priority is average customer value rather than conversion rate and you want to add some up-sell steps in. If you have some powerful data, an incredible hunch and you want to test out something completely different then by all means give it a test.
Pre-select obvious answers to save users time
Here’s two examples of how pre-selecting answers can make it even faster for users to complete your form:
- An e-commerce site that is aimed at females asks for the users sex, but pre-selects the Female option
- A car insurance website operates in the UK and asks “Is your car right hand drive or left hand drive” but pre-select right hand drive
- A retailer that generates 95%+ orders from the United States asks the user what country they are in, but pre-selects United States
Those examples are based on my belief that the majority of people will almost always give the same answer to that question. They’re good guesses, but you (the site owner) have access to the real data. If 99% of users say they have a right hand drive car then pre-select that. If 95% of users always say the same thing, make it easy for them.
Take a database dump of all the answers to your form questions over a good (3m+ period of time), calculate the percentage each answer constitutes against the total responses for that question. You’ll see opportunities to pre-select. Cross-reference this against any marketing plans (Are we going to target a new country/sex/something that will mean that it’s likely pre-selecting will alienate these users) and check with your legal team. Some questions may need the user to select a response, and pre-selecting it negates their approval of something.
Doesn’t the user have to read the question regardless? The answer to the latter is yes, the user will almost always still read a question when the answer is pre-populated, but they also read that their answer has been filled in. They don’t need to think about the answer, even if that thinking time is relatively short, and they don’t need to interact with the form, so no clicks or keypresses. Every reduction in interactions reduces effort and time to complete. This has an indirect impact on the conversion rate.
What difference does it make? Every site is different, so try it and see. In your form optimisation process this is a light task that should take single digit hours from start to finish, so it’s worthy of a trial. From data I’ve seen there’s a minor reduction in form completion time and a minor improvement in conversion rates. It’s unlikely to give you a double digit increase in sales, but it’ll be a change that’s part of that group of minor changes that deliver major results.
Radio Buttons trump Drop Downs
Drop downs are great for ensuring data accuracy – imagine asking a user in the United Kingdom what country they live in and the answer has to be given in a text box. You’ll get responses like UK, United Kingdom, England (or Scotland, Northern Ireland, Wales etc), Great Britain, GB and misspelt variations. The time to complete will be much longer (more key-presses required) and there will be an increase in the correction rate. The challenge with drop-downs is that they can be long, and most of the options need to be absorbed by the user before they choose an option. Un-optimised drop downs can be a cause of form abandonment.
What I found in my research was that some sites had replaced drop downs with radio buttons. Drop downs accounted for a greater percentage of fields (35.94% to 27.66% for radio buttons) but my favourite, and the second highest scoring site, had four times as many radios as drop downs. One of the lower scoring sites had 28 times more drop-downs than radio buttons (they had 28 drop downs and one radio button).
Here’s why I believe that radio buttons beat drop downs:
- Radio buttons show you all the potential answers, making it easier to read and absorb
- Radio buttons can be styled more easily than drop downs, making them more attractive and easier to engage with
- Radio buttons require less clicks (or key-presses)
Here’s an example of the same question being asked with a radio and a drop down, and my analysis of the results:
Form uses radio buttons for questions (Tesco Insurance)
Form uses drop downs for question (LLoyds Insurance)
Results from Example:
- It was moderately faster for the user to click the radio buttons
- It took two less clicks in total for the user with the radio buttons
When to use radio buttons:
- If the answers is binary (yes/no, male/female) OR
- When the list of options is small, and can be displayed on screen (See example below that has six options)
My advice is to deploy and test any switch from drop downs to radio buttons, then to analyse the user engagement with the field and the impact on conversion rates, time to complete and the point at which users abandon the form.
You can still optimise radio buttons
Have you ever clicked a drop down and you’re presented with a long list of unordered options? Unless your answer is visible you’ll have to scroll down scan-reading each option until you find the right one. Thankfully I’m seeing this issue less and less, but it’s an example of how you must optimise the answers. The same is true for radio buttons.
Optimise your radio buttons by having the most selected option first, and then flowing down to the least selected. And/or leave the “none of those / other” option to the end. Here’s a great example from Tesco, and it shows how you can break the “three option” rule I mentioned above and still look good.
Generate Answers Automatically So Users Don’t Have To Answer Them
As an example, let’s say that one of your questions is title (Mr, Mrs, Miss etc) and a second is Sex (Male, Female etc). One, in almost all cases, is directly linked to the other and the sex could be pre-selected from the answer to the first question. I think that asking for both is unnecessary in most forms, but I wanted to highlight an obvious way to generate an answer automatically.
Let’s take a different example – you ask the user for their vehicle registration, then later ask them for the make, model, age and type of car. The first question is directly related to the other four, and if you can access a database of car registrations you can pre-fill the data, or not ask for it at all. This gives you a challenge: what is the internal and external cost of us accessing that database, and the expected reward (in conversion rate and revenue uplift) of making that change. From my analysis of car insurance companies almost half have determined that it will benefit them.
In general every field you can remove, or reduce the complexity for, will give you an uplift. In a long form you have a lot more fields to try to remove. If you can’t remove the field, then how can you make it easier? I talked earlier about pre-selecting the most selected option, but there’s a world of data out there that you can absorb to make someone’s application easier. Social logins tried to do this, and some sites with shorter forms allow people to pre-populate some fields by logging in via their social account. For a long form this won’t be as useful as social accounts tend to contain just basic information on a user, so the challenge of reducing fields is bigger.
There are some easy wins to generate answers automatically:
- Use IP lookup to automatically answer questions about country
- In some countries you can use the company number to pre-populate fields about an organisation. This could reduce three or four fields down to one
- Use Postcode/Zip code lookup to automatically answer address questions
- Use Title to answer a Sex question
- Use Telephone Number to lookup country and telephone provider
- Use a sign-in (Facebook, Google, Twitter) to get core details (Email, Name, Sex, Location) from the user
As well as answering questions automatically you can adjust the potential answers automatically. One example is that you ask for date of birth, then later ask the user how long they have had their driving license for. The answer could be adjusted to range from 0 years to the maximum (their age, minus the minimum age to drive). The impact of this is less than providing the full answer, but if you can reduce the number of answers to a question you will reduce read-time and effort to answer the question.
Another example of reducing the range of an answer is within a date selector. If you show the user a calendar then ensure that they can’t select irrelevant dates. If the user has to be over eighteen then don’t allow them to select a date of birth that would make them younger than that. A further issue with date selectors that include drop downs for month and year within the UI, and that are for a future date rather than one in the past, is that the month drop down is linked to the year, but often appears first. If the current month is November 2017, but you want to select January 2018 then the month list contains just November and December. The user has to select 2018 in the year, then go back to the month.
Make common answers even easier to select
I talked earlier about automatically selecting answers that are statistically likely to be correct (for example, if 95% of your sales are to females, automatically select “Female” if you ask for the users sex). There are other ways that you can make it easy for users to select a common answer.
- In a drop down put the most commonly selected answer at the top. An example of this is a country drop down, where the top one to three countries are shown at the top of the drop down. I suggest that a visual break is then added after these items, and before the rest of the list, so that the user knows that the items at the top have been put there for a reason, and after the break the list continues. I’d also suggest that the items at the top of the list are duplicated in the full list, in case a user misses the prioritised item and scrolls down to the full list
- For date selectors (either multiple drop downs for day, month, year OR a text box) use buttons to allow users to select common dates. The functionality could be as simple as populating the drop downs or text boxes with the relevant value when the button is clicked. The time saving for the user is significant.
In the example below you can see how Go Compare allow a user to quickly select two common dates. This one-click approach saves the user a significant amount of interactions and time.
Should I hide questions on my long form, then reveal them as the user fills in the form?
In my experience:
- Yes, if some questions are only relevant if the user has answered a certain way on a previous question AND
- Yes, if you don’t do it “all the time”. Don’t have the user hate you because every time they think they’re making progress another question appears
Users don’t like forms that grow because they’ve already mentally allotted a time and effort measurement to your form. They scanned to see that there are around 20 fields and from scanning the top of the page they can see there’s about five steps to complete and suddenly a new field appears. That challenges their belief that they can complete the form and causes them discomfort so use “surprise” fields in moderation.
The opposing view is that for some users the additional question won’t appear. They won’t see a reduction in form fields but they won’t see a field that’s greyed out, or says “not required” next to it.
I hope that you found my advice on long-forms useful. If you’d like to talk more about my research use the Intercom live-chat in the bottom right of the browser window to message me directly