Post-launch metrics
Aspen Dental
How redesigning a confusing work queue prevented $2.98 million in accidental refunds in just 3 months
Project overview
Timeline: 2.5 months (2024)
Impact: 1,100+ Aspen Dental locations nationwide; $2.98M in prevented refunds within 3 months of launch
Role: Junior UX Designer
The moment I knew something was broken
Before I was formally assigned to this project, I visited an Aspen Dental office to observe how staff used our enterprise tool, EPMS.
I asked the Office Manager what he thought of a widget called "Schedule Care or Refund." on the Office Dashboard.
He told me he didn't touch it. Not because he didn't need to - because he had no idea what it was asking him to do.
A few weeks later, the Senior Director of Patient Financing and Senior Product Manager of Revenue Cycle Management came to me with the same problem. I already had my answer for why.
image
A system built for experts, used by everyone
Patient financing at Aspen Dental runs on a trigger-based refund system. When a patient takes out financing, a clock starts.
If the Office Manager doesn't complete specific actions within specific windows, the lender automatically pulls the financing back - even if no one intended that to happen. There are three phases, each with its own rules and deadlines.
I mapped it all on a FigJam board, which became the artifact I returned to in every stakeholder session, engineering conversation, and alignment check.
The Office Manager role also carries a 40% turnover rate - the highest in three years. Whatever I designed had to work for someone on their first week.
image
A table of data, not a tool for action
The existing work queue had 10 columns. This was some of its most critical problems:
"Refund date" sounded final - but it wasn't: It shifted based on OM actions.
"Care completed" didn't mean treatment was done: It just meant the patient reached Phase 3 of the financing lifecycle
No charged-out-care totals: An OM could schedule a patient and still see them stuck on the list, with no idea why.
There was no clear call to action anywhere. Just a table of data asking users to draw their own conclusions.
Finding what actually mattered
I ran a workshopping session with the patient financing team and its executives, as well as the territory managers who train our OMs in the field.
We went column by column with one question: does an OM actually need this to do their job? We cut 10 columns down to 5.
Many of them didn't exist in the original design at all.
image
The column that changed everything
The old design showed OMs what was happening. It never told them what to do about it.
I pushed for an "Action Needed" column - one specific, dynamically-generated instruction per patient, based on their phase and lender type. I worked with engineering early to confirm this logic was feasible before designing around it.
I also reordered the table so "Days Until Scheduled Refund" became the first column. The list now sorts by urgency, and OMs work it top to bottom.
image
Testing with the people who'd actually use it
I ran moderated feedback sessions with 7 participants - Office Managers and Regional Managers ranging from 3 months to 14 years of experience.
5 out of 7 misinterpreted the "Schedule by X to occur/be completed by Y" language, collapsing two separate deadlines into one.
Only one participant - an OM with 8 years of experience - understood it correctly on the first read.
"It feels like I have to finish everything by this one date. I don't get why there are two dates here." - Christina, Office Manager, 14 YOE
This made it clear I needed to pressure test the copy.
I tested several rewrites - the version that worked across every participant was the simplest one: "Schedule by X, complete appt by Y."
Jargon mattered too - "charge out" consistently confused people, while "provide over $100 worth of care" landed clearly at every experience level.
IMG
I also learned the filters carried over from the original design weren't being used. Experienced OMs worked the list top-to-bottom regardless. Queues rarely exceeded 12 patients, so I cut the filters entirely.
Redesigning the front door
The dashboard widget leading into this queue had the same problem as the table: it led with fear, not action.
The original showed a donut chart with a dollar figure in red: -$45,800, Opportunity at risk.
I redesigned it around a direct statement instead: "6 accounts left to action," with a badge that appears only when patients fall in the 0-7 day refund window: "2 refunding soon."
Additionally, the dashboard has several widgets tied to scheduling across different roles, and so this widget needed to be clear this was about financing.
I renamed it from "Schedule Care or Refund" to "Upcoming Patient Financing Refunds" to address this problem.
$2.98 million in 3 months
We piloted to 50 offices, then launched nationally to all 1,100+ Aspen Dental locations.
Post-launch metrics
Comparing the three months before and after national rollout, $2.98 million in financing stayed with patients instead of returning to lenders - a reduction in accidental refunds across all 1,100+ locations.
No other process, staffing, or policy changes shipped to the network during this window.
"This makes it way easier to keep track of patients who will be refunded and when I should schedule them." - Office Manager via launch survey
More patients completed their care. More revenue stayed in the practice. A work queue OMs used to ignore became something the field was excited about.
Worth noting: the post-launch window included December, historically a slow month — so this figure is likely conservative.
IMG
A new ask that worked against the product's intent
A few months after launch, executive leadership introduced two new requirements:
Give OMs the ability to submit refund requests directly on a patient's behalf
Surface appointments that had already been scheduled in the queue
That second ask went against the product's purpose as a queue of outstanding tasks, not completed ones. I designed it anyway and ran a second round of testing with 5 Office Managers.
img
What round two got right - and what it didn't
The sectioned layout was a clear win across all 5 participants, but two things I'd carried forward from round one broke down.
But two things I'd carried forward from round one broke down.
The "Treatment timeline" badge - which had solved the dual-date problem earlier - now created a contradiction: a patient could show "Not started" while sitting in "Scheduled Appointments."
"Why does it say 'Not started' if I already scheduled them? That's confusing." - Lexi, Office Manager, 2 YOE
Removing the dollar amount from the widget also went too far. 3 of 5 participants said it felt less urgent without it.
Img
Making the case against my own stakeholder's ask
When I asked OMs what they thought of seeing already-scheduled patients on the list, none of them found it useful. To them, once a patient was scheduled, the task was done.
I brought that finding to the SVP of Patient Financing and made the case for dropping the scheduled-appointments view entirely - rather than shipping something the field had explicitly told me they didn't want. I got buy-in to move forward.
"I can find the patients that are about to be refunded quicker than ever." - Pilot survey response, Office Manager
I also extended the window to view patients who have been refunded from 24 hours to 7 days, after learning most OMs only check this report a couple times a week.
img
Designing the refund request itself
Submitting a refund on a patient's behalf is irreversible, so I treated it with the weight it deserved.
When an OM selects either refund-triggering reason from the status dropdown - set apart from routine tracking options by a visual divider - a confirmation modal opens. with the reason pre-filled, the patient's remaining credit, and a required checkbox confirming the OM has met the criteria.
Users are met with review details of the patient's remaining credit, and a required checkbox confirming the OM has met the criteria to refund.
This is a deliberate stop before something that can't be undone.
img
The work continues
This project didn't end at the $2.98M milestone. When leadership introduced new requirements months later, I ran a second round of testing, pushed back on an ask the research didn't support, and reversed a design decision of my own that no longer held up.
The interface will look different soon - a design system modernization effort is already underway.
What won't change is the process behind it: test with the people using it, listen when the data contradicts a stakeholder or contradicts me, and keep iterating past the day something ships.
Enjoyed this project? Read about my case study from my time at Shelter Insurance.