BOB FINANCE: Mobile Loan Form Analysis

bob finance

Bob is an innovative provider of Swiss retail financial products with a focus on convenient digital solutions, smart products, quick processes and outstanding customer service

THE PROJECT

As an interview task, I analysed a loan application form on mobile (see the form here) and made proposals for improvement

APPROACH

In a real-life situation, if I actually worked at Bob Finance already, I would use this approach:

1. Request a copy of the flow diagram for this form i.e. the questions and how the responses at each stage affect the questions and responses at each stage - so that I can identify areas to streamline and legal requirements. If that didn't exist then I would create it.

2. I would then set up something like Hotjar to get statistics on how many abandon the form and where, to improve drop off areas and to be able to measure improvements later and collect data while design improvements get underway (for improvement statistics at the end).

3. Ideally I would interview users who are thinking about taking out a personal loan soon, and learn their ideal approach and pain points with existing sites

4. This is a very long form, so rather than just try to optimise it, I would brainstorm alternatives with the loans specialist, such as:

Reduce the mobile form to lead generation only and email the customer a form to fill in later on a desktop
Pull main decision tree questions to the front of the form, such as salary and expenses and build those in with an interactive loan slider so that the main customer requirement and business requirement are covered off first and other fields are only filled out if there is agreement there (streamline the process and make it the minimum online form. e.g. up-front entry of 'blocker fields' like full-time salary and expenses which form the main decision tree)
Give the customer a clear idea up front of the loan requirements e.g. minimum salary so that people who will not get a loan don't start to fill it out
Personal information can be collected at the end which reduces scaring the customer.

Since I don't yet work for Bob, my approach was to fill out the form with fake information to get a feel for it... this is known as an 'Expert Review'

The current form has a very traditional approach

There are 4 current steps:

1 Personalische angaben | Kontaktinformationen (personal & contact information)

2 Beruf and einahmen (Occupation and income)

3 Wohned and ausgaben (Living and spending)

4 Ihre angebotsubersicht ( Your offer)

IMPROVEMENTS LOOKED FOR

This is a very long form, and that’s not recommended for mobile. There are some ways to cut down the number of fields e.g. with addresses, can ask for the postcode first and then give a predictive text field for the street name and number, which also means the address is fully validated when it is submitted, and other fields can be auto-filled e.g. like ‘Fill with Facebook’.

It's best practise to say up-front how long the form will take (show visually in steps across the top) and give info about what personal data is stored on the customers credit file.

Asking for the firstname first is the wrong approach

People are resistant to giving personal information unless they see the benefit, and this information is not needed first.

Once a customer has designed their loan and feels confident that it will be granted, form drop-offs will tend towards zero

The loan application can develop like a conversation where the customer designs their loan and gives information as it becomes relvent to the decision tree

By redesigning the loan application around the real decision tree, it develops more naturally and big decisions made early on such as 'Salary' minus 'outgoings' which will give an indication of the loan amount and payback schedule available - this can be displayed in an interactive diagram

THE FORM FIELDS - FINE DETAILS

1 Personalische angaben | Kontaktinformationen

FRAU / HERR radio button

VORNAME - (i) as indicated in the document - the (i) tip does not make it clear if all names should be entered or just the first ‘vorname’. E.g. many people have at least 1 middle name. This is confusing to the user.

GEBIRTSDATUM - (i) ‘The requirement for a loan is that they are between 18 and 64. if there are requirements to apply for the loan these should be stated up front, rather than have users start the form and then find out that they are not acceptable. Also, if they are, say under 18 and put in their birth date as 2005, when this is entered into the form, there should be a message as they have added it that they are not acceptable, rather than waiting until they have filled in the rest of the form.

ZIVILSTAND (civil status e.g. married)- are all of these options necessary and for what legal reason in Switzerland?

NATIONALITAT - has a large scroll through of options, perhaps better with predictive text? Use predictive search for fields with lots of pre-defined options.

if the user chooses something other than swiss, then 2 more options appear, which is what residence permit they have, and how long they’ve had the permit for (since month and date)

When asking users to choose their country, occupation, or something else with a large number of predefined options, it’s best to provide a predictive search function to reduce the amount of typing and cognitive load required

