Eye tracking has long been used in the fields of UX and CRO to accurately map where a user’s focus is when navigating a website. There have been many practical conclusions that have come out of this research such as this article published by CXL last year.
However, as form specialists, we wanted to hone in on what eye tracking could tell us about web forms and how to improve their user experience. In this article, we’ll explore some of our biggest takeaways and how they can apply to your own form design.
Before we dive in, it’s first important to highlight how we came about our research. We partnered with Nudge Insights, a UK based behavioral science consultancy to conduct a study on how users interact with form flows and fields. Using state of the art eye-tracking technology, we got users to make their way through six UK financial forms:
- Credit card applications – Post Office, Halifax
- Car Insurance – GoCompare, RAC
- Loans – Santander, Little Loans
While straight measurement of time spent completing each field is a valid measure (and one supported by most form analytics tools), we wanted to take advantage of the technology to track specific eye-based metrics, namely:
- Fixations – A fixation is essentially when the eye settles and focuses on a particular part of the form (remaining stable for a minimum of 60 milliseconds), indicating attention.
- Saccades – A Saccade is the rapid eye movement between two fixation points.
When pieced together fixations and saccades make up a scanpath.
The findings and conclusions in this article are all based on the assumption that the smoother the scanpath (i.e. the lower the fixation count / duration), the better the form experience for the user.
High fixation counts and durations at a particular point in a form indicates that the user had more difficulty in completing the field or section.
Six Key Findings
As noted above, these conclusions are predicated on the assumption that guiding your user quickly and efficiently through the form is good. Distractions, delays and confusion are bad. Here are our takeaways.
1. Use Text Fill rather than Dropdowns for Date of Birth
Previous research has shown that dropdown menus provide a poor user experience in forms. These studies have used time or click based methodology to demonstrate how dropdowns create greater friction than a text or radio based interface. Our research reinforced these conclusions based on eye tracking evidence.
As part of the study, Nudge Insights looked specifically at the date of birth field on each of the forms. It’s generally thought that formatting the DOB field should be relatively straightforward—it only requires the day, month and year to be input. Although there are various ways of structuring this field, most forms settle on text fill, drop down or some combination of these elements.
The below table shows each Form against the DOB format used and the average eye fixations that study participants used when filling in the field.
The most obvious pattern is that, with the exception of Halifax (more on that later), the forms using text fills have lower fixations than those using drop down menus, implying that they deliver a smoother user experience. Does this tally with how the user interacts with the form? Take a look at these two scan paths. The first is for the Post Office form which statistically performed the worst in the study.
An associated scan path from the field essentially how the user’s eye is moving and focusing. Notice how they are forced to flick their focus up and down significantly.
Compare this to the Little Loans form which opts for the simple text mechanism.
The combination of the average fixation data and the raw scan paths indicate a clear difference in usability and efficiency of the two methods.
Practical Takeaway: Use a text field format over drop downs for your date of birth fields (and likely for most other date fields).
2. Don’t jump the gun on error messages
We noted above that Halifax was the exception to the general pattern of text fill fields DOB averaging lower eye fixations than drop downs.
Why would that be? At first glance, the interface doesn’t look that different to the Little Loans one.
Yet the scanpaths are much longer and less compact than Little Loans:
Closer inspection of the user videos revealed the causes.
Firstly, as soon as a user completes the “Day” part of the field and focuses into the “Month” an error message is displayed.
This early error message distracts the user, driving the eye movements upwards from their original position. This is especially unfortunate as the message is not even necessary. While research has shown that inline validation can smooth user experience, in this case the user has not even entered a value nor left the field before they are being shown the big red writing. Premature introduction of an error message whilst the user is still inputting information creates stress and slows the user down.
The second factor is that the date of birth question has fallen at the bottom fold of the page. When the error message triggers (which it does every time!) the text fill boxes are pushed below the fold so disappear to the eye. The user is forced to scroll to continue interacting with the field, hence the strong vertical pattern in the above scan paths.
These issues are a salutary warning to not rely solely on “best practice”. Although we’ve established that text fills are, in general, the most efficient mechanism for date fields, if you blindly implement them without testing the execution you may still be creating unforeseen issues in the user environment.
Practical Takeaways: Don’t trigger error messages until after the user has completed a field. Road test your form to avoid unintended usability issues.
3. If your error messages are not clear or sited correctly you will confuse the user
The six studied forms took different approaches on placement of error messages which provided an opportunity to compare them against some of the received wisdom on where to place error messages.
The most pertinent example that underlines why that wisdom exists in the first place was the personal details section of the Santander form. They took the approach of not notifying the user about any errors until the form was submitted. This message was generated at the top of the web page:
With such a message, you might think that when you found one of the mythic red asterisks there may be some indication of what the error might be. You would be sorely disappointed to see the below.
With the slight exception of “Home phone number” there is no guidance for the users once they have taken the trouble to scroll back up to the top of the form to get the general error message and then scrolled back down again to locate the offending fields.
While we would definitely expect such a pattern to lead to unnecessary form abandonments, what effect does it have from an eye tracking perspective? Take a look at this example scan path from a user who has made errors in the Santander form.
Compare this to Little Loan’s method of using inline validation to communicate the error immediately and to provide some further guidance.
This results in a much more compact scan path for users who enter invalid information, implying a smoother journey and better user experience.
Practical Takeaways: Deliver error messages next to the relevant field and trigger them as soon as the invalid information is entered.
4. There is a usability cost if you ask for the same information multiple times
The debate about whether you should ask for users’ email twice usually centres on UX versus avoidance of incorrect information on your database. There are various articles that cover the arguments so we won’t wade into the pros and cons here. Rather, we will see if the hypothesis that asking users to confirm their email causes UX issues is backed up by our eye tracking data.
That said, as well as “Confirm Email” requests, many forms compound this by asking for multiple phone numbers; sometimes as high as 3 different ones. Do they really need that information?
The below table shows the average number of fixations and the average duration of all fixations during a user session completing their personal details.
While this is not conclusive, the general trend is; the easier the input requirements (email confirmation + phone numbers), the lower the number of fixations required to complete and the less time spent on those fixations. This underscores the hypothesis that such requirements introduce friction to the UX.
Practical Takeaways: Don’t ask for email confirmation or multiple phone numbers unless you have a clear reason to do so.
5. Streamline the UI to minimize cognitive load for the user
When looking at the relative form sections asking about Employment details, there was a significant difference between the best performing form (Halifax) and the worst (Santander):
Why is this difference so marked? At first glance the forms look pretty similar.
The most obvious difference is that Santander asks for additional details such as employer address which, as extra information, will inevitably require greater concentration than a shorter form. It is not enough to explain everything, however. There are two other factors at play.
Firstly, the UI around the “Job Title” field.
This looks like it should be a free text box where the user can enter anything they like. That is not the case though. Submitting an answer that doesn’t match the list that the back end holds gives the user a red asterisk (and, like previously, this is not verified inline but upon form submission).
This issue is compounded by the lack of any guidance on what has gone wrong. In the above example the system would accept the answer “Teacher” but that is not clear – the only way to get any type of help is to click on the question mark which delivered guidance which is still vague.
The eye tracking showed a cluster of fixation points gathered closely together around this field, indicating that it required a higher level of cognitive effort to complete.
Halifax took a different approach:
They opted for a drop down execution which, as we noted earlier, is not ideal. However, when compared to the open-ended, yet restrictive, Santander approach, it at least provides some clarity and guidance to the user, forcing them to select an option to progress. We can probably pick holes in whether the list they use is optimal but from an eye tracking perspective only, it doesn’t perform too badly.
The second factor to consider is the question around employment length. Santander asks the user to input the length of employment, essentially asking them to know when they started and then calculate the time up to the present day themselves.
In comparison, Halifax just asks for the start date and calculates the employment length automatically.
The clear lesson here is to ask for as little information as is needed to get what you need. Methods such as auto-calculation can remove points of friction.
Practical Takeaways: If you have a fairly open ended question (e.g. Job Title) but require specific answers for your back end, don’t make the user guess what is necessary – make it as easy for them as possible. Use auto-calculation where possible to smooth the user journey (if you are struggling to do this, there is some coding advice here).
6. Even “Good” guidance distracts the eye
We are generally big fans of including microcopy to guide a user through your form. However, even with the best guidance, we should always be aware there is a cost that needs to be balanced against the benefit. Look at this overlay of scan paths on the Little Loans’ Employment Details section.
We can see that the users are inevitably flicking their eyes away from the fields to the text on the right. This isn’t to say that adding the guidance is wrong (in general, it’s probably better to err on the side of having the guidance than not), but you need to be clear why you are doing it. In Little Loans’ case, it is not always certain that it is necessary.
In this particular example the form states they need the next pay date to verify the user has income. It is not apparent how this will help the verification and this reason is implicit in the question itself so the guidance may be an unnecessary distraction for this field.
Practical Takeaway: When designing your form, always be cognisant of;
- Where your guidance copy is placed – make it as close to the field as possible to minimise eye distraction.
- Do you need to include this copy? If the guidance is clearly implied in the question consider omitting it.
While these findings probably won’t seem earth shattering to CRO and UX professionals, they still provide further backing for already established hypotheses and axioms as well as providing additional advice on how to smooth a user’s journey through your webform or checkout.