Client Mortgage and Protection Platforms and Applications
Sector Financial Services
Role Product Designer
Delivered Onboarding
Tools Figma, Dovetail, UserLane, Mixpanel 
Tech React, Angular and Storybook
Service SaaS
Transactions Business to Business and Business to Customer

A fintech company aims to provide advisors and agents with a comprehensive overview of their client’s financial suitability before they apply for mortgage or protection products. Our task is to develop a dashboard that caters to agents, advisers, and clients, offering varying levels of detail as required.

Historically, the company has offered mortgage and protection products with identical registration processes. However, these processes lack conditional logic, screening, or consistency in data capture format across systems.

So, where do we begin?

Before providing accurate affordability calculations, we must thoroughly review all captured data and its relevance to the calculations.

Let’s delve into it…

The registration process for both mortgages and insurance products is identical.

The form consists of over 10 data points and does not allow users to save their progress and return later.

Users must manually input data, with no provision for automated entry through open banking or identity checks.

Additionally, we find legacy fields duplicating specific calculations, impacting affordability calculations.

  • We depreciated old fields
  • Merged duplicate
  • Split combined terms
  • Moved screening questions and incorporated conditional logic
  • Incorporated a stepped approach to data capture – progressive disclosure.
Form

Form Faster!

The expenses section is where users are asked to enter their living costs during onboarding. The input field reads “Mortgage or rent payment.” The existing form does not use branching or conditional logic.

Users with an existing property may have rent and mortgage payments, but the field does not allow this. Moreover, it does not cancel out any fields entered in the existing property (created by another team).

So, if a user has an existing property they rent out, this would be captured in existing properties and expenses, skewing the affordability calculations!

The ambiguity in the field title is skewing the data captured. Solution: Spilt and capture data separately, backfilling existing line items. If a user has indicated that they do not have an existing property, then display the title as monthly rent paid. If the user has shown that they have an existing property that they live in, capture the mortgage repayment fee. If the user has an existing buy-to-let property, then capture the mortgage payments in expenses under existing properties and the rent income in income from other properties in other income.