Gradible Loan Evaluation Tool

January of 2015 marked a significant pivot for Gradible. We made the decision to move from a task-based platform to a self-serve loan evaluation tool.

My Role

As the Head of Design at Gradible, I was responsible for designing, user testing, and iterating our loan evaluation web application. The key collaborators included:

• Product Design: Me

• Product Management: Lee Smallwood

• Engineering: Zachary Ontiveros

The Discovery

Address The Core Problem

Our initial business model was a platform that worked as a marketplace for flexible online tasks. Individuals with student loans could complete tasks for a virtual currency redeemable for direct student loan repayment. However, as with all marketplaces, there are two sides, and we struggled to scale the business side of the marketplace. 

Throughout our time building the flexible task marketplace, we had continued to offer free loan evaluations to our members. Ultimately we realized that additional income was a potential solution for helping borrowers repay their student loans, but frequently our members were eligible to make adjustments to the way they were repaying their student loans which could offer the same kind of relief as additional income, and in some cases even make them eligible for forgiveness.

We had witnessed demand for a programmatic, self-service loan evaluation tool and identified that there wasn't one in the market, so we made the tough decision to pivot the business in this direction. 

The Vision

Replace the Callcenter

In addition to the functional challenges of building a reliable, comprehensive, and accurate recommendation calculator, I had significant work to do to identify how the user data would be collected and the output would be displayed. The goal was to create an experience for the user that was simple, visually clean, and which inspired trust and authority, ultimately leading to actionable recommendations that a borrower could follow to adjust his/her loan portfolio.

With Stephen Anderson's UX Hierarchy of Needs in mind, I was also aware that to build viral user acquisition that didn't require paid advertising, we would need to rely on the product experience reaching a level of delight that would warrant social sharing. 

The Framework

Structuring the Experience

Once we had mapped the inputs and outputs required for the app, I could begin to structure the content. I used Jesse James Garrett's Visual Vocabulary to represent the architecture of the app. Adopting a numbering system early was beneficial, helping our team stay in sync.

Setting Design Direction

I took a top‐down approach to defining the experience of the new application. Through sketching and storyboarding, I generated ideas about the arrangement of UI, data elements, and interactive behaviors. My vision began evolving into something tangible with a high‐level design language and a distinct anatomy for the app.

Structurally, the new application broke down into two fundamental stages, the information gathering stage (inputs) and the recommendation stage (outputs). 

Inputs

To simplify the process for potential users, I decided to present the required questions to the user one at a time, but to keep the user informed and motivated to complete the funnel, I designed a progress bar as a form of encouragement.

The majority of the personal inputs (marital status, occupation, etc.) were single, drop-down questions, but the loan input section required added complexity. In lieu of an API connection to the member's student loan servicer, we were initially forced to have the user add their loans individually.

Output

One of the major challenges of designing a financial application is striking a balance between being comprehensive and digestible. This was my primary concern on the recommendation page.

As you can see above, I opted to present a visual comparison between the user's current repayment plan and our recommended adjustment. Below the comparison graphs, the user could toggle between tabs that presented the alternate plans for which he/she was eligible. And finally, below the fold the user could explore the written content that detailed each plan and highlighted the pros and cons of making the adjustment.

The Refinement

Testing With Users

With a tangible prototype, it was time to put the app in front of some borrowers searching for help evaluating their student loans. Over the course of two weeks, we brought in a dozen student loan holders that were not currently Gradible users and had them create accounts, run through the onboarding funnel, and evaluate the output from our recommendation tool.

Through the in-person, moderated usability testing, we were able to gain insights into what the user was thinking, what challenges were arising, and what certain portions of the onboarding process were difficult to understand.

It became clear very quickly that we had some serious issues we needed to address, including UI elements, functionality, but primarily in how we were packaging the output recommendations.

Visualizing the Journey

After compiling the user feedback, I used customer journey mapping techniques to visualize the user's experiences across various touch points in the application. This exercise allowed us to identify specific pain-points, while understanding where we should focus our attention in the next iteration. Adding aspirational emotional states provided goals for how we wanted the designs to influence users.

I summarized our findings from the user testing sessions and created actionable Project Requirement Documents to address the issues that users were experiencing. 

Input Updates

During our testing sessions, two primary issues became common themes during the input flow of the application. 

1. The progress bar was vague

2. Entering loans one-by-one was prohibitively arduous

To address the progress bar ambiguity, I mocked up a new iteration that more clearly delineated the completed, active, and future steps in the funnel. I also collaborated with our developer to create an interaction design that more clearly identified the transitions between sections of the funnel.

To solve the loan entry issue, I leaned heavily on our developer to determine how we could possibly import each user's full loan portfolio without API technology from Federal Student Aid (FSA), the overarching federal body that oversees the student loan program.

While our developer created a proprietary sync function that leveraged the user's FSA ID to download their loan portfolio (with their permission, of course), parsed the loan data, and recompiled it an editable and digestible format, I updated the UI to match the new functionality and address other issues identified during testing.

Output Updates

The most fundamental issue we identified during user testing was the confusion users experienced when attempting to consume the output from their evaluation. Although we had been providing loan evaluations for the previous year and a half, we had failed to perform adequate, additional user profiling to identify the potential personas likely to use our application before beginning to prototype and design.

After having a significant number of people interact with the original designs, we identified three primary archetypes (Struggling Sally, Forgiveness Fran, and Refi Roger) interested in the evaluation, and the differing motivations of these users ultimately informed the restructuring of the output display.

The original designs had swung too far in the direction of being comprehensive, showing the user all potential options for which he/she was eligible. This proved to be confusing and overwhelming. We realized the users wanted to do one of three things.

1. Lower their monthly payments

2. Identify potential forgiveness opportunities

3. Pay off their balance as quickly as possible

With these motivations in mind, I restructured the output page accordingly with a tab that identified federal loan modifications to limit monthly payments; a forgiveness tab that showed federal, state, and occupation-dependent forgiveness programs; and finally a refinancing tab that introduced private loan refinancing to those members likely to qualify.

Specifically within the Lower Monthly Payment tab, we also made additional adjustments to what content was shared and how. Originally we showed all the plans for which an individual qualified, but we realized this was unnecessary and shifted to only showing the most advantageous plan, lowering the borrower's bill the most. 

Though the original visual displays were useful for some users, an overwhelming majority preferred being presented with the "high-level impact" numbers first including new monthly payment, number of payments, total paid, and amount forgiven.

We moved the graphs and charts below the fold and also created videos and pro/con charts to help users that would consume the information better in varying formats and mediums.

The Impact

With the updated design, interactions, and content structure we released the updated application and remeasured our key conversion metrics and found the following improvements:

Loan input completion rose from 50% to 91%

The number of users clicking-through on our recommendation calls-to-action increased from 8% to 15%

Takeaways

The shift from a task-based platform to a self-serve loan evaluation tool was a defining pivot for Gradible and one that required collaboration and a willingness by all team members to work outside of his/her functional area and comfort zone. In a small startup environment where speed is often valued over deliberation, mistakes are inevitable, but so are opportunities to learn.

Urgency and hubris resulted in inadequate user research at the outset of the project. Having spent 18 months working with our customers led us to believe that we understood exactly what they needed. However, with a change in business model came a change in users, and ultimately a change in our "typical user profiles". 

I could have saved valuable time redesigning by testing our designs in a lower-fidelity medium like wireframes before building a high-fidelity prototype, which required development resources. Lesson learned.