The problem to solve

In 2020, Better.com's capacity to fund home loans was limited due to a bottleneck at the Closing stage of the loan funding process. At a high level, the bottleneck was due to the labor-intensive, manual nature of the work required to underwrite and close loans as well as redundancies in the workflow and reliance on inefficient 3rd party software.

In addition to being time consuming, much of the work required to close a loan is very complicated and needs to be performed by highly skilled members of operations team. From a compliance standpoint, closing is also one of the most precarious parts of loan origination process. If compliance issues go unresolved and a loan proceeds to the funding stage, it results in costly fines and fees.

Increased loan volume placed on an overworked team at a time-critical stage of the process resulted in slower time to fund and lower overall loan quality.

Goals

Since exponential hiring and training was not scalable, our team chose to invest in building new software to support and optimize the closing process. We were working towards three major goals:

1. Reduce overall time a loan spends in the closing stage

2. Increase the quality and accuracy of loans that reach the funding stage

3. Decrease onboarding time for new members of the closing team

Solution

Replace the inefficient 3rd party software with a new, more efficient internal tool.

After a lot of research, we determined the biggest issue with the closing process was our reliance on an inefficient 3rd party software to create closing documents. Reliance on this product resulted in a process that required many manual processes like data transfer between systems, cross-checking values between documents, editing or overriding values and compliance reviews.

Our goal was create the necessary features on our internal platform while improving the UX.

Research

Understanding existing workflows

In order to design the best solution, we needed to understand the existing workflows of the operations teams working on closing. To do that, I spent a lot of time shadowing members of the different teams and digging through their training documents. Then I created a step by step workflows for each team. We used to stress test design ideas throughout the process. Then I used these notes to create a user flows for the current process, which helped us ensure we weren't missing any critical functionality when designing the new solution.

Example workflow I created from shadowing one of our closing support teams.

User flow I created from my shadowing sessions.

Sketching

Brainstorming solutions

Once we understood the existing workflows, my team made lists of required features, functionality and existing friction for each step of the current process. Then we ran brainstorming sessions to dig into how to make the new product smarter, easier and more efficient.

I worked with my product and engineering partners to ideate on a product that would leverage the data our internal systems already produced and layer on features that would alleviate the pain points of the current closing workflows. Once we had a general direction for our solution, I started wiring out various implementation options so we could visualize everything and discuss the pros and cons.

Some early wires that came out of our brainstorm on how users could edit closing forms.

Sketching

Mapping MVP and beyond

After multiple brainstorms and conversations with the closing teams, we mapped out the user flows for our MVP and desired future product functionality.

Find an MVP was really tough. This product needed to be built holistically, because we couldn't ask whole teams to stop using their current software and switch onto the new system until were certain it would not only work but save them time. We ended up including most of the core functionality in the MVP, and moving all "nice to haves" (like automatic compliance tracking) to the future builds.

Our final MVP user journey map.

Our desired future state journey map.

Prototyping

Bringing the product to life

As we were mapping out the MVP functionality, I started prototyping out our vision for the product so we could test it with the various teams that would be using it. We first met with managers from each team and walked them through the prototypes, gathering their feedback.

The initial feedback on the new product was overwhelmingly positive, with a few key asks and changes depending on the team. Based on that manager-level feedback, we began building an MVP of the product in staging, so we could test it with associates using real loan data and allowing them to edit in real time.

The new, simplified editing process in our MVP launch.

Case Study

Quick overview

The problem to solve

Goals

Solution

Impact

Research

Sketching

Sketching

Prototyping

Thanks for reading!