Optimizing Financial Forms: Section 2

‍

Specific Financial Form Issues

1. Individual fields

Financial forms tend to have a lot of fields (31 on average according to Zuko’s benchmarks). This leaves a lot of places where the user experience can be damaged. Many of these questions will be bespoke to the individual form but there are commonalities that come up on most forms. Some of the frequent issues have been covered in Zuko’s general guide but we build on that advice here with finance specific points.

(i) Email

99% of the time, you’ll require your customer to give you their email address to access your service so you’d better not mess up this field.

Information taken from Zuko’s database shows that, out of the common personal details fields,  email address is the one that users spend the most time completing:

People know their own email address don’t they? So why are they spending so long completing them on forms?

The first reason is due to the mobile user interface (users entering their email address on a mobile device take 2 seconds longer than desktop users), and a lot of this is because the mobile keyboard is incorrectly configured. The keyboard setting for email fields should be set to the correct “email” input type rather than the “text” or “number” types otherwise the @ symbol will not be readily available, slowing the process down unnecessarily. Research by the Baymard Institute indicates that 61% of mobile sites use the incorrect keyboard settings for at least one field so you’d better check that you are not making the same mistake.

‍
The second common problem is the insistence of many sites that the user confirms their email address. This leads to them jumping back and forth between the two email boxes to try and get the answer “right”, meaning they spend much more time on the field than they should.

Why put them through this pain? We get that you are paranoid that they will mess up and enter the information incorrectly but it is a terrible user experience and the evidence indicates that they will just copy and paste their answer from the first box anyway, negating the reason to confirm in the first place. Keep it simple and just ask them for their email once. We’re confident that the reduced abandonment rate will more than make up for the occasional person who misspells their address and can’t be bothered to correct it. If you are still worried, install a sophisticated inline verification solution to your form that will prompt the user if they make a common error (missing the @ for example, or using “gnail” instead of “gmail”).

(ii) Phone Number

People don’t forget their own phone number. So why is there often a disproportionate proportion of abandonments for this field?

In short, it is because of the capricious validation that many forms use. Users are confused about what to enter. Country code? Does there need to be a “+”? Include the opening “0” or not? Are parentheses needed for the area code? Include spaces or not? What about dashes?

Studies back up the fact that this field is a minefield for users - 89% of users in this test entered their phone number differently to the requested format.

The best way to mitigate this issue is to remove the need for the user to think too hard. Ideally, accept any format that the user enters; minimize the on page validation and reformat at the back end if you really must. For example, “07772766234”, “+447772 766 234” and “(07772)-766-234” should all be accepted as valid inputs. If you can, autoformat the input as the user types and, if country location is important to you, use smart defaults to automatically geolocate the user and reduce the need for them to add the country code themselves.

Finally, as mentioned earlier, use microcopy to tell the user why you need their number (and make it genuine!). If you truly don’t need their phone number at this stage then don’t ask for it.

(iii) Date of Birth

Again, date of birth should not be a problematic field for the user. The childhood buzz of birthday presents has conditioned that particular moment in time deeply into our psyche. We don’t forget it. Yet forms continue to make it more difficult than it needs to be for us to supply that top-of-mind information.

Firstly, you should make it abundantly clear the date format you are expecting. Is it the American (MM/DD/YYYY) or European (DD/MM/YYYY) convention you are asking for - particularly important if your form spans multiple countries.

Even more importantly, use the most simple format for data entry. This means steering clear of dropdown menus. Dropdowns are problematic in many ways but are especially bad when it comes to dates. Who wants to scroll back decades to find their year of birth? Indirect age discrimination in action.

Date pickers are not much better and can be fiddly on mobile. A far superior solution is a simple, clean 3 text box format involving 8 taps / keystrokes. Zuko commissioned eye tracking research that revealed this configuration was the most user friendly, requiring the lowest amount of eye fixations and attention to successfully complete.

(iv) Social Security Number (or Equivalent)

Unlike DOB and phone number, users are much less likely to have their Social Security / National Insurance / PAN / National Identity number memorized. This may mean they need to leave your form to rummage through their (digital, metaphorical or physical) drawers to retrieve it. As we discussed earlier, you should make it clear upfront that you will require the information so they can locate it before they start to complete the form.

Other things to be aware of when asking for this sensitive information are:

• If you’ve decided to mask the input make sure you have an unmask button so the user can see what they are typing if they are in a safe environment.
  

‍

• Use a simple unified text field to make it as simple as possible for the user - no tabbing or drop downs to complicate the experience.
  

Think:

Not:

• The UK government design service has a good pattern it recommends for collecting National Insurance Numbers. You could do worse than just copying it for your own form.
  

• Use a trust badge if you can. Trust badges have been shown to increase user confidence and improve conversion. If you have credible ones that you can use (for example, if you use a respected third party to verify the SSN) then it will help reassure the user.
  

Stash, an app based Fintech, do this well; displaying their trust badge alongside a convincing reason for needing the information: 

(v) Employment Details

At the risk of banging the same drum over and over, this shouldn’t be difficult. Your customers know what their job title is so why do you insist on forcing them to jump through your hoops to give you that information?

The first item on the list to spook your users is the simple Employment Status question. Consider this innocuous looking dropdown:

Seems simple right? Yet there will be many corner cases that see the drop down and think it doesn’t apply to them. Students? Semi-retired? Part time? Retired with a side-hustle?

Although you may see a simple, mutually exclusive list of categories the user won’t necessarily place themselves into such a comfortable box.

This issue is magnified considerably when it comes to specifying an actual job itself, especially when it comes to insurance forms. The insurance industry has a bad reputation for using any excuse to not pay out on claims. Potential customers are paranoid that if they get an answer “wrong” on their application form they will be denied their due in a future claim so, if there is any doubt, they’d rather drop out now and find reassurance in the arms of your competitors. Either that or they “job hop” - changing their job description multiple times to see if they get a lower quote.

Even if the user is happy to proceed, they will probably be tearing their hair out at the implementation of the field. Often, this form field has a limited list of job titles it will accept. If the user’s finely crafted job title doesn’t match the list then “Computer Says No” - they’ll be politely (or impolitely if you haven’t sorted out your error messages) rejected and have to consider whether it is worth their time trying to shoehorn their (perfectly reasonable) job into your restrictive form field like our friendly Conversion Rate Optimization Consultant has tried to do here:

‍
So how do you get around this? Possible answers are below, in order of preference:

• Consider whether you really need this information and whether you need it now. We get that the insurance industry prices insurance based on job sometimes (vegetable pickers are “riskier” than secretaries apparently). But is it right for you to do it? (especially if it is being used as a backdoor way to segment by gender now it is illegal to price discriminate in certain territories). If you can conceivably remove it without your business model collapsing you probably should. Alternatively, do you need to ask it now? Moving it later in the process when the user is more committed may reduce abandonment on this step.
• Use a free text box for the user to describe their job. Do the work at the backend to categorise the job into the basket you need rather than making it up to the user. It’s not beyond the wit of today’s AI to match most job titles to the relevant category.
• Use a smart search function. As the user types in their job title, give them an auto suggested list of relevant options from your list to select from. This shouldn’t just be based on character match but subject match derived from previous user behaviour. You can build this yourself or buy it off the shelf from an appropriate vendor. The UK comparison site Compare the Market is a good example of this implemented well.
  

• Finally, and we feel dirty saying this, if you have no other option, you may want to use an exhaustive drop down for the user to choose from. We really don’t recommend it for all the reasons outlined previously, but it may be a better option than having the user struggle to guess how you’ve categorized their life’s work.

(vi) How long have you lived at this address?

“I don’t know. Mabel, when did we move here? Was it January or February ‘73?”

Some financial forms, particularly ones involving a credit check, require an address history over a certain time period (typically 3 years). It can be fiddly for a user to remember all their previous details, particularly dates, so you should make it as easy as possible for them:

• Ask up front if they have lived at the address for 3 years. If they answer “yes” you can cut out all the nonsense about dates, etc and allow a large proportion of your users to progress with minimal fuss.
• Start by asking for the year someone moved into an address (generally easiest to remember). Only ask for the month if it is necessary to determine if the 3 years has been reached.
• Never ask for the exact date of moving. They won’t know.
• Always auto-calculate the time for the user based on their inputs. Don’t force them to work out how many months Aug 2018 - May 2020 is.
• Tell them at the start of the form if they will need to enter this information.
• Make sure there is a save function. If they have to leave the screen to search for the details they don’t want to come back and find that all previously entered data is lost.
• If they are struggling, you may want to prompt them where they could find the information. Amazon’s profile history is a great repository of information about previous addresses for many people.
  

(vii) Income / Wealth

“Asking for personal wealth details often is the biggest trigger for form abandonment. People won’t share that information if they don’t trust you yet.” Matic Kasnik, Conversion Optimization Expert, UBS

Unlike many of the previous fields, this one actually is difficult. Even if the user knows their income / wealth (many won’t know the exact figure), it is sensitive personal information that people are reluctant to part with.

Some advice to smooth this part of the form:

• Explain what you are asking for. As noted in section 1, just because you know what gross income or net assets are it doesn’t mean that the user does. Explain in clear language what you need from them.
• Don’t ask if you don’t really need the information. Your marketing department may be clamouring for data to create audience segmentations but you can’t segment someone who doesn’t give you the information in the first place. Let the marketers base their analysis on different metrics while you concentrate on providing the smoothest user experience.
• Provide hints on where to find the information. If you need something specific from a pay cheque or tax return, show a visualisation of where the exact figure can be found.
• Use income brackets rather than a specific number. You are not the taxman so you probably don’t need to know your customer’s income to the nearest penny. Using brackets makes it easier for the user - they don’t need to calculate their income exactly and it also reassures them that you are not going to be delving too deeply into their personal affairs. Be slightly careful though; set your brackets evenly. Don’t have a bracket that is obviously low or borderline as users in that category may believe that you don’t really want them. For example, users in the sub $60K bracket here will be a little suspicious:
  

• If possible, include a “Prefer not to answer” option. Many users are so sensitive about income questions they will be put off. If you give them an option to avoid this, your form conversion rate should improve. If it is absolutely necessary for you to have the information, consider whether you can get it any other way (through a follow up phone call, survey or email, for example).

‍