Home loan fintech
Home loan fintech
Home loan fintech whose vision is to deliver Australia’s best value mortgage, by radically simplifying the mortgage value chain. Introducing themselves to the world as the “home loan wrecker,” the fintech’s philosophy is to help borrowers to pay off their home loan quickly, through simple ‘hacks’ and a great rate.
case study : address input
We wanted to improve the home loan application by focusing on areas known as ‘blockers’ where customers were unable to proceed with the application due to their inputs or technical issues.
One feature update we decided to prioritise was the step in the application that asked a customer to input the address of the property they were looking to refinance. The challenge we had with the previous design was that customers were unable to move through the application if their address could not be verified by the address web API. To ensure a seamless experience for customers through the application we needed to allow for varying customer address inputs to ensure they would not be stuck on this step.
duration
2 week sprint + extra preparation day before kick off
Tools
Sketch, Invision, Paper and Pen
My ROLE
My role for this project was to help define the problem and it’s impact to the business and customers. I also generated possible solutions (hand sketches), conducted guerrilla testing on the prototype and reported findings back to team in order to iterate on the solution before finalising it for UAT.
1. Why are we doing this?
Problem statement
In the previous design of the application customers were unable to proceed if their address input could not be found in the address web API’s database. It was also unclear for customers that their address input would be validated against an address in the system.
Impact of this problem
Identifying and validating a customer’s address is part of the crucial first steps of the home loan application. If a customer is unable to move forward at this stage it can lead to frustration and an inability for us to capture a lead and convert a customer while also creating a potential detractor. Alternatively, a customer can call through to the customer service team to provide their address details - however this method is much more time consuming and not scalable.
There are multiple reasons why a customer’s address may not be recognised by the address web API or they are unable to progress at this stage in the application’s previous UI.
Customer input does not match what the address web API requires as an input - i.e if a customer inputs the unit and level without a comma such as “30 3 Erskine Street”.
If the address web API service is down/unavailable.
If the customer’s address is not in the address web API system - in cases of new property development.
HOW DO WE JUDGE SUCCESS?
If address web API is unable to validate a customer’s address input there should be another method for customers to proceed through the application. We can measure this by how many times a customer successfully moves through the application upon entering their property address.
2. Validation
what we already know
Through our pilot customers who have used the application, some of their addresses were not recognised by the address web API.
We know through usability testing sessions that some users do not expect the address to be validated upon input and are sometimes unsure why the next button is disabled when they attempt to continue, as the UI does not make it clear that this will occur.
The address input is not accomodating for varying customer inputs.
what we need to answer
Before we proceeded with a solution and pushed it to production we needed to test and validate our hypothesis through a prototype with some users.
We also needed to find out:
Technology limitations of the web address API.
CRM data inputs - what the current required fields were.
More about our customers’ mental models around address inputs.
3. DESIGN
Kick off
In preparation for the kick off and to ensure we came up with a solution that solved the problem, we compiled competitor address input examples, defined the problem and it’s impact to the customers and the business and analysed our previous research.
To kick off the project myself, the Lead Experience designer and a representative from the engineer team met to discuss the problem and potential solutions.
During the kick off we:
Discussed the problem statement and why we were improving this feature.
Reviewed competitor examples - what was working, what wasn’t working and what could be improved upon.
Sketched initial solutions - including different field input options and micro copy suggestions.
Suggested interactions improvements.
Confirmed next steps and a list of questions we had to answer.
POSSIBLE SOLUTIONS
Allow for manual address input if address web API is unable to validate a customer’s address
Improvements to the UI:
Providing visual feedback that search results are loading when the user inputs their address by showing a spinner in the text input field.
Updating the ghost text to ‘Search address’ to provide guidance to users of what the input field will do.
Highlighting the search results with what the customer has inputted - i.e bolding the text so that a customer can quickly scan the results against what they had inputted.
Improve address web API settings, such as:
The input requirements by allowing it to be more forgiving of different customer inputs.
Allowing the search results to refresh when the user retyped the address (previous version maintained the same search results even after a customer retyped their address).
Prototyping
The sketches were refined and the solution was prototyped by the Lead Experience designer in Axure with support from myself.
At the same time we shared the prototype with the engineering team so they could get a head start on build and raise any technical issues.
Usability testing
I wrote up a testing script and organised for five testing participants on the day. I did a call out for participants from within our office who did not have a lot of exposure to the application as they were relatively new to the company.
Together with the Lead Experience designer we tested the prototype with participants.
The goal of our testing was to:
Learn if participants were able to manually input their address into the form.
Identify how long it took to complete the task.
Find out how satisfied participants were with the task.
Check if the terminology made sense for users.
Identify changes required to improve user performance and satisfaction.
Usability testing results
Findings from the testing were analysed and synthesised.
All participants were able to move through the application by manually inputting their address.
Link to the manual address input read “Can’t find address?” And did not indicate what would happen. From this feedback we improved the copy to say “Can’t find address? Enter it manually.”
Manual address input boxes were a bit unclear for participants as some were unsure which field they should input their apartment unit- from this feedback we needed to confirm with engineering how they best wanted to get the data so that it would be accepted by the CRM without a person having to check it manually.
Overall, the prototype of the new solution was an improvement to the previous design, however there were some additional changes to be made before final hand off to the engineering team.
4. RESULTS
Based off the testing we improved the prototype and added in additional specs to the story ticket so that it was ready to hand over to the engineering team. This particular ticket did not require a visual design as the changes were mainly text updates and system related. Since going into production the new manual address input feature has been utilised by customers quite successfully which has ensured that most applications have been able to come through to the CRM without manual input by the service team.
5. NEXT STAGES
From a usability perspective the additional manual input option has ensured that this step of the process is no longer a blocker for customer. However, for potential future updates minor UI improvements can help make the experience more delightful and seamless. For example the addition a search icon to the front of the input field may help set users expectations about what will occur when they type in their address so that the ghost text can be utilised more effectively with an example address.
TAKEAWAYS
It was really valuable to conduct usability testing of the prototype before putting the designs into build as there were quite a few improvements that were made base off their initial feedback. Working closely with the engineering department we were also able to update some of the web address API settings to help improve the experience and work through technical limitations together. Within a 2 week sprint we were successfully able to deliver from ideation to production while conducting research and validation to ensure the right solution was built.
