When the data can't be trusted, neither can the decision

A provider profile sounds simple — show everything we know about a doctor or entity on one page. In practice, “everything we know” came from seven different upstream data sources and third-parties, each with its own update cadence, data quality issues, and organizational owner.

The design challenge wasn’t layout. It was trust. 52% of provider directory entries contain at least one inaccuracy — analysts already knew the data had quality issues. (CMS Provider Directory Review, 2018) The question was whether the interface would pretend otherwise, or give users the context to make informed judgments.

The system

Two users came to the same page with fundamentally different needs. An analyst needed facts: is this provider credentialed, contracted, eligible? A director needed a narrative: how is this provider performing, what’s their adequacy contribution, what action is recommended?

the analyst needs facts; the director needs a narrative

I designed the profile as a layered page. A shared top section — provider identity, primary specialty, compliance status — answered “is this the right provider?” quickly and definitively. Below that, the page forked. Analysts saw an interface organized access point and by product package - purchased by clients - with data provenance visible alongside every data point. Directors saw a summary-first view: performance breakdown, adequacy contribution — with the ability to drill into the same underlying data from a strategic entry point rather than an operational one.

The decisions

Data provenance as a first-class design element. Every data point carried a subtle provenance indicator. When data from two sources conflicted (which happened more often than anyone wanted to admit), the interface flagged the discrepancy inline and showed the errors - a flagged alert. This was initially controversial. The product team worried it would undermine confidence in the data. The opposite was true: analysts already knew the data had quality issues. Hiding that didn’t build trust — it eroded it. Showing the seams gave users what they needed to make informed calls, thus positively impacting their business goals and downstream contracting decisions.

Segmentation structure: three iterations. The first version organized by data source — the engineering-natural grouping. The second organized by task: credentialing, contracting, evaluation. The third — the one we shipped — organized by question: “Is this provider qualified?”, “What’s the business relationship?”, “How are they performing?” The question-based structure tested significantly better because it matched how analysts actually thought about their work. They didn’t come to the profile wondering what the credentialing system had to say. They came wondering whether this provider was eligible for a network and would they serve the purpose they were seeking to fill.

Presence over blocking on data conflicts. When conflicting values surfaced from two source systems, the instinct was to resolve or hide the conflict at the data layer. I pushed to show the error with a warning instead. The system’s job wasn’t to adjudicate disputed data — it was to surface the dispute so a human could. Automating that judgment would have produced confident-looking incorrect answers.

What changed

• The unified profile replaced four separate tools analysts had previously navigated between
• Time-to-decision on standard provider evaluations dropped measurably
• The indicators became a feature users specifically cited in satisfaction surveys — not because it is exciting, but because it solved a trust problem the product team hadn’t previously seen

Reflection

The hardest design problems in enterprise tools aren’t about interaction patterns — they’re about information integrity. Users of complex systems are sophisticated enough to handle messy data. What they can’t handle is uncertainty about whether the data is messy. Making the system’s limitations visible isn’t an admission of failure. It’s the design.