Income-Driven Repayment

I worked as the UX design lead for the U.S. Department of Education’s overhaul of the entire income-driven repayment (IDR) application and introduction of a new, more affordable IDR plan.

Problem

The FUTURE Act was a new law that cleared the way for Federal Student Aid (FSA) to build new back-end integrations with the Internal Revenue Service (IRS) to more quickly connect to a student loan borrower’s tax information to calculate family size and adjusted gross income. This was groundbreaking for borrowers, as this new integration allowed seamless transfer of information and more quickly determined eligibility and payment amount right in the application. This was a forcing function for FSA to build a new application process, and launch a feature we call “autorecertification” meaning that an IDR borrower would only need to apply once, and we’d recertify your income each year and recalculate their payment annually without the need for any forms.

Approach

Given the legislative mandate of a new IRS integration, we needed to understand the entire student loan servicing environment (the companies FSA contracts to actually collect/process student loan payments) and what our limitations where. As with most government projects, we were working under tight deadlines.

I started with an initial discovery sprint working with others to interview student loan borrowers on the current experience with repaying loans under an IDR plan. We also conducted usability testing on the legacy application, and held several interviews with student loan servicers to unpack their back-office operations. Our main insights were:

Borrowers are often surprised to find there are multiple IDR plans; 50% have their servicer pick a plan
Paper application volumes are higher than expected, with up to 30% being processed as paper
Critical IDR concepts, like when to enroll and requirements to “recertify” confuse borrowers
IDR borrowers top reason for calling is to get a status update on their application as they wait until their servicer processes their app
Providing documentation of income after the application can be a cause of fallout and requires lots of back and forth with a loan servicer. Servicers spent a considerable amount of time manually calculating plans with and processing paper apps
IDR forgiveness is often misunderstood; many don’t understand remaining balances may be counted as income. Borrowers want more clarity on their progress toward IDR forgiveness

Initial Recommendations

These helped FSA save time and cost early on as the it was before the work was under contract with the development vendor and servicing teams.

Allow borrowers to save applications along the way to gather necessary income documentation (if needed)
Include the option for borrowers to upload income documentation in the application vs. having to mail/process it afterwords
Allow loan servicers to access manual uploaded income documentation within an electronic application; provide a way for borrowers to report their income/pay frequency
Allow borrowers to track their apps via their FSA account
Provide IDR borrowers a payment count and progress toward ID
forgiveness. Provide more clarity around IDR forgiveness to reduce false hope around early forgiveness
Remove the cosign flow (aligns with new IDR regulations)

Provide borrowers an easy and understandable application
Educate prospective IDR borrowers about important IDR concepts
Build trust with borrowers that FSA is handling personal and financial information securely
Empower borrowers to pick a plan that suits their needs
Consider how we're communicating new program changes --what's our communication strategy?
What happens post submission?
Build an experience that helps borrowers understand new IDR
rules (consent, taxes, recertification)
Design an an experience that accommodates borrower's life situations (married, multiple loans, no income) that doesn't compromise UX
Provide delighters throughout the application to reduce users' anxiety of the process (illustations, animations, toast notifications)
Aim for the same time it takes to complete the current IDR app — Early draft of experience goals, our driving design tenants as we shifted into early prototyping.

A user flow of the different audiences for IDR — Mapping the initial experience.

Sticky notes that define the success criteria with the product team. — Defining success criteria with the product team.

Results

After rounds of usability testing, we felt confident in several new aspects of the application and flow.

Early concept showing a borrower an initial summary page.

early wireframes of the IDR app — Early concepts of the IDR application, showing the integration with the IRS.

Early concept showing a repayment plan selection page. We tested this version against a horizontal card option.

High-Fidelity Mockups

A simple splash page serves as an orientation on what a borrower will do in the form, reducing the chances their expectations are misaligned as they begin.

A loading page indicates the application is securely connecting to gather a borrower's tax information. Borrowers really appreciated this feedback and transparency in the application. — A loading page indicates the application is securely connecting to gather a borrower’s tax information. Borrowers really appreciated this feedback and transparency in the application.

The select a repayment plan page on the IDR app. — The IDR application shows a borrower the exact amount they will pay under the plan and also does several “out year” calculations to estimate the total paid. IDR plans are difficult since each year you may pay something different deepening on what your income was. We added status pills that call out the cheapest monthly payment and the plan with the lowest total paid over time.

The final page of the IDR application — A borrower can be done in as little as 8 minutes (average time to complete).

A borrower's dashboard with an action required IDR app — A borrower with a “action required” status on their application.

An IDR app in the "in review" step — A borrower can easily track their application status at any time and get email updates on when it’s processed. This feature’s goal was to significantly reduce the times a borrower called a customer service rep for a status check.

processed IDR application — An application that was successfully processed.

Autorecertification

In addition to launching a new application, business process, and a new user experience, we also launched a new “autorecertification” process. This process allowed us to “recertify” a borrower’s income without them needing to do anything. We would simply email them and let them know if it was happening. If their income changed since their last tax return, they could simply do a recertification on their own and override the automatic one. We knew we needed to:

Provide proper notification to a borrower about payments that are changing and give them time to adjust and recertify on their own
Reduce the burden on borrowers that don’t need to take any action (one win was getting approval to place the monthly payment amount in an email so a borrower doesn’t actually have to log in to view anything)
Make the process feel natural and keep the borrower in control

Early concepts on the customer journey and back-stage actions relating to autorecertification.

Mapping the email and service design for borrowers in an IDR plan.

Draft email for a borrower who successfully “*autorecertifi*es”

Results

Developed and implemented an entirely new income-driven repayment plan and application which reduced the overall time to completion by 5 minutes.
Increased the overall satisfaction score from 82% to 89%.
Designed an “autorecertication” process where student loan borrowers don’t have to reapply each year, saving borrowers millions in lost hours filling out forms.
Significantly reduce paper submissions by marketing the new IDR application and ensuring loan servicer customer service reps drive callers toward the online application.
Helped increase IDR enrollment to more than 10 million student loan borrowers.

Lessons Learned

Early stakeholder interviews were critical to establish trust with the project team, as well as loan servicers back-office processing folks.
Allowing an initial discovery research sprint saved development costs because we could focus on drafting contract requirements with a high confidence in knowing what the system needed to support to deliver a user experience that matches user needs and goals.
Opening up usability testing sessions to the entire project team helped create early buy in for our research efforts.