Designing the first student loan retirement benefit
Company name changed under NDA. Fortune 100 US retirement and asset management firm, 2018 to 2024.
Overview
Over 40 million Americans carry student loan debt. For many, that debt is the reason they cannot save enough to receive their full employer 401(k) match. This project introduced a new category of workplace benefit: the first product that let employers treat an employee's student loan payments as a retirement contribution.
I was the product designer on a small team that included a content strategist, a research intern, and three engineering teams each owning a different layer of the product: UI buildout, backend, and migration and integration. My role extended past screen design into dev handoff across all three teams, QA, and contributing patterns back to an early-stage internal design system as it matured alongside the product.
The product launched with two strategic employer clients and enrolled at 300% of projected participants. It became one of the most widely cited examples of SECURE 2.0 legislation put into meaningful product practice, and was internally recognized as the fastest discovery-to-launch at Northbridge to date.
A new category of benefit, with no existing infrastructure to build on
This benefit was possible because of newly passed federal legislation under SECURE 2.0, which allowed employers to match student loan payments directly into a retirement account. But passing the legislation did not mean the infrastructure to deliver it existed.
The benefit mechanic
When an employee makes a student loan payment, their employer matches a percentage of that payment directly into their 401(k), the same match they would normally receive for contributing to their retirement account themselves. To receive the match, employees connect their loan servicer during enrollment and certify their payments through their company's benefits portal.
This required Northbridge to verify loan payment data for thousands of employees across multiple servicers, calculate employer contributions, and communicate match projections accurately before any payment had been made. None of that existed in the existing retirement platform.
The infrastructure constraint
Northbridge's existing 401(k) platform was fully hardcoded. Integrating directly would have required an estimated $10 million and five years, according to that platform's PM. With a hard strategic client deadline in place, the product had to be built as a standalone experience first, integrated with a third-party loan-data provider (Finicity) to pull payment data during enrollment, with deeper platform integration to follow in subsequent phases.
That constraint shaped everything: how match projections were surfaced without a live connection to a user's actual retirement balance, how verification state was communicated without a real-time system, and how the experience would need to be designed in a way that could eventually absorb full integration without requiring a ground-up redesign.
The regulatory context
Because this benefit was the first of its kind, the product team worked alongside Northbridge's legal and compliance teams throughout the design process. Every piece of copy related to match projections required approval. Every disclosure had to be precise about what was guaranteed and what was estimated. These constraints were real design inputs, not footnotes. The final enrollment flow reflects them directly.
Research
Over three months, the team conducted 40+ interviews with borrowers across a range of socioeconomic backgrounds and loan amounts, alongside calls with loan servicing advisors to understand what information borrowers were already receiving, and where it fell short.
What we learned
Research surfaced three consistent findings that shaped design decisions throughout the project:
- Borrowers felt cared for by their employer in a way they described as new. The benefit changed how they viewed the company that offered it.
- They wanted to know their estimated match amount before opting in, not after. The value had to be concrete before they were asked to share account access.
- They wanted ongoing visibility into both their loan payments and their accruing match, not a one-time confirmation. The benefit needed to feel like an active relationship, not a set-and-forget transaction.
Three borrower segments
Research surfaced three distinct borrower profiles. Each shaped design decisions in specific ways, particularly around tone, information hierarchy, and how the product asked for trust.
Doctorate holders in public service, teachers, social workers. High credential cost, low salary, often denied PSLF after years of qualifying payments. Debt had stopped feeling like a number and started feeling like a life condition. Many had disengaged from financial tools entirely because nothing had ever worked for them.
Started at $50K+ and spent years aggressively paying it down. Close enough to the finish line to feel the trade-off acutely: every dollar going to loans was a dollar not compounding in retirement. More willing to talk openly about debt. Likely to complete enrollment independently if the flow was clear and fast.
Emerged during interviews rather than from product requirements. Borrowers in default wanted this benefit as much as anyone, sometimes more, but eligibility required accounts to be in good standing. The design couldn't serve them in this release.
Testing two enrollment sequences
Before committing to a final flow, I built low-fidelity wireframes for two different enrollment sequences and tested both with borrowers. The only variable that changed between them was the order of two steps: connecting a loan account, and seeing the projected employer match.
Both sequences ended at the same destination, the same account connection and the same match calculation. The question was whether asking for account access first, or showing the payoff first, changed how borrowers felt about the benefit and how likely they were to complete enrollment.
Option A. Connection first
Borrowers were asked to connect a loan servicer via Finicity before seeing any match projection. For the Weight Carrier segment in particular, this read as a request for financial vulnerability with no stated payoff, and created visible hesitation in testing.
Option B. Value first
Borrowers saw their estimated match amount immediately, before being asked to connect anything. Trust was established before vulnerability was required. This sequence became the enrollment flow that shipped.
Key design decisions
Three decisions defined the shape of the final product. Each one was grounded in a specific constraint, a research finding, or a technical reality uncovered during the project.
Lead with the projected match, not the account connection
We tested two enrollment sequences in wireframes. One front-loaded the Finicity loan account connection before showing any match projection. The other led with the estimated match, showing users what they stood to gain before asking for account access. Users responded significantly more positively to the value-first sequence. For the Weight Carrier segment in particular, being asked to link a loan account before understanding what was in it for them created hesitation. Showing the match projection first established trust before asking for vulnerability. That finding drove the final enrollment order.
Build outside the existing platform
Integrating with Northbridge's existing 401(k) infrastructure would have taken years and cost far more than this project's budget allowed. The product was designed as a standalone experience from the start, capable of operating independently and being integrated incrementally in later phases. That shaped every decision about how match data was surfaced without a live retirement account connection: projected amounts were clearly labeled as estimates, the dashboard communicated a pending verification state rather than a live balance, and the architecture was designed so nothing about the user-facing experience would need to be rebuilt when integration eventually happened.
Design the ineligibility state as carefully as the happy path
When the Ineligible Borrower segment surfaced during research, the immediate product response was to add a generic error for users who didn't qualify. I pushed for something more intentional: a clear explanation of exactly which eligibility criterion wasn't met, what it would take to meet it, and what the user could do next. For a product built around financial inclusion, a generic "you don't qualify" felt like a design failure. The final error states reflect the same care given to the enrollment flow itself, and the segment was formally documented as a product opportunity for a future release.
Design system contribution
This project was built within an early-stage internal design system. Several patterns didn't exist when the project started, including the benefit enrollment wrapper, the match projection card, and the loan verification state components. Where patterns were missing, I created them and contributed them back to the system so they could be reused across other benefit products. The system matured alongside the product, which required building with one eye on the specific enrollment context and another on what would generalize cleanly.
Leading through implementation
With a hard deadline tied to client open enrollment, I coordinated across three engineering teams each owning a different layer of the product. That meant owning dev handoff and QA across all three, and prioritizing cross-team work wherever this product depended on other parts of Northbridge's infrastructure.
Two technical constraints surfaced during implementation and had direct design implications. Neither was anticipated during the discovery or design phase, which is itself one of the lessons I'd carry forward from this project.
Servicer-side two-factor authentication breaking the loan connection
The two-factor authentication step lived with the loan servicer, not with the benefit itself. To calculate each employer contribution, the benefit had to re-authenticate with the servicer through Finicity on a recurring basis and pull the borrower's latest payments. The servicer's own two-factor check could interrupt that handshake and quietly drop the connection, sometimes on the first sync, sometimes months after enrollment. The visible symptom on our side was that payments stopped syncing, with no explanation to the borrower and a real risk of a missed contribution. Since we could not change the servicer's security step, the design had to own the recovery: a clear disconnected state that explained what happened and gave the borrower a simple path to reconnect their loan account and resume syncing, readable even by someone who was long past enrollment and no longer remembered the setup.
NAVIENT's fragmented account structure
NAVIENT issues a separate loan number for every loan a borrower takes out, typically one per semester, and separates subsidized from unsubsidized debt into further loans on top of that. A borrower who financed four years of study could arrive carrying twenty or more individual loans under a single servicer, and NAVIENT opens a second account once the first one fills. Pulled straight through Finicity, that borrower's debt surfaced as a scattered list they did not recognize as their own. I designed the loan confirmation step to absorb the structure rather than pass it along: one row per servicer showing a single balance, with the individual loans available underneath on request. The account layer NAVIENT uses internally is never shown at all. Borrowers confirm what they owe in one line, and open the detail only if they want it.
Summary view
The failure is flagged in place, on the row it belongs to. Every other account keeps reporting payments, so the borrower reads the problem as specific rather than total, and knows which one account needs their attention.
Payments detail
Drilling into the broken account shows what actually stopped. Tracked payments sit frozen at $5,000.00 and nothing new has arrived, which is the contribution the borrower stands to lose if the connection is not restored before the period closes.
One row per servicer
The borrower confirms one balance per servicer. NAVIENT's internal account structure never appears, because it is an artifact of how the servicer stores debt rather than anything the borrower needs to reason about.
Individual loans
Expanding reveals the individual loans behind the balance, each with its own figures, for borrowers who want to verify the detail before they enroll. The disclosure is available, never imposed.
Outcomes
The benefit launched with two strategic employer clients and exceeded projections immediately. Its reception in the benefits industry extended well beyond the initial client relationships.
- Enrollment at launch: 300% of projected participants, with early strategic clients including a Fortune 500 aerospace and defense company and a major national insurance carrier.
- The retention case: Companies across the firm's benefits book were running an average 26% employee turnover rate. Research pointed to compensation and benefits gaps as a driver, and student debt relief as a lever employers could pull. That was the business case that funded this product, and the reason retention language appears throughout the employer-facing material.
- Retirement projection: Based on an average annual match of roughly $1,900, the match calculator projected an additional $200,000 in retirement savings by retirement age. These are modeled figures from the calculator, not measured post-launch outcomes, and they were surfaced to borrowers as an estimate during enrollment.
- Industry recognition: The product became one of the most widely cited examples of SECURE 2.0 legislation translated into a real workplace product. Northbridge's Student Debt program was recognized across the HR and benefits industry as a category-defining offering.
- Internal recognition: Recognized as the fastest discovery-to-launch at Northbridge to date, a milestone that reflected the team's ability to move quickly without sacrificing the research depth the product required.
What I'd do differently
This project moved faster than anything I had worked on at Northbridge. That speed created gaps worth naming honestly.
Finicity proof-of-concept before the enrollment design
The servicer-side two-factor disconnect and the inconsistent NAVIENT account structures were discovered during implementation, not during discovery. If I were starting over, I would have pushed for a technical proof-of-concept on the third-party loan connection before designing the enrollment flow around it. Those edge cases would have been known design constraints from day one, rather than problems the design had to absorb mid-build.
The ineligibility experience deserved earlier investment
The Ineligible Borrower segment surfaced during research, which was valuable. But the "not eligible" state ended up being addressed reactively rather than designed with the same intentionality as the happy path. A named segment in the research phase deserved a named design problem from the start. The final state is better than a generic error, but it could have been more, and the opportunity to build something genuinely useful for those borrowers was partly lost.
Documentation for the teams who inherited the work
This product required two more years of integration work after I rolled off. The teams inheriting it were navigating design choices made under a specific set of constraints, including the standalone architecture, the regulatory approval requirements, and the Finicity dependency, and a cleaner record of why those decisions were made would have given them a stronger foundation. Design rationale is not just useful during a project. It earns its value most when the people who made the decisions are no longer in the room.
