Simplifying Complex Data for 350,000+ Physicians
Scope
Physician performance evaluation platform
Role
Sole UI/UX Designer
Duration
3 months
Team
Product Owner, Marketing Director, 3 Engineers
For 16 years, UnitedHealth Group's approach to physician confusion on their performance evaluation platform was the same: add more information. By the time I arrived, the interface had statistical formulas, percentile breakdowns, case-mix adjustments, and confidence intervals. Complexity layered on complexity.
I worked with call log transcripts to understand what questions physicians were actually asking during support calls. They weren't asking how their scores were calculated. They were asking why they didn't pass. The solution wasn't more information. It was better presentation of the right information.
I led the complete redesign as the sole designer on a team that had never had a designer before. I restructured the information architecture, established design-engineering rituals, and shipped a platform organized around the questions physicians were actually asking.
This case study describes my process and contributions while respecting confidentiality. Specific system names and internal details have been generalized.
The Platform
Physicians are evaluated on two core metrics: clinical quality (do you follow evidence-based guidelines?) and cost efficiency (how do your costs compare to peers?). Based on these scores, physicians either receive a designation or they don't. The designation affects their visibility to patients and referral patterns.
Since the beginning, the team had approached physician confusion the same way: if users don't understand their results, give them more information to help them understand. The assumption was reasonable. Physicians are educated professionals, and providing the methodology should help them interpret their scores, but it wasn't working.
Marketing kept hearing the same calls:
"I don't understand my score."
"Why didn't I qualify?"
"What do I need to do?"
My Approach
Diagnosing The Real Question
I didn't have direct access to physicians, so I worked with what I could get. The marketing team shared call log transcripts from physicians who had contacted support after the most recent designation cycle.
The team had been answering physician confusion with methodology for the past 16 years. To avoid confirmation bias, I held their interpretation in mind as the existing hypothesis and entered the analysis looking for whether the data supported it or contradicted it. I tagged questions by category and noted recurring language. The patterns were consistent.
Physicians weren't asking how their scores were calculated. They were asking:
"Why didn't I get designated?"
"What does this score mean?" (often referring to specific statistical terms like chi-square or phi-coefficient)
"What do I need to do about it?"
The statistical methodology that the platform was prioritizing wasn't the answer to physician questions, but the very source of them. Physicians are not statisticians. They needed a clear pass/fail status and a comparison to the threshold. Less methodology, more outcome.
The Structural Problem
The data overload was one issue. The site architecture was another.
A heuristic analysis surfaced structural problems independent of content:
Multiple entry points led to the same content
Navigation had dead ends
Critical information was nested two or three levels deep
No clear hierarchy guided users to what mattered most
Performance evaluation dashboard - before redesign
Physicians had to navigate through three different views just to understand if they qualified. The information they needed first was the hardest to find.
My Proposal
The shift was clear: stop answering physician questions with statistical methodology and start answering them with outcomes.
Stakeholders pushed back on removing the statistical content. They worried it would reduce credibility. The data had been part of the platform for 16 years; removing it felt like erasing the platform's authority.
Rather than fight to remove information, I proposed a different frame: strategic information reveal. Answer the user's primary question by default. Make the statistical detail available on demand for users who want it. The argument shifted the conversation from "what to remove" to "how to reveal", and we reached consensus.
I structured the entire experience around two questions physicians were actually asking:
Why am I not designated?
What can I do about it?
While analyzing the platform, I noticed a usability issue beyond the methodology question: the two score category names were too similar. Users couldn't remember which was which, and they didn't understand the distinction between them.
Renaming wasn't possible as the names were established program branding. Changing them would have required a massive documentation overhaul upstream, beyond the scope of my project.
I designed around the constraint instead. Explanatory text on each detail page clarified what each score measured, in plain language. Tooltips on the dashboard reinforced the distinction at the point of interaction. The names stayed and the confusion was addressed through supporting UI.
The Solution
The Information Architecture
The existing architecture scattered critical information across multiple entry points. I restructured it into three clear levels, organized by how urgently a user needed each layer:
Level 1: Dashboard
The immediate answer. Did you qualify? What are your two scores, and how do they compare to the thresholds? What can you do next?
Level 2: Score Details
For physicians who want context. Category breakdowns, benchmark comparisons, what's affecting the score.
Level 3: Methodology
For the small number of users who want to understand the math. Available, accessible from every page, but not required.
Information Architecture before redesign with multiple entry points and critical information buried under a click
Information Architecture post-redesign with clear hierarchy, information, and action paths
Level 01 - The Dashboard
This is the first thing physicians see. Designation status is the hero element: did they qualify or not? Below that, their two scores with visible thresholds and tooltips explaining what each measures, with the ability to expand to get more detail. Clear actions: View Details, Request Reconsideration, Contact Support, View Methodology.
Landing page Dashboard with answers to immediate questions in its default view
Level 02 - Score Details
This is a more detailed breakdown for physicians who want to understand their scores better. It is detailed by category with comparison to benchmarks and what's affecting their score. Explanatory text at the top clarifies what the score measures in plain language.
Effective Quality Care score details page
Efficient Quality Care score details page
Level 03 - Methodology
This is for the physicians who still want help understanding their scores. Available, but in a different tab and accessible from every page. Users can navigate to it if they want to go over the methodology and contact the Premium team.
Methodology and reconsideration requests available on request
Video Prototype
Progressive Disclosure for Score Cards
Stakeholders required that statistical calculations remain visible. The score cards were the design negotiation point. I used progressive disclosure through accordion-based cards.
Default View (collapsed):
In the default state, the cards show:
score and percentile ranking
pass/fail status through a clear visual indicator (Meets/Does Not Meet Criteria badge)
benchmarks for score and percentile
Expanded View:
Statistical information was retained, but they were made understandable by:
adding specific benchmarks
including tooltips with explanations regarding how to recognize a positive score
a note indicating that the percentile ranking alone determines pass/fail status
Users who don't need statistical detail never see it. Users who want it access it with one click. Stakeholders kept the credibility they were worried about losing. Physicians got the answer to their actual question.
Design System Work
I transitioned the platform from developer-built components to UHG's design system. This brought visual consistency with other UHG applications and improved both polish and accessibility (WCAG-aligned).
For elements unique to the evaluation platform, i.e. the score cards, I designed them as custom components that extended UHG's design language. The score cards needed a visual treatment for designation status that the existing component library didn't support, so I extended UHG's badge and card patterns to handle the pass/fail context.
The First Designer on the Team
This team had never had a designer. There were no established processes for design reviews, documentation, or handoffs. Building that infrastructure was part of the job.
What I set up:
Weekly Design Reviews with Engineering
Work-in-progress sessions before showing stakeholders. Engineers understood my rationale; I understood their constraints. By the time we presented to stakeholders, we were aligned.
Documentation Conventions
Wireframes and prototypes with annotations, linked to development tickets. Engineers did not need to chase me for clarification.
Stakeholder Cadence
Regular check-ins with the product owner and marketing director, with clear decision points and documentation of what was decided.
These rituals continued after I left.
Surya jumped right in and delivered beautiful designs to an overly complex concept. Outside of that, she's a super awesome human and I could only be so lucky to work with her again!
Brooke Klaers
Director of Marketing Engagement, UHG
Reflections
01
Evidence Enables Hypothesis Reversal
Proposing a different approach to a 16-year-old problem required evidence. Even with limited research access, the qualitative data from call logs made the case in a way that design opinion alone couldn't.
02
Hold the Existing Answer in Mind, Look whether the Data Supports It.
I avoided confirmation bias on this project by entering the research with the team's existing interpretation in mind, then reading the data to see whether it confirmed or contradicted that interpretation. That framing helped me notice when the data pointed the opposite direction.
03
Strategic Compromise over Rigid Principles
Progressive disclosure required letting go of the perfect solution (complete removal of statistical detail) for the practical solution (smart presentation). The best design is the one that balances user needs with business constraints in a way both can accept.
04
Design Around What You Can't Change
Not every constraint is solvable head-on. The score category naming stayed the same. The confusion was addressed through supporting UI. Choosing to design around a constraint instead of fighting it is also a design decision.
05
Build Infrastructure Alongside Interfaces
Being the first designer on a team means building the infrastructure that lets future designers succeed, not just shipping screens. The collaboration patterns I established kept running after I left.
Simplification is harder than addition. Showing less, and making the case to stakeholders for showing less, required more rigorous thinking than showing more ever would have.
Let's work together
The assumption was reasonable — physicians are educated professionals, so providing the methodology should help them interpret their scores.