zweite staatsbürgerschaft - (second citizenship) - as above

aufenthaltsbewilligung (residents permit) -

seit wann leben sie in der schweiz - Since when do they live in switzerland (why is this written in 3rd person?)

Strasse / Nr (Street name, then number) - Is a bit vague about what goes in which box?

PLZ/ORT - Postcode auto enters the placename (good) , but doesn’t seem to check the street name above. If this PLZ/Ort were entered first there could be predictive text street entry to make sure the address is validated when the user enters it. [When asking for addresses, use a post code / zip code lookup to reduce field entry]

gewunschte korrespondenzprache (required correspondence) - (Deutsch, italian or french) dropdown

Email weiderholen (means to reject?!) (i) erfassen sie eine gultige e-mailadresse in folgendem format - Enter a valid e-mail address in the following format

Telefon Mobil

Telefon Privat - These numbers are different formats, no need to be, a private number could also be a mobile

Tickbox - hiermit bestatige ich die richtigkeit mener personalichen daten und bin mit der nutzung entsprechend den in der datenschutzerklarung gemachten angaben einverstanden

(Hereby confirm the correctness of the personal data and agree to the use according to the data provided in the data protection declaration)

WEITER (Continue BUTTON) -

Error messages - ungultige oder fehlende angaben bitte fullen sie alle felder aus (Invalid or missing information, please complete all fields [and the fields where highlighted in red - good]

Note that I put in an ‘L’ permit and an age under 18 and got - ‘Thank you for your interest in Bob Money. Unfortunately, due to internal credit guidelines and legal requirements, we are not currently able to offer you and offer’. It would be better to tell the user why e.g. you must be over 18 and you must be on an ‘XYZ’ permit, because then the person may become a customer later i.e. when they get a ‘B’ Permit (if that is the rule, I can’t be sure from this)

Error 2 - ihre anfrage konnte leider nicht verarbeitet werden ‘ Your request could not be processed - please call this number’ but no reason was given again, perhaps because my email address had been used previously?

2 beruf and einahmen (Occupation and income)

anstellungsverhaltnis (Employment) - festanstellung (permanent Employment) and other answers - the answer to this sets the fields below.

I did not continue with the form, because there were so many answers whch affected other answers, just suffice to say that I would implement 'BEST PRACTISE' as detailed below.

FORMS - BEST PRACTICE

These links on best practice form design cover far more detail than I can show here:

SUMMARY OF APPROACH

1. Business research - Clearly understand the loan application process - Flow diagram, Legals etc

2. Statistics - set up Hotjar and perhaps Google analytics to see videos of users and understand drop-off points

3. User Research - Interviews of online survey or diary studies or external survey company to give insights - Highlight issues with the product offering, understanding of the product, current pain points. lessons to learn. e.g. see Transferwise.com against their competitor and note Commonwealth bank was the first to allow payments from one Facebook user to another.

4. Expert review of existing form, notes on usability improvements, Competitor review - who is doing it better globally?

5. Brainstorm better approaches e.g. do we use a different approach for mobile, do we align the loan decision tree with the customer experience?

6. Create clickable wireframe prototypes

7. Test prototypes on users, learn and improve

8. Visual design and (UX review if design done externally)

9. Build and UX review and adjustments to UI / any path issues

10. Go live

11. Monitor with GA and Hotjar, identify areas for improvement

12. Periodically keep an eye on competitors, changes in the loans market and legal requirements to continually simplify for the customer.

SOLUTION? A BETTER USER EXPERIENCE FLOW

1. Tick-boxes for main loan requirements up front so that the customer can clearly see what is required to get a loan, and get immediate feedback how they might change their situation to gain one

e.g. 'I am employed full time' (Y / N)

2. Salary and outgoings entered which then give an algorithm based diagram showing the loan amount, repayment period and full repayment amount

3. Accept conditions and give all personal information in an

OPTIMISED FORM

4. Provide document evidence

5. Sign documents and receive money and repayment instructions

Allowing the customer to design the loan based on quick up-front information gives a feeling of control and 'sells' in the result before all the form filling starts i.e. gives motivation to get to the end of the optimised form