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
A guided care navigation experience that turned scattered health, benefits, and program content into personalized journeys — so members could see what to do next instead of having to know what to search for.
Role
Lead Designer — research through delivery, mobile & web
Timeframe
March 2024 – January 2025 (11 months)
Team & collaborators
2 product owners, 4 mobile engineers, 5 web engineers, content strategists, clinical and advocate SMEs
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.
Care Pathways reframed that 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 a sprawling content library into a product model that could scale: care path, journey, activity, recommendation, support action.
Context & constraints
The business goal was to move past a repository-style experience and proactively surface relevant guidance based on a member's circumstances — increasing engagement with digital guidance, improving benefit use and program enrollment, and reducing repeat calls to support. The design had to hold up under real constraints:
Mobile and web both had to work, keeping parity where it mattered without ignoring platform differences
Content had to scale across many pathways and journeys without recreating the overwhelming library we were replacing
Member-facing and advocate-facing views needed to stay synchronized, so a support conversation could pick up where the app left off
Personalized recommendations had to be understandable and optional — helpful, not prescriptive
Accessibility gaps, particularly around filters and mobile popovers, had to be resolved before launch readiness
My role & collaborators
I was the only designer on the initiative, working across two product owners and two engineering teams. My contribution was less about screens and more about translation: taking input from content strategists, clinical stakeholders, support leads, and engineers, and turning it into one coherent experience strategy plus implementation-ready design direction for responsive states, filters, journey drawers, and activity details.
Research & insights
What we did
A first moderated study on offers, programs, and pathways — 5 participants, 4 tasks, run over 3 weeks
A follow-up feedback round on the pathway experience itself — 6 participants, 6 sessions across web and mobile
Participants spanned mid-20s to early-50s, clinical and non-clinical backgrounds, average or greater technical comfort
Design jams and cross-functional reviews with product, content, and engineering, plus end-to-end prototype walkthroughs
What changed our minds
People think in life events, not product categories — guidance framed around a diagnosis or a benefits change landed; guidance framed around business units did not
Three themes dominated both rounds: search, clarity, and complexity. 40% of participants said tasks took too many steps, and 60% were primarily on a phone
Label copy was doing more damage than layout — participants stalled on category names they couldn't interpret
Personalization needed an escape hatch: recommendations helped, but people still wanted the full library when the recommendation missed their actual intent
It wasn't intuitive for me when I looked at it — "newly diagnosed," for whatever reason, I don't know.
Participant, moderated feedback session
Design exploration & rationale
The reframe was from content library to guided navigation, and the question I kept coming back to was: how might we help someone understand what to do next while still letting them explore everything available? That produced a nested content model — care path, then journey, then activity — which gave the system room to scale while keeping the member's mental model simple: pick a topic, pick the journey that matches your situation, act on small pieces.
Five decisions carried the design. Guided journeys organized around life events instead of a searchable library, because people couldn't name what they needed. Bite-sized activities with clear calls to action, because long-form health content created real cognitive load. Flexible progression — explore, skip, complete, resume — because health journeys aren't linear. Recommended content shown alongside full browsing access, to balance relevance against control. And a shared content structure behind both the member and advocate views, so support conversations didn't duplicate what someone had already done digitally.
Add a cleared screenshot for this section
[ADD ARTIFACT: the information architecture diagram — care path → journey → activity → call to action — or the journey detail page showing activities and progress states.]
Prototyping & testing
What held up: life-event and condition-based categories made the structure legible; short activities turned abstract needs into next steps; in-progress and recommended areas brought people back; average rating in feedback sessions was 8 out of 10
What changed: pathway and journey descriptions were rewritten to say plainly what each option offered, and explore/library views were iterated for scanning
Accessibility: mobile filter patterns were reworked for screen reader usability and clearer interaction
Structure: journey details were split so a short description and a longer side-drawer explanation could coexist without crowding the page
Outcomes & impact
The experience shipped as a core personalization capability across the app and guide ecosystem, and became the foundation additional care paths were built on.
16.0% reduction in repeat callsMeasured against the guide and app support experience
10.5% increase in accepted personalized offersMembers acting on recommended programs and offers
30+ care pathsSpanning benefits, family support, financial, health conditions, mental health, and staying healthy
Beyond the numbers: members got clearer next steps during genuinely stressful moments and could move at their own pace across devices, and care advocates gained a consistent structure to guide conversations — reducing the one-off navigation help that had been absorbing support time.
Learnings & reflections
The hardest problem was designing for nonlinear journeys while still giving people a sense of progress. What the team learned is that guidance has to be structured and forgiving — enough structure to reduce uncertainty, enough flexibility that it responds to someone's situation instead of behaving like a checklist they're failing. The core shift was from "find content" to "understand what to do next."
What I'd do differently: set up a formal experiment framework earlier, define success measures at the activity, journey, and pathway levels before launch rather than after, and instrument completion, skip, revisit, and handoff behaviour properly. 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.
