Case study · AI-assisted fee schedule management platform
Fee Schedule Hub
A centralized, AI-assisted platform for finding, creating, tracking, and auditing fee schedules — replacing a workflow that had lived across spreadsheets, SharePoint, and email. Requesters, approvers, and operations teams now share one system instead of three.
Role
UX Engineer / Product UX contributor — discovery through UAT
Fee schedule data — the rates and rules that govern how claims get priced — lived across Excel files, SharePoint folders, and email threads. Requesters, leadership approvers, and operations/pricing teams each worked from their own copy of the truth. I helped design the platform that replaced that patchwork: a single hub to search, create, edit, deactivate, approve, track, and audit fee schedules, with an AI assistant layered on top rather than in place of human review.
Context & constraints
Search required knowing the exact fee schedule name in advance — there was no way to browse or compare. Stakeholders described it as a scavenger hunt: incomplete discovery regularly led teams to create a new one-off schedule instead of finding the one that already existed. That duplication, plus approvals tracked entirely over email and no consistent template across requests, made the workflow hard to govern as it scaled.
Constraints that shaped the design:
Every request touched multiple roles and systems before it was "done" — a service-design problem, not a single-screen one
Audit and compliance review had to survive contact with an AI-assisted workflow, not get bolted on afterward
Bulk updates across many schedules at once were needed eventually, but had to be sequenced as a fast-follow rather than block the initial build
My role & collaborators
My strongest contribution was translating a deeply operational, spreadsheet-based workflow into a structured product experience that could support both human decision-making and AI-assisted automation. I worked across information architecture, the search and AI panel design, workflow states and validation, request tracking and audit visibility, bulk-action strategy, and a series of development-ready UX decisions — partnering closely with product and engineering throughout rather than handing off a finished design.
Research & insights
What we did
Reconstructed the current-state workflow from stakeholder discussions and a current-journey map
Ran requirements sessions to surface search needs, pain points, and workflow gaps
Collected real AI prompt examples — how people would actually ask for a lookup, a comparison, or a deactivation — to shape the assistant's design
What changed our minds
Search needed to work by attribute (state, line of business, license level, service code, network, rate range, modifiers), not just by exact name
Decision support — comparing schedules and surfacing near-matches — mattered as much as search itself, because it's what actually prevents duplicates
Searching could feel like a scavenger hunt — incomplete discovery meant teams sometimes created a new one-off schedule instead of finding the one that already existed.
From a requirements discussion with requester-team stakeholders
Design exploration & rationale
I structured the create/edit experience as a single page with persistent context, rather than a multi-step wizard: identity and scope, geographic and regulatory scope, pricing definition, claims system configuration, escalators, retroactivity, approvals, and back-office metadata, with pricing definition as the primary work surface. The spreadsheet had every field visible at once; the platform didn't need to. Progressive disclosure kept advanced and conditional fields out of the way until they were relevant — the recurring design tension was between showing everything that had been migrated and reducing cognitive load, and progressive disclosure was the resolution that kept coming back.
The AI panel sits alongside the form rather than replacing it: it can populate fields from a prompt, but every AI-assumed value is visibly marked and the form stays editable, so a human reviews and can override before anything submits.
Add a redacted screenshot for this section
[ADD SCREENSHOT: the AI side panel populating a request from a prompt, with AI-assumed fields marked for review — once network/system names are redacted.]
Prototyping & testing
UAT review: search/view, create, edit, deactivate, request tracking, approvals, and notifications were walked through end to end with stakeholders
Edge cases surfaced in engineering review: audit tables needed license-level specificity, modifiers needed clearer representation, and the cap table structure had to align with backend data
Import handling: reworked so a bad import produced a reviewable error state instead of simply blocking the user
Outcomes & impact
The work reached UAT/demo readiness covering search, create, edit, deactivate, request tracking, approvals, email notifications, and associated-entity visibility — addressing every major pain point from discovery: fragmented lookup, manual intake, email-driven approvals, limited tracking, and duplicate-schedule risk. Production metrics weren't available at the time of writing; I'm holding the numbers below until they're validated rather than estimating them.
Reached UAT across search, create/edit/deactivate, tracking & approvalsEvidence-backed against UAT review materials
[Search efficiency — to confirm][Average lookup time, before vs. after]
[Duplicate-request reduction — to confirm][Once production analytics are available]
Learnings & reflections
Four things I'd carry into the next enterprise workflow: don't replicate the spreadsheet one-to-one — find the decision-critical fields and disclose the rest progressively. AI is only trustworthy when its assumptions are visible and reversible, not when it's fastest. Governance — approvals, audit visibility, change history, role-based actions — isn't a back-office add-on; it's what makes people trust the workflow enough to actually leave the spreadsheet behind. And enterprise design systems need to flex for real operational edge cases — modifiers, cap tables, import errors — or the reusable patterns stop being reusable.
Case study · Guided care navigation for mobile & web
Care Pathways
I turned a scattered health content library into guided, plain-language next steps — and it measurably reduced support calls.
Role
Lead Designer
Timeline
Mar 2024 – Jan 2025
Team
1 designer, 2 product owners, 9 engineers across mobile and web
Care Pathways reframed a sprawling library of health, benefits, and program content as guided journeys inside a member-facing health app and its companion web experience. As Lead Designer I shaped the member experience across mobile and web, aligned it with the workflows care advocates use on the phone, and turned the library into a product model that could scale: care path, then journey, then activity.
16%Fewer repeat calls
10.5%More accepted personalized offers
30+Guided journeys
The problem
People hit major health events — a new diagnosis, a pregnancy, a benefits change, a caregiving crisis — and rarely know what to do next. The programs, benefits, and support services that could help already existed, but they were spread across separate systems and channels, and finding them assumed you already knew what to search for.
The content was not missing. It was unfindable by anyone who could not already name what they needed — which is precisely the person a health event creates. Research made the pattern plain: people think in life events, not product categories, and they stalled on category names they could not interpret.
From library to guided path
The reframe the whole project rests on: content stops being something you store and search, and becomes something that moves you forward.
Representative recreations. Original work under NDA.
Three levels, one mental model
Topic, then guide, then steps. Managing diabetes is the running example: one care path holds several journeys, and each journey breaks down into actions small enough to finish.
Three levels were enough to organize thirty-plus journeys without rebuilding the overwhelming library we were replacing, and shallow enough that a member never had to hold more than one question in mind: what am I dealing with, which situation matches mine, what do I do first.
Designed around life moments, not departments
The landing page asks “What are you dealing with?” rather than presenting a menu of business units. Recommendations carry their reason — “Because you completed Know your numbers” — so guidance stays explainable rather than mysterious.
One catalog, filtered by what you're facing
Personalization needed an escape hatch. The full catalog stays one click away and carries the same status vocabulary, so a member whose recommendation missed their intent can still browse everything.
A topic, broken into situations
One topic resolves into the specific situations inside it. “Just diagnosed” and “managing it for years” are different problems, and the care path page is where that distinction gets made.
Every step ends in one clear action
A diagnosis becomes six steps, each one a single concrete action with a time estimate attached — fifteen minutes, an appointment, a daily habit — so the next move is always visible and always small.The centre of the experience. Opening a step never navigates away — the sheet explains the step in plain language, then ends in one action. The list stays visible behind it, so a member never loses their place in the journey.
Progress without pressure
Done, skipped, and not started are all legitimate states. Skipping is not a failure and not permanent — a skipped step returns after 90 days rather than disappearing or nagging.
Health journeys are not linear, so the system had to be structured and forgiving at once: enough structure to reduce uncertainty, enough flexibility that it responds to someone's situation instead of behaving like a checklist they are failing.
Accessibility reshaped the filters
Before and after. A legend in the image marks which parts were reconstructed from testing evidence and which are directly evidenced.
Testing found that filtering worked but the controls competed with other actions and lacked a clear interaction hierarchy, and that the mobile popover pattern was difficult to use with a screen reader. The rework gave every control a visible, persistent label, made selected states unambiguous through checkboxes and chips, and replaced ambiguous dismissal with dedicated header actions and one persistent apply button.
The model scales to home
Once steps are structured, the home screen can assemble them. Each card states its own provenance — a next step in a guide, a covered program, an employer benefit — so a personalized surface stays legible rather than arbitrary.
Same path, both sides of the conversation
Members and care advocates read the same structure and the same activity state, so a phone conversation picks up where the app left off instead of starting over. Interfaces and permissions stay role-specific.
Impact
16% reduction in repeat callsMeasured against the guide and app support experience
10.5% increase in accepted personalized offersMembers acting on recommended programs and offers
What I'd measure next
Journey starts — how often a member commits to a path at all
Completion — how far through a journey people actually get
Skips and returns — whether the 90-day return brings people back, or whether a skip is effectively an exit
Handoffs to a person — when the guided path stops being enough and a conversation has to take over
Reflection
The hardest problem was designing for nonlinear journeys while still giving people a sense of progress. Too much structure and the experience becomes a checklist someone is failing; too little and it collapses back into the library we were replacing. What resolved it was treating skipping as a first-class state rather than an error — the system keeps its shape, and the member keeps their pace.
What I'd do differently: set up a formal experiment framework earlier, and define success measures at the activity, journey, and pathway levels before launch rather than after. We had directional program metrics but thinner data than I wanted on how individual journeys performed — which is exactly the data that would have sharpened the next round of design decisions.
Case study · AI-assisted provider onboarding workspace
OnboardIQ
Turning a fragmented, manual, multi-system workflow into a guided operating model — targeting a 34–35 day process for sub-20-day execution.
Role
Lead UX Engineer / UX lead
Context
Large healthcare enterprise, internal operations tooling
Status
Future-state design and MVP-in-progress. Metrics shown are targets and planning baselines, not post-launch results.
Executive summary
OnboardIQ is a portfolio-safe name for a provider onboarding redesign that aimed to turn a fragmented, manual, multi-system workflow into a guided, AI-assisted operating model.
The core idea: one intake record, role-specific work queues, AI-prepared evidence, transparent handoffs, and human decision gates. This aligned with the strategy direction of shifting from sequential handoffs to parallel execution across contracting, credentialing, and data loading, coordinated by an orchestration layer.
Framed another way: one provider request, three role lenses, one source of truth — AI doing the assembly, humans making the decisions.
I led UX for the onboarding experience, owning wireframes, work queue interaction patterns, AI summary placement, detail-page structure, stakeholder facilitation, and prototype iteration.
Problem
The existing onboarding workflow was slow, manual, and split across intake, contracting, credentialing, and downstream data-loading activities. Discovery repeatedly surfaced the same contributors to cycle time and rework: manual verification, duplicate attachments, email-template follow-ups, manual network and fee schedule loading, contract review, credentialing review, and fallout handling.
End-to-end turnaround time sat at roughly 34–35 days, against a target direction of under 15–20 days near-term and 10 days or fewer longer-term.
The problem was not "make a better UI." It was a service-design challenge: how to help internal teams coordinate work across multiple handoffs while preserving auditability, human judgment, and operational reporting — and while absorbing state-specific exceptions, special onboarding paths, duplicate requests, missing documentation, and provider-facing status ambiguity.
Discovery and research
Research was primarily artifact review, journey mapping, SME walkthroughs, internal workshops, stakeholder validation sessions, and prototype reviews.
Early workshops focused on empathy mapping, pain points, and model-agnostic intake — standardizing the initial flow regardless of provider model type, and using shared journey materials to identify opportunities. Later workshops reviewed current-state processes for solo and group onboarding, contracting, credentialing, data loading, state-specific workflows, and automation opportunities.
Key inputs
SME process walkthroughs for current-state onboarding, state-specific coverage workflows, specialty workflows, and manual recruitment paths.
Prototype and wireframe validation for work queues, expanded rows, assignment, duplicate review, missing-document flows, implementation type, status, and detail-page actions.
Business feedback analysis showing participants were more engaged explaining current process than critiquing future-state wireframes — which prompted a shift toward crisper, scenario-based prompts.
Key insights
Users needed actionable queues, not dashboards first. Evidence pointed to MVP emphasis on the work queue as the actionable surface, while leadership dashboards and reporting were deferred to later roadmap work.
AI needed to assist, not decide. The direction consistently positioned AI as an evidence-preparation layer, with humans confirming, overriding, or triggering communications. Human-in-the-loop was treated as necessary before acting.
Exception handling was the real design problem. Duplicate requests, missing tax documentation, coverage-specific bypasses, specialty-workflow misrouting, governance review, disclosure review, and reopened requests all created edge cases that would break a linear happy path.
Status and turnaround logic directly affected trust. Stakeholders raised concerns that reopened or out-of-team work could distort turnaround reporting — supporting a distinct "reopened" state and separated timing for work that leaves the onboarding team.
Design strategy
The strategy was to simplify the user's mental model while preserving operational complexity in the system. The future-state direction articulated five principles: model-agnostic intake, upstream validation first, exception-only human work, one tracker with one source of truth, and upstream prevention of downstream fallout.
Translated into three experience principles:
One record, many role lenses. The same request supports contracting, credentialing, approval, and data-loading views without forcing users to reconstruct context.
Evidence before action. AI summaries, evidence cards, validation checks, and source-backed rationales help users decide quickly without hiding risk.
Human accountability by design. Provider outreach, push to contract, duplicate handling, and status transitions all preserve review, confirmation, and audit trails.
Solution design
An AI-assisted onboarding workspace built around:
A work queue containing request identity, suggested entity type, tax identifier, status, state/region, assignment, and AI summary / next-best-action signals.
Expanded-row patterns surfacing duplicate indicators, missing documentation, AI validation results, and action affordances — without forcing users into a detail page for every decision.
Bulk assignment and reassignment, including selected-row affordances and actions such as assign to me, reassign, and clear assignment.
A request detail page with provider snapshot, status, stepper/progress model, exceptions, implementation type, state eligibility and fee schedules, attachments, AI validation checks, and notes/activity history.
Role-specific surfaces for contract managers, credentialing processors, approvers, data-loading operators, provider support, and leadership monitoring.
Notably, the solution avoided over-claiming full automation. AI prepared evidence, classified exceptions, generated summaries, and supported next actions — while human review was preserved at every key decision point.
Validation
Validation ran through recurring stakeholder walkthroughs, internal alignment sessions, and design reviews rather than formal usability testing. Stakeholders reviewed work queue columns, filters, assignment, duplicate criteria, missing-information flows, status naming, and detail-page action placement.
The most useful learning was methodological. Business users gave limited feedback when asked broad questions about wireframes — in one reviewed session, only about 5% of utterances represented actual end-user feedback. I treated that as a research-method problem rather than a user problem, and moved the team toward scenario-based prompts: asking participants what they would do when a request was missing tax documentation, or when it looked like a duplicate. Feedback moved from silence to decision-quality input.
Impact — targets, not measured results
Post-launch measurement was not available at the time of writing. The following are targets and planning baselines:
Reduce end-to-end turnaround time from approximately 34–35 days to a majority path of under 15–20 days near-term and 10 days or fewer future-state.
Shift from sequential handoffs toward parallel contracting, credentialing, and data-loading preparation, with final convergence gates before activation.
Improve operational visibility through queue aging, fallout, straight-through processing, turnaround time, and human-in-the-loop burden metrics in future reporting concepts.
Support managers who track staff throughput expectations of roughly 50 requests per week / 200 per month, with reporting used for aging inventory, assignments, and turnaround time.
Current and planned turnaround-time ranges from the strategy source. Treat as target impact, not realized production impact. Sourced as current/planned ranges, not confirmed post-launch measured results.
Planning figures and workshop estimates — targets and baselines, not measured outcomes.
Metric
Baseline / current
Target or expected
Evidence strength
End-to-end turnaround time
~34–35 days
<15–20 days near-term; ≤10 days future-state
Medium — target, not realized outcome
Overall current process time
~30–33 days
—
Medium — workshop estimate
Contracting time
10–12 days
—
Medium — workshop estimate
Credentialing time
~7 days
—
Medium — workshop estimate
Provider contract signing expectation
—
7 days from provider after contract sent
Medium — operational expectation
Counter-signature volume opportunity
Manual process
~2,000 contracts/month
Medium — planning input
Staff throughput expectation
—
50 requests/week; 200/month
Medium — single source
Feedback quality signal
—
~5% actual user feedback in one reviewed session
Low/Medium — one session
Reflection
This project required shifting from screen production to systems thinking: mapping operational complexity, negotiating scope, building alignment, and making AI understandable and accountable. It also required design leadership through prioritization — when pricing and onboarding competed for attention, the team agreed onboarding should hold full focus until new pricing requirements emerged.
The hardest part was not designing the queue. It was helping stakeholders imagine a future workflow while protecting the operational nuances that made their current process work.
