10KC is a $75M B2B mentorship platform used by enterprise organizations including Nike, Deloitte, and PwC.
The mentor–mentee matching flow was one of the most critical workflows in the platform — and one of the most problematic. Admins frequently abandoned the process, requested support, or questioned the quality of matches due to long load times, low transparency, and a confusing interface.
This created significant operational overhead for Customer Success and reduced client confidence in the platform, contributing to churn risk.
I led the redesign of the matching experience to make it fully self-serve, improve transparency into match decisions, and ensure admins could confidently complete matching without support intervention.
Role
Lead Product Designer (End-to-End Ownership)
Company
B2B SaaS HR platform
Duration
3 weeks
Team
Two Software Engineers
My Role
Led the end-to-end redesign of the mentor–mentee matching workflow from problem definition through validation, working closely with Product, Engineering, and Customer Success to balance user needs with technical constraints.
Identified key usability and trust issues through research and support data
Defined the UX strategy for improving self-serve matching
Scoped solutions around technical and timeline constraints
Prioritized solutions based on impact and feasibility
Designed and validated the end-to-end matching experience
Tested solutions with admins and iterated based on feedback
Key Problems
The Solution
A self-serve 4-step workflow that reduces operational load
The tab structure divides the matching flow into four key milestones, showing only what you need based on where you are in the process. With the new simplified UI, admins can review, adjust, and lock in matches independently, without relying on Support or Customer Success to explain workflows.
Transparent match explanations that build admin confidence
Admins can clearly see why each match was created and which criteria were met, allowing them to validate the system, trust the algorithm, and confidently move forward without second-guessing.
Informative loading states when matches are being generated
Real-time progress indicators and estimated time remaining prevent admins from thinking the system is frozen, reducing abandonment and creating a predictable experience.
This frees up Customer Success to focus on high-value initiatives and reduce ongoing support costs.
This cut internal support overhead and restored admin trust, which helps prevent churn and ensures the algorithm is relied on confidently.
This accelerates mentorship program launches, shortening the time to value.
Research Methods
I referenced qualitative and quantitative research sources to understand where users were encountering issues and why.
Interviews
I conducted guided walkthroughs with admins to map their mental models and surface their pain points.
Analytics analysis
I analyzed the data to understand the bounce rate and error rates, identify problem areas, and establish a benchmark for improvement.
Support tickets
I collaborated with the support team to identify and analyze core complaints and help requests regarding the matching flow.
Competitor analysis
I referenced other networking platforms to identify feature gaps and opportunities for differentiation.
Key Findings
Only 11% of admins can complete the matching process by themselves due to the confusing user interface (see photo below)
Matches take too long to be generated, causing admins to think the screen is frozen and abandon the page.
One of the leading cases of churn was a lack of confidence in the product. This was largely because it's unclear why specific matches are created.
Constraints & Key Decisions
After speaking with the engineering team, we learnt that rebuilding the matching flow from the ground up was not going to be feasible.
CONSTRAINT #1
Before beginning any work on the matching page, we needed to fix the existing page performance issues so that we wouldn't be building on top of a broken system. This meant that we would have less time for other improvements.
CONSTRAINT #2
Years of technical debt made changes to the matching logic high-risk and time-consuming. Since the matching page was such a core high-frequency workflow, we couldn't risk introducing excessive bugs.
DECISION
Due to the time constraints and risk of bugs, I restricted the solution to UI-level changes, reframing the problem from changing how matching works to changing how matching is understood.
Mapping out the ideal flow
BEFORE
A complex, multi-step process with lots of back and forth between the Admin and the Customer Success Team over a span of days.
AFTER
An ultra-simplified four-step process that could be completed entirley by the Admin in one sitting.
Key Design Decisions
How might we design a self-serve workflow for admins so that they can confidently create matches without needing support?
WHAT DIDN'T WORK
I wasn't able to create a step-by-step flow spread across multiple pages because it would take too long to build, was too bug-prone, and would slow experienced admins down.
WHAT I DID INSTEAD
Since I was constrained only to fixing the UI and not changing the underlying logic, I split up the page into 4 distinct tabs, each correlating to a different stage in the process.
How might we prevent admins from thinking that the matching page is frozen while matches are being generated?
WHAT DIDN'T WORK
Optimizing the match algorithm to make it so fast that no one could ever mistake the page for being frozen. This wouldn't work because we didn't have time for back-end changes and load times would always vary based on the number of people being matched.
WHAT I DID INSTEAD
I had to set user expectations by making it clear that the page was in a loading state. This meant showing the progress of the matching and the estimated time remaining until completion.
10%
Creating Matches....
Estimated time remaining: 2m 34s
WHAT DIDN'T WORK
A full match explanation would be overly detailed, not scannable, and not scalable. It would also not show what admins care about most: whether the match adheres to the matching criteria that were set.
WHAT I DID INSTEAD
I created short and clear match reasons that were anchored on the match criteria set by the admin.
Testing with users
I tested the design early and often, iterating with feedback at each stage. The moderated prototype walkthrough included four participants—two super users and two with no prior experience—to capture both expert and fresh perspectives.
Before & After Summary
BEFORE
Not self-serve due to confusing UI
Frequent support requests
Delayed program launches
AFTER
35% increase in self-serve admins
54% decline in match-related support tickets
25% faster program launches and time to value
Key Learnings
Perceived performance matters as much as actual performance
Admins often assumed the system was broken when matches took time to generate. Making system activity visible prevented abandonment and reduced support requests without requiring backend changes.
Transparency isn’t about exposing every detail
It’s about surfacing the information that builds confidence, aligns with user goals, and scales across diverse audiences.