Homeowner Application

Homeowner Application

Startup
Product Design
Fintech
TIMELINE
2022 (1 year)
MY ROLE
Design Lead (Project Management & Product Design)
THE TEAM
Product Design - Thomas Griffiths Graphic Design - Taylor Newman Copywriting - Anita Chauhan
CONTEXT

Fraction is a Canadian-based financial startup that provides a new solution for homeowners looking to access their home’s equity without needing to sell. Fraction stands out from the traditional Reverse Mortgage and HELOC approaches as it eliminates many of the usual restrictions and conditions. The biggest benefit of using Fraction is the removal of monthly payments, homeowners can now prepare for retirement, explore investment options, pay off their debt, and much more, without the worry of monthly payments.

SCOPE

There are a few ways homeowners can begin their funding process. The first approach is to partner with a broker and have them handle the funding process with Fraction. The second approach is for the homeowner to handle the funding process and submit their application through Fraction directly. This latter approach would require an application flow that would collect relevant user information and pass the information to the underwriting team to assess the validity of the deal.

The homeowner application is therefore the core facilitator for starting prospective clients on their funding process with Fraction.

This project was an iteration of the first version of the application flow. The aim for V2 was to tackle a variety of pain points and general feedback received after the first version was launched.

These included:

  • Reducing the number of independent inputs and grouping them into logical clusters to reduce form fatigue and adjusting flows for a single applicant vs. multi-applicant process.
  • Introducing a visual upgrade to match our soft rebrand.
  • Using third-party services to provide a pre-fill path for users.

APPROACH

Reducing the number of independent inputs and grouping them into logical clusters to reduce form fatigue and adjusting flows for a single applicant vs. multi-applicant process.

For the V1 homeowner application, we separated all form inputs into individual sections (similar to Typeform inputs) in hopes that input isolation would bring more focus and clarity to users progressing through the flow. This thinking was also tied to bringing an easier experience to our older user group who may have a difficult time navigating web-based applications, by limiting the number of actions they can take in every step.

This approach however led to a high number of drop-offs throughout the flow. Drop-offs were random and not clustered to specific inputs, they also primarily happened mid-way in the flow. Form fatigue was the apparent culprit and our initial hypothesis was incorrect regarding how we displayed inputs.

Going into V2, we knew that reducing form fatigue was the greatest priority. The approach we took was to group inputs into relevant buckets based on the underwriting team’s suggestions. They would separate incoming deals into personal and financial categories before analyzing the validity of prospective deals.

The list of navigation categories:

  • Deal type
  • Property info
  • Loan info
  • Applicant
  • Financials
  • Product offer
  • Review

Reducing the number of independent inputs and grouping them into logical clusters to reduce form fatigue and adjusting flows for a single applicant vs. multi-applicant process.

Just before jumping into V2, we had completed a soft rebrand at Fraction. This entailed revisiting the branding and UI. We had reached a level of design maturity that had not yet been reflected in our visuals since the company’s inception. The rebrand made us look back at previous products we had designed and determine how we could bring it to light with this new direction. The homeowner application was the perfect product to start with.

Reducing the number of independent inputs and grouping them into logical clusters to reduce form fatigue and adjusting flows for a single applicant vs. multi-applicant process.

A further step we took to reduce form fatigue was to introduce pre-fill in the homeowner application. By connecting with third-party authenticators, we could ask for one input and have the user verify on their end, allowing us to pull relevant data and populate most of the application for them.

We present the pre-fill prompt to the user at the beginning of the application flow. If the user proceeds with the pre-fill then we ask for a phone number and send a confirmation code to the provided number. Once the code has been verified, we can pull data tied to the user’s number and populate relevant inputs with the data provided by the number.

All of these approaches are taken with the ultimate goal of streamlining the application process and ensuring that users have a pain-free experience. We know that forms of this length, that also ask for sensitive financial and personal information, are easily susceptible to abandonment. Trust and security are vital to the user, and introducing these verifications help build that.

HAND-OFF

The hand-off process at Fraction is quite straightforward. All products are designed in Figma and are placed in their own project space. A project is separated into 3 distinct file types: workspace, prototype, and hand-off.

The hand-off file type pulls screens from the workspace. We turn every completed workspace screen into a component and use an instance of that screen in the hand-off.

This allows for a few things:

  • Engineering and marketing can access the final screens without the worry of accidentally breaking something (by making hand-off “view-only”).
  • The hand-off file becomes the “source of truth” for any project.
  • Updates made to the workspace can be easily pushed to the hand-off when published.
  • By splitting up the file types, we are reducing the memory load placed on Figma.

MEASURE OF SUCCESS

Once the homeowner application (V2) has been implemented, an immediate variable we can start to measure again is the drop-off rate. If the drop-off rate is the same as before, then we will plan to revisit for a third iteration to try and reduce that number. We need to also be aware of where the drop-off rates occur. If we find that they are random between input clusters and are mainly occurring in the middle part of the application, then it is easy to assume that it is a fatigue issue. If, however, they primarily take place in specific clusters, then the problem is more localized to those parts of the form and further investigation will be done there.

More of My Work

Directing at a Design Agency

Directing at a

Design Agency

Agency
Leadership
Multi-industry
Broker Dashboard

Broker

Dashboard

Startup
Product Design
Fintech
Establishing a Design Philosophy

Establishing a

Design Philosophy

Startup
Leadership
Fintech