Responsive Web
•
Product Design
•
UX Research
Company
Date
Hats Worn
Overview
LendingClub Patient Solutions (LCPS) works with medical providers to offer patients financing, providing a simple and affordable way to pay for care. In order to offer LendingClub’s loan options to their patients, providers must first register their practice with LendingClub. Optimization of this registration funnel is crucial, as each registered provider, on average, constitutes 10 loans financed to patients.
Problem
LCPS’s registration flow is a multi-step process that, at points, asks for complicated sets of information and actions, as required by law. The current design does very little to make it easy on users as they try to register their practice. The problems are:
Decreased registrations since Management and Ownership section was added. Since this section was added in May 2018 (as required by law) overall conversion of the funnel dropped from 20.43% to 14.12%. On the specific page where this section was added, conversion dropped from 88.40% to 58.42%, accounting pretty much single handedly for the decrease in the overall funnel.
The current Ownership Information section
Unable to navigate backwards to a previous step to edit mistakes/typos. If there are any errors once the application has been submitted, neither the applicant nor LendingClub’s internal team can make any changes. Applicants are required to redo the entire registration.
Confusion between certain fields. Users get confused between fields asking for similar types of information, and end up inputting the wrong thing.
Users
There are three distinct groups of users who use this flow to register their medical practice with LendingClub:
Office managers (~75%)
Doctors/Dentists (~20%)
Treatment Coordinator/Doctor’s Spouse (<5%)
It's important to note that there are varying levels of experience among users. For example, office managers who are familiar with patient financing and registering with financing companies ran into very few problems, whereas less experienced users were easily overwhelmed.
My Role
I was the sole product designer leading this project from research to handoff, and partnered with the product manager, engineers, the head of product, business stakeholders, legal and compliance team members, and sales/ops agents.
Outcome
I created a new design of the electronic registration flow for three screen sizes (mobile, tablet, and web).
Approach
Speaking with LCPS Agents
Before designing, I wanted to learn as much as I could about the problems users were running into. My first step was speaking with some LCPS sales and operations agents who work with and help providers who try to register. The agents I spoke to have been helping patients register for years, and have seen it all when it comes to registration pain points.
Some specific insights I learned from these meetings that would play a large part on how I approached a solution:
The Management and Ownership Section was a pain because users didn’t understand what was being asked for or why it was being asked, didn’t have the required information on hand, and weren’t always willing to provide the required information.
Submissions with errors were a common issue and are seen about twice a day. As much as 50% of registrations are rejected a week, and half of those are due to typos. There have been providers that needed to submit their application up to 4 times due to errors.
Users confuse similar fields with each other. For example, Practice Name vs Legal Business Name, and Business Address vs Residential Address.
Based on these insights, I knew the new design needed to do a better job explaining why things were required, make it more clear what was required, and be more accommodating of user errors.
Interviewing Past Users
While those meetings with LC agents were happening, I was also working with the sales team to source and schedule providers to interview. We sought out the most recent providers to register with us, so that the process would be fresh in their minds. I had the opportunity to interview users from five recently registered providers about what well and poorly about their registration.
There were two clear patterns of users and behaviors that I uncovered. Based on what I found, I created two personas for users specifically in the context of registering:
It was important for me to consider how we could make registering less painful for the less experienced Flora, while not dumbing it down to a point where we’re introducing friction to Vicky. Both had the same simple goal: get their practice registered as quickly as possible so they can begin procedures for their patients.
Comparative Research
Before jumping into an active state of design, I wanted to familiarize myself with the design of some of our competitor’s application forms. I also took a look at LendingClub’s Personal Loans funnel, to see if there were elements there that I could incorporate. Some specific things I paid special attention to were:
How much information is presented on a given page?
How did the form guide users?
How did these flows show navigation and progress?
What steps were taken to minimize errors?
A few thoughts from my comparative research
Putting it Together
As I learned more and more about the users and their experiences, I iterated on my sketches and low-fidelity wireframes to better solve for user problems. As the ideas became more solidified, I moved into high-fidelity and pulled from patterns within LendingClub’s design system to ensure consistency.
Once everything reached the pixel-perfect stage, I created an interactive prototype on Invision and validated it with users, making adjustments based on their feedback. Some of the most important insights were:
Helper text clarifies confusions about certain fields
Management and Ownership section is a lot more straightforward
New confirmation section conveys the urgency of double-checking inputs
Requests for ability to add multiple doctors
Final Design
It’s inherent in our business to require lots of complicated, personal information. Mistakes are going to happen. In my redesign, I aimed not to necessarily eliminate mistakes, but to make the registration flow more forgiving so that these mistakes don’t become major frustrations and barriers to registering.
Reducing Errors
Both the LCPS agents and users I interviewed indicated that input errors were a huge problem. I tackled this issue on two fronts: providing helper-text on fields that are confusing, and requiring the user to confirm that their information is correct before submission.
Providing Context
Less experienced users didn’t know what to expect from the registration. They were surprised by the amount of information we asked for and were unsure about why we asked for it. My goal was to provide more context into what the information they enter will be used for, and how close they are to completing registration.
Simplifying Ownership Information
The Ownership Information section has been a huge cause of drop-off due to its complicated requirements and large workload to users who don’t have the necessary information on hand.
The new design transforms this section into two simplified subflows.
Note: The new design does includes a slight amendment. Users are no longer required to account for at least 50% ownership
Takeaways
When constraints make error-proofing impossible, make designs error-flexible. We’re not just asking for a lot of information, we’re asking for a lot of complicated information. In the end, there’s nothing we can do about what the law requires. Sometimes, it’s a necessity to admit defeat in one area (eliminating errors), and instead focus on minimizing the damage (make errors less painful).
Let's connect!