Delivered a complete redesign spec, and surfaced a customer-adoption gap that reframed the project's priorities.
Introduction
I was brought in to redesign a mature B2B product that had been in development for years, with a hard launch deadline months away. The product team couldn't define what the redesign was supposed to solve. When asked about requirements, they pointed back to the existing software. The real issue: we were refining a solution to a problem no one had diagnosed.
Research Gaps
Previous work by an outside agency identified surface-level pain points:
Users struggled to synthesize data across sources
Extracting actionable insights required excessive manual work
Troubleshooting unpaid claims lacked clear workflows
But critical gaps remained:
What we knew
What we didn’t know
Users found data extraction painful
The specific steps in troubleshooting workflows
Unpaid claims caused friction
What data fields mattered during investigation
Manual work slowed decision-making
How different practice sizes approached analysis
Closing those gaps required observing real user sessions, which never happened.
The Work
Core Workflow Visualization
With no diagnosed problem to design against, I made a set of structural bets to keep the work moving toward the deadline, and treated each as a hypothesis to validate rather than a settled principle.
Architectural Decision: Flexibility Over Specificity
Practices were structured very differently:
A arge practices (100+ users) had a deep hierarchy with finance directors, practice admins, managers branching into contract/reimbursement/office roles
A small practice (5-10 users) collapsed into 2-3 people
Same work, completely different organizational structures and no research on how hierarchy shaped decision-making.
My call, backed by other stakeholders, was to make the product structure agnostic. Administrators would configure role-based task restrictions and data visibility to match their practice’s actual structure. This was a bet on flexibility over specificity. I recognized this was a hypothesis needing validation and not a settled design principle.
Admins configure role templates per practice, the mechanism that let one product fit both a 100-person hierarchy and a 3-person team.
Customer Discovery
Before testing the redesign, I wanted to see how customers actually used the existing tool. Identifying active users turned out to be the hard part, in a way that was itself revealing. A trainer had to source customers on our behalf, and of the few practices that engaged, only one had anyone actively using the product: two people, both of whom knew only the sliver they'd been trained on.
This raised a larger question: had the product’s original direction ever been validated with customers? The adoption pattern suggested it hadn’t, and if that was true, the project may have been solving for assumptions from the start.
Recommendation & Outcome
I proposed shifting priority from redesign iteration to onboarding and customer relationship investment. My argument:
Feature adoption gaps pointed to missing discovery, not missing UX
Customer churn was a bigger risk than the redesign timeline
Validating assumptions with users would reduce downstream rework
Whether the team adopted the recommendation is unclear; they moved ahead to hit the deadline. I completed my deliverables and transitioned off the project.
Reflections
Design decisions made without user research are hypotheses, not conclusions
Architecture bets require validation mechanisms built into the roadmap
A well-executed redesign can still fail if it solves the wrong problem
Knowing when to push back is as important as knowing how to design