As a company, we were entering the maturity startup phase. We had landed many great partnerships, but we were catering our product too much to their individual needs which was not sustainable.
How can we make the best mobile experience for all of our unique partners, while remaining flexible?
Although our loan origination experience had many paths and entry points, we started with just one fixed path for a proof of concept: the happy path of the new customer experience.
Previously, all of our demos had our logo and our brand colors, which were confusing for partners that were trying to envision their brand in our product.
Our goal was to create a new white-label branded experience, separate from our own brand identity as a company. This way our bank partners could picture their brand in our product.
“Catalyst” is a fake brand that would represent any bank partner. We went with green because it creates a feeling of trust and comfort, but is still a neutral color.
I looked at our primary competitors to get a feel for the market benchmark in originations. While this isn’t more important than user research, it was a quick way to see what our competitors knew that maybe we didn't.
How might we handle large amounts of information on a tiny screen?
At this point, I realized that I had less experience with mobile design. I humbled myself and did some research on mobile form design best practices.
• Vertical, full width field layouts on mobile screens are better than horizontal layout.
• I should put the least sensitive and most motivating questions up front, such as the user's goals.
• I should put the most sensitive information at the end of the form, after more trust is built with the user.
• Progress bars are best practice for showing completion, and lead to a smoother, more transparent UX.
To get feedback from the rest of the design team, I conducted a user journey workshop during which we talked through the first draft of my experience. While this wouldn’t replace insights from actual users, this was a low-effort way to test my design early on.
.png)
.jpg)
Despite the long approval process, there was no congratulations screen. I added a "congratulations" message once the user logs back in and is approved, to give them a subtle moment of joy that is clear yet doesn't distract from the experience.
.gif)
After learning skeleton screens have tons of research supporting a lower perceived loading time, I proposed we implement one for our "Loan Options" screen which takes some additional time to load.
I recognized that clients would still want to make adjustments to our standard experience. I knew it would be important to put our experience in front of real users and get some data to ensure this experience is truly the best in the market. I worked with one other Senior Designer to come up with a research plan and conduct testing to gain some real insights.
Participants were satisfied with the overall experience, information break down, and branding, which signified that we were on the right page.
“This website is clear, it provided me with the details that I need to know like the loan amount, how long I need to pay it off, and the payment methods that are available.” - Rebecca
Users had trouble using the discount toggle on the rates and terms page because all loan options didn't fit without scrolling. This would be an even bigger issue on smaller devices. I removed the discount toggle as it was distracting from the main purpose of the page: to select a loan option. I transitioned it to a card and moved it to a more actionable page: where the applicant has to connect the bank account to make use of the deal.
The loan breakdown section was overlooked by users. I changed the look from a line of text to a more visible “card”. I added this component to our company-wide design system because I identified other areas that could make use of the card to compress information.
After a few iterations and feedback sessions with design, development, and product teams, I was confident in my final prototype. The following prototype showcases the frictionless, recommended experience that we put in front of partners.
Again: how can we confidently say one experience is the best for all of our partners, while remaining flexible?
There were certain areas in the experience which were difficult to agree upon, as there were many trade-offs to consider. I hypothesized that these areas would be good candidates for configuration options where we would provide the client with 2-3 viable options to pick from based on their risk comfort level.
Contract Signing
Our bank partners are the ones liable for adhering to compliance laws. Some banks might want to play it safe and “force” the user to open and read a contract before accepting a loan agreement, while others may be fine with a checkbox.
Page Breakdown
Some partners may prefer to have the loan application process completely on one page, as it would technically be faster. As a cross-functional team, we decided to include this configuration option as it was our current offering and therefore not a big lift for development. This also gave us the opportunity to compare drop-off rates between partners that choose the different options.
.jpg)
This project resulted in a cohesive, mobile-first experience that was consistent across multiple screen sizes. In the process, I became an advanced Figma user after organizing all my files, pages, components, and using auto layout to quickly manipulate every screen into different layouts and sizes.
With the new systems approach we had set up in Figma, all changes came from one source. This allowed us to shorten the time it took us to make a demo by over 50%.
Before, a single demo in one screen size used to take a designer two weeks to create. It needed to be maintained every month to be consistent with all other demos.
After, a demo in multiple screen sizes takes less than one week. It does not need to be maintained.
My favorite impact is that design finally had a seat at the table. Design was empowered to push back on custom changes that were costly and not improvements on the experience. We would now prioritize making changes to the standard experience instead of making customizations for the client - focusing on our "why".
See Next Case Study
OSOW
