A payments platform for doctors and patients that nobody was using — rebuilt into a new revenue stream, with a design system that outlives this one project.
The client's payments platform was underutilized, and the people who did use it didn't think much of it. Through interviews, a handful of pain points kept surfacing — single sign-on, general adoption, a messy enrollment process, and a spike in customer support call volume that was overwhelming the client's team.
Two things drove most of that call volume. First, the technical hurdles of accepting credentials from a wide range of services for SSO. Second, a lack of accurate provider profiling — which forced people to keep a separate login for every office location under the same organization.
Underneath both was a design problem: the product had almost no error prevention or recovery. A form that hadn't been fully filled out, a user navigating away without saving — neither had any messaging to catch it, and each one turned into another support call.
Research started with stakeholders across six distinct areas of the solution, split between two sectors — Product, which covered the technical and operational side, and Business, which knew how the solution was actually being sold.
Partnering with the Business side, we reached out to current customers to understand how they actually felt about the Provider Portal. Clear patterns emerged: people liked the self-service tools and search capabilities, and consistently pushed back on the lack of mobile browser support, the overall look and feel, and tedious data entry.
To go beyond what interviews alone could tell us, we ran an incentivized fifteen-question survey to over 1,000 current customers, asking what they liked and disliked most, how easy key parts of the product were to use, and what they did most often.
Response rates were low — typical for a product with a low satisfaction score — but what we did get lined up with the interview findings. Combined, that feedback shaped feature prioritization and became the start of a much deeper backlog of future enhancements.
Customer interviews and workflow analysis got clustered into a short list of what actually mattered — separating real pain points from one-off complaints, and lining that up against what the business needed the product to do.
Working with project stakeholders, we set out to establish baseline metrics for the product's current health. What we uncovered got organized into four categories, built around the pain points we'd already identified: usage and adoption, registration, engagement, and customer experience and satisfaction.
Those baselines did double duty — they gave us a fair read on where the product actually stood, and they became the yardstick for what would count as success once the redesign shipped.
Doctors and patients needed genuinely different things from the same payment flow, so the redesign had to work for both without feeling like two separate products bolted together.
Alongside the redesign, I built an enterprise-level design system — not just for this platform, but so the client's team could make future changes without starting from scratch each time.
Clickable prototypes went in front of the same people who'd flagged problems with the original product, so feedback came from people who actually understood the stakes — not just internal review.
Sessions focused on cognitive load with the new interface, surfacing pitfalls that had gone unnoticed internally, and measuring time to completion against the original flow.