Finding the data that matters for 20M+ people who couldn't opt out of understanding it.
Company
MetLife, one of the world's leading insurance and financial services companies (Insurance / Enterprise).
Product
MetDental’s Member and Provider Platform serves over 20 million members and over 130,000 in-network providers.
MetLife's dental platform buried critical decisions inside dense, regulated claims and benefits data.
My job was making that data legible for members to decide whether they can afford a procedure, and for providers processing procedures at volume.
Every core member and provider flow shipped responsive across web, tablet, and mobile.
Overview
Role
Lead Product Designer, Dental Provider & Member Platforms
Team
3–4 Designers, UXR, Multiple PMs, Engineering, Business Leadership
Leading a Team and a Platform Transformation at Scale
MetLife's dental insurance administers benefits for over 20 million people across a network of 478,000+ dental locations nationwide.
The platform supporting this ecosystem, used daily by providers and members alike was outdated. Navigating eligibility, claims, and benefits had become unnecessarily complex for both sides of the experience.
The business had made modernization a top priority, and I was brought in to lead both the design team and this large scale initiative simultaneously.
While I owned the provider platform redesign end to end, I also oversaw a team of designers each running their own parallel work streams across the member experience.
Diving Deep into Research
How might we find the data that matters?
Finding behavioral signals to make design decisions that are measurable and tied to business outcomes.
Members weren't giving feedback about an entertainment app; they were trying to figure out if they could afford a root canal. Providers weren't browsing insights; they needed to verify a claim status before the next patient.
Same underlying problem, a lot of noisy, dense data, and a real cost to getting the signal wrong.
I'm walking through how I found that signal, what I personally owned versus what the team owned, where research changed my direction, and what I'd bring to a team facing the similar questions today.
The Customer Problem
Multiple audiences, multiple needs.
Members needed reassurance
Coverage, cost, and eligibility questions at the exact moment someone is deciding whether to get care. Clarity wasn't a nice to have, it changed real decisions.
Providers needed speed
The same underlying data, but at volume, across every patient on their books. What took a member five minutes to read had to take a provider five seconds to scan.
Compliance wasn't optional
DPPO and DHMO plans carry different rules for nearly everything, coverage percentages, frequency limits, incentives. The "right" data depended on which plan you were looking at.
Structure of My Team
Led across the team: Roadmap, prioritization, and cadence. I built and ran a shared prioritization framework, the weekly operating rhythm, and the research partnership model across all six workstreams. I created and maintained the roadmap across all of the team initiatives, regularly presenting progress and priorities to leadership and the business.
With a team of 4 designers, UXR, and UX Content designer, I assigned clear ownership by domain. A dedicated designer for the member experience and a dedicated designer for the provider experience. This gave each designer a single focus and accountability while allowing me to lead across both tracks.
The member side work streams included:
Orthodontics: A 0→1 experience for members
Member Dashboard Redesign: Improving the core member home experience
Family Benefits: Surfacing benefits clarity for families
Opt into Paperless: A behavioral nudge initiative I also led directly
For member, I directed and unblocked, I set direction and ran alignment, I didn't push every pixel.
I owned the provider side work streams that included:
Resource Center: A 0→1 content hub I also led directly
Redesign of Legacy platform: A complete redesign of MetDental for providers
For provider, I owned each project, ran alignment, and pushed many pixels.
Facilitation & Cross-Functional Alignment
Before I introduced a shared prioritization framework, priorities were being set in two places that didn't talk to each other.
UX driven priority ranking and business driven priority ranking for the same initiatives, ordered almost in reverse of each other.
I worked with the team to build a design strategy and prioritization table that was shared with PM, DEV, and Leadership, replacing disconnected conversations with one shared artifact.
I facilitated workshops for stakeholders to plot initiatives together, in the same room, replacing disconnected lists with an artifact for everyone to share.
A System for Running Parallel Work streams
Managing multiple designers across multiple projects required a tight operating rhythm. I held weekly meetings for each work stream using a consistent format: where we were, where we are, where we're going. Blockers were addressed, iterations discussed, and everything documented in Jira and Confluence so leadership always had clear, real-time visibility into work in flight.
Each team also received a weekly written recap covering progress, blockers, open questions, and next steps, keeping every project running in a glass box and every stakeholder informed without having to chase status.
Prototype, Test, Iterate
Each team built focused research plans and prototypes tested first internally, then externally with real users, including providers navigating a network of 133,000+ unique locations.
Designs were iterated until hitting appropriate quality marks before moving into development.
The dental coverage homepage
Redesigning around what brings people value and piece of mind
Concrete moments
This is the landing screen every member hits first, where they land coming out of their accounts overview into the dental experience.
It's the highest traffic screen in the platform, and it was carrying a lot of things nobody was actually using.
Behavioral data told us what to keep.
🎯 Decision driver
Users consistently went to the cost estimator first when planning treatment, it was the primary decision anchor, not a secondary tool.
🏠 Homepage value
Coverage summary and cost estimator ranked as the most important homepage elements.
Aligning Stakeholders Before Designing Anything
Rather than having the team dive straight into design, I kicked off the provider platform project with a design sprint alongside UXR, bringing together key business and product stakeholders.
This surfaced the potential and limitations of the project early, creating shared alignment before a single screen was designed.
💙 Perceived value
The redesigned spending insights concept scored 4.15/5 in perceived value in testing, especially for call-center users and habitual site visitors.
Mobile Prototype of Dental Member Coverage
Orthodontia
Before this work, there wasn't an ortho explanation at all, just a flat "Orthodontics Covered: No" buried in a benefits table.
Ortho was one of the top drivers of call volume, internal call containment briefs cited it as a top IVR topic and reducing calls while moving members off paper and onto digital self service were explicit company goals. A separate flash survey had already flagged Ortho as the single hardest benefit category for members to understand, and eligibility research had independently flagged the ortho deductible as hard to find.
Multiple teams had strong opinions on how to do it. I ran a workshop where everyone contributed before reacting to each other.
From this I framed a design hypothesis:
If we replace that blank line with a real cost, a dynamic story, there will be better member comprehension and calls related to ortho should improve and go down.
I set the research plan and goals, walked UXR through each prototype, and they ran the facilitation and analysis.
Testing was remote, moderated sessions with 5–6 participants per round, roughly two weeks each: a week to define goals and prep, a week to test, then a readout that started with a quick summary before the fuller analysis followed.
Round 1
Minimal lift prototype
Cost driven story prototype
Quick implementation: A plain language policy explainer, coverage rules, and lifetime maximums, no worked examples.
Too abstract; members couldn't connect it to their own situation.
Winning direction: Two persona stories (Emma, Jake) walking their actual costs procedure by procedure, combined with an in network/out of network toggle on a single screen.
Review
UXR's testing confirmed the hypothesis. The real cost version outperformed the standard explainer.
After sharing Round 1's results with stakeholders and leadership and gathering their feedback, we ran a second round to see if we could push further.
Round 2
Simplified story prototype
Complete story and numbers breakdown protoype
Not well received: Simplified the narrative further, but lost the itemized costs members had responded to.
Not adopted: Went the other way with a fuller story plus a complete numbers breakdown, split into separate in network and out of network tabs with a full payment schedule ledger.
UXR's testing showed people lost the thread of the story trying to click through it.
Final Direction
What we actually wanted was for these stories to be dynamic and built from each member's own treatment plan and their own name, not illustrative examples like "Emma" and "Jake."
We didn't have the dev resources for that scope of work, and it wasn't a priority for the business at the time.
The names became their own small version of the same problem: a fictional name attached to a real member's account read as confusing, not relatable, so the shipped version used generic labels instead.
That call came down to leadership and content team judgment, not a tested finding.
The operating principle became showing meaningful information with the data we actually had, instead of waiting on a fully personalized version we couldn't build yet.
When engineering surfaced something the design didn't account for
Claim statusing was the single highest effort item on the entire roadmap, and it didn't ship from a fixed spec.
New requirements kept surfacing in the code as engineering got further into it, and design adjusted the same week, not the same quarter.
Design assumption
Show patient specific ortho benefit detail directly in the claim view, it's one of the highest drivers of support calls, so it should be there.
What we shipped instead
Engineering flagged that patient specific data wasn't available at the API level yet. We scoped the MVP around what was actually buildable, and staged the fuller version as a fast follow once the backend caught up.
That was the value of the twice weekly sync. Not reporting status to engineering, but being able to catch the gaps between design knowledge and what the system could do before it became a missed launch instead of a scoped down one.
Outcomes
Impact of the work
🏗 Platform Modernization Prioritized
Full redesign of a legacy platform serving 20M+ members and 478,000+ locations.
🎯 An alignment methodology that outlived the project
Facilitated structured design workshops that aligned business, product, and engineering.
👥 Research made structurally load bearing
Every initiative required a documented hypothesis and evidence before prioritization.
🔬 Compliance-sound workflows, without sacrificing usability
DPPO/DHMO policy logic designed in direct partnership with compliance and legal.
📋 Full Leadership Visibility at All Times
Weekly documented cadence across six parallel workstreams kept every project transparent without status-chasing.
📈 Legible data, at scale
Claims, eligibility, and cost information redesigned around what a member or provider actually needed to decide, not just what the system stored.
What I learned
The hard part was never the screen.
Making dense data legible turned out to be the easier problem. The harder one was building a system where a research backed decision could reliably beat an instinct driven one. Consistently, across a team big enough that no single conversation could hold everyone accountable to it.
The fun part is leveraging my experience.
Walking into a team with multiple engineers, no dedicated designer, a PM who's been carrying research alone because there's been no one else to do it. I've built these operating systems before. The research requirement, the shared prioritization framework, the cadence that catches the gap between design and engineering before it becomes a missed launch instead of a scoped one. I have those frameworks in my back pocket, I don’t have to reinvent them from scratch.
I love being in the research sessions and the Figma file, not just running the system from above.