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 requesting a progress report. Credit repair is highly regulated and trust-sensitive. Repair takes a long time, and progress is not easily quantified or directly correlated to credit score change. Additionally, CROA prohibits any language implying a guaranteed outcome, timeframe, or score change — a hard legal constraint, not a style preference.
How can we create a legally compliant dashboard experience that clearly communicates progress, proves service value, and builds user trust?
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 struggled to navigate deeper into the site to access repair details. 7 of 12 participants dismissed an important setup modal that would increase the effectiveness of their repair.
Ideation + Iteration
Working closely with Product and Engineering, I mapped the target user flow to align on the desired experience and define key design requirements. We identified two critical needs: giving users easy access to their removed and in-progress items, while also ensuring they could clearly identify and complete outstanding tasks directly from the dashboard. Throughout the process, I used tools like Stitch, Figma Make, and Lovable to rapidly explore and iterate on concepts, bringing tangible directions into stakeholder reviews and facilitating faster alignment.
03 • Validation
Testing + Feedback
Ultimately, I created a short-term solution as well as a long-term vision. For the short-term solution, 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 expand the dashboard's functionality.
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, more than 80% of participants successfully located removed items and identified their next steps, while over 75% 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: a Recent Activity widget surfacing recent bureau and dispute updates, and a dashboard navigation redesign built around familiar, functional patterns — a persistent side-nav on desktop and a bottom nav bar on mobile.
Both initiatives carry open questions: for the activity feed, we'll need to work with Legal and Engineering to define an update cadence that builds trust without implying an outcome or timeline CROA prohibits us from suggesting; for navigation, we'll need to determine whether the new pattern stays scoped to the dashboard or signals a broader IA shift across account, billing, and support surfaces.
Resolving these will require close collaboration with product and engineering to translate a large, complex dataset into a small set of signals users can act on, validated through a card-sort or tree-test on the proposed navigation structure and moderated testing on activity-widget prototypes to confirm which data points actually build user trust.
