Responsive Income Validation Tool

The need to match loan amount with affordability is an important consideration in the mortgage application process. To this end a lender will look to documentation provided by the applicant during a mortgage interview to validate their income and ensure that future repayments will not overly stretch a customer's personal finances.

If a customer fails to correctly report and evidence the individual elements that contribute toward an income calculation a repeat interviews is required.

Repeat interviews block the application progress and generate confusion at a time where customers seek speed and certainty.

Through discussion with mortgage advisors we identified that current messaging around documentation requirements was too generic and vague.

The onus was on the customer to identify what income validation evidence they would be required to bring to their interview. As such many customers failed to bring the correct evidence.

Furthermore, during interviews, advisors were spending a significant percentage of available time keying in figures from the documentation the customer had brought with them. A somewhat impersonal and intimidating process where customers were left to wait and twiddle their thumbs.

Mortgage interviews are scheduled by appointment and walk-ins are generally not offered. Many of the bank's advisors will move from branch-to-branch over the course of a week and their time comes at a premium.

Given that income validation is only one of several components within a mortgage interview, we aimed to bring this component out of the interview altogether. This would maximise the time an advisor could dedicated to the other components of the interview and to answering peace-of-mind questions a customer may have.

We would work to allow the customer to complete income validation ahead of their face to face advisor interview. We would provide a link to our tool at the same time that details of the interview time and location were communicated.

If customers were unable to use the tool before they arrived in-branch, staff would suggest they used it while they waited for their advisor to become available. A customer could choose use the tool on their own mobile device via free in-branch wifi, or with a tablet provided by the bank.

The evidence a customer is required to submit during income validation is unique to their circumstances.

Requirements differ depending on the sources of their income. Sources such as full-time employment, self-employment, overtime, benefits, and so on.

We would use the data gathered as part of income capture to provide a personalised list of documentation the customer would be required to bring to their interview.

If the customer had elected not to use the tool before arriving in-branch and thus had not brought the correct documentation, there would be little we could do to mitigate a repeat branch visit. However, offering an 'income validation while you wait' service could still remove the need for the advisor to spend time manually identifying what documentation the customer would need to bring at a later date.

Additionally, a customer could later walk-in to any branch and staff would offer to copy and forward documentation to the customer’s advisor without the need for a pre-booked appointment with a mortgage specialist.

We had defined the problem we wanted to solve, and had quickly developed ideas with regard to how we could proceed. But unlike many banking projects we didn’t have a team of business analysts and solution designers on tap. We were not doing so-called “big design up front”. This was two SMEs and a UX Designer heading into the unknown.

I felt it was important that we didn’t dwell on our initial ideas for too long and advised that I head straight into developing something tangible we could test among ourselves and later show to a wider audience for feedback.

I knew a GUI prototyping tool like Axure wouldn’t cut the mustard here. It’s too fiddly and feature limited. While I feel Axure is valuable for building out detailed UI specifications what I desired was to get real code onto real devices and open myself up all that is possible with modern web technology. I could not be restricted by a tool that abstracts away the full power of the native medium.

I chose build the prototype with HTML/CSS/JS and a smattering of open source frameworks and libraries.

I believe many designers and developers would agree that a prototype should be to some extent disposable. The approach should be to favour speed of delivery and number of iterations over, for instance, the highest standards of code quality and reusability.

With my previous experience as a front-end developer, and having built many HTML/CSS/JS prototypes in previous roles, I had over time built library of foundational code I could put to work on this project. Adding to this code that is freely available from the open source community, I felt comfortable diving straight into building-out something tangible without spending time setting up an overwrought architecture that could have become a limitation during later iterations.

Using the wonderful web package manager, Bower, I kickstarted the prototype project with Twitter Bootstrap and jQuery. I added to this a smattering of open source libraries that would offer out-of-the-box functionality such as the single-page application feel I looking for and some basic form validation that would make the journey feel solid and realistic.

I didn’t spend a great deal of time at all considering reusability of the Javascript I was writing. This in fact bugged me somewhat, I could see where I was repeating myself. But to maintain momentum I favouring a lift and shift approach that would get me as quickly as possible to a complete journey that could be tested on real devices.

The first end-to-end prototype journey, based on our initial ideas, was ready to test after 3 days of hacking on the project. What we would learn from having this tangible artifact to inspect would inform what we would do next.

In total I completed 6 major iterations of the prototype. After completing each I would bring the team together for some collaborative inspection, testing on a number of different devices available to us, trying out different scenarios, and brainstorming on what we could add (or remove) in the next iteration to further address the problem we were trying to solve for the customer and the business. Later on we tapped the SMEs networks to bring mortgage advisors and customers into the feedback loop.

An example of a problem our test and iterate approach raised was that we had no backend to work with. No database within the bank to store the information the customer had provided. There would be no way for the customer to recall their previous calculation and documentation requirements.

If we were to successfully remove the need for the advisor to key in all the components that make up the calculation the results had to be persistent.

We felt it was too much to ask that the customer keep their browser tab active on their device from the time they completed the income calculation to the point they were face-to-face with the advisor. There was just too much that could go wrong technically. For instance, what if the customer hit refresh? It would be back to square one, and that’s not a great service experience.

To solve this problem I looked at leveraging the relatively new localStorage feature available in modern browsers. I could use this store the customer’s calculation locally on the their personal device. This would deliver the benefit of persistence we needed without the overhead of worrying about sending, storing, and retrieving data from bank systems.

Another road bump was came via the relative uncertainty of mobile connectivity. What if the customer had no cellular signal? What if they had reached their data limit this month and couldn’t load the web app? This lead me to implement an offline mode, and an option the customer could use to clear the saved data on their device at any time they chose.

Finally our team presented what we had achieved to the mortgage council. We were praised for our efforts, proving just what could be achieved in a short period of time by two mortgage business SMEs and a UX Designer.