Lexington Law Dashboard Redesign
Leading end to end design and initiating early product concepts for Lexington Law's paid credit repair experience.
Year:
2025
Timeframe:
12 weeks
Tools:
Figma, Maze, Claude
Category:
Product Strategy
01 • Overview
Context
Owned by Credit.com, Lexington Law is a U.S. attorney-model credit repair firm offering a B2C SaaS product. Clients pay approximately $139.95/month for help identifying and disputing negative items across all three credit bureaus. The average user is 35–45 years old, starts with a credit score of 550–650, and has an average of eight negative items across their credit reports. Many are working to improve their credit in preparation for a major purchase, such as a home or auto loan.
The Challenge
80% of call-center support requests were related to users asking about progress. At the same time, increased telemarketing regulation was forcing the business from a call-center-first model to a digital-first experience. My designs would have to quickly decrease demand on the call-center while working within existing back-end systems; they would also be laying the groundwork for a long-term vision that didn't yet exist. To reconcile these stakeholder needs, I framed the design problem as such:
How can we reduce call center demand by clarifying progress on the digital experience —while working within existing backend and laying the foundation for a long-term vision?
02 • Approach
Research + Insights
I conducted moderated remote interviews with 12 existing clients to understand what was and wasn't working with the current dashboard experience. Users found the high-level summary useful, but immediately dismissed an important task modal, struggled to navigate deeper into the site to access repair details, and were frustrated by ambiguous item statuses.
Ideation + Iteration
Transforming these insights into designs, I worked closely with product and engineering to map out the ideal customer journey, as well as the underlying system logic. I wanted to understand what was needed from the user, as well as how that related to what the system was doing behind-the-scenes. I discovered that the system is non-linear: multiple parallel processes happening simultaneously, different bureaus reporting different statuses, and items cycling through the dispute process multiple times. At the same time, I was using tools like Figma Make and Lovable to sketch ideas fast to present to my cross-functional partners.
03 • Validation
Testing + Feedback
Ultimately, I created a fast, scoped fix as well as a long-term vision. For the fast fix, I focused on front-end refinements that would fix accessibility and usability issues. For the long-term vision, I incorporated greater back-end improvements that would bring forward recent activities from the last 30 days, show greater item details, and link outstanding tasks to individual items.
Once I had a working prototype, I conducted usability testing to validate the first set of changes with real users. For the short-term solution, 5 of 6 test participants successfully located removed items and in progress items, while 4 of 6 testers rated their confidence at 7/10 or higher.
Testing also revealed two key opportunities: I reverted to familiar terminology to help users orient themselves, and added credit score access to Quick Actions while keeping it secondary to the primary goal of understanding repair progress.
04 • Reflection
Key Outcomes
By addressing front-end accessibility and usability issues in our first update, Lexington Law’s credit repair dashboard nearly doubled intake completion rates while reducing the burden on our call center support team. Users can now immediately see and complete outstanding tasks—eliminating the friction of previously dismissing them without a clear way to return—as well as easily access deeper pages containing detailed lists of removed and in-progress items.
182%
INCREASE
in intake completion rates
22%
REDUCTION
in progress-related support requests
✨
DEFINED
a strategic, long-term vision
Next Steps
Building on the short-term usability wins, the next phase focuses on the back-end investment: showing removed items and disputes sent from the last 30 days, surfacing item details, linking outstanding tasks to individual items, and replacing ambiguous item statuses with reassuring ones.
Several open questions would need to be resolved before moving into implementation. Do these changes actually give users a clearer understanding of their progress, and does the experience continue to feel relevant and trustworthy as a user moves from one month to three or nine months into the process? I’d use moderated testing with users at different stages of their journey to validate the proposed direction and identify where the experience needs to evolve over time.
To summarize, this project reinforced something I'm always coming back to as a designer: when systems get complex, exposing everything can just get messy and overwhelming. My job is to figure out which pieces of the system actually matter to the user at every step, so the experience feels simple even if the system underneath isn't. I've found that when that's done well, that's what builds trust and value.
