Case study · 03

Aya Operations Platform

Rebuilding the operating system behind healthcare staffing.

Senior Product Manager · Aya Healthcare · Systems design · Data architecture

Context

The Problem

As Aya scaled its enterprise healthcare staffing business, three fundamentally distinct operational concepts — cost centers, physical hospital units, and job requirements — had become fused into a single legacy data structure. What started as a convenient shortcut calcified into a systemic constraint.

Duplicate records proliferating across the system.
Inconsistent reporting that eroded client trust.
Onboarding that required heavy manual support from Aya teams.
Changes in one area causing unexpected downstream ripple effects.

The problem wasn't a bad form. It was a broken operational data model disguised as a UX issue.

Solution

Separate the three concepts at the data model level — not just in the UI.

Entity

Purpose

Cost Centers

Financial ownership and budget attribution

Physical Units

Hospital departments and care settings

Job Requirements

Role specs, credentials, and staffing rules

Rather than treating them as a single entity, separating them created a cleaner operational architecture, eliminated duplication, and made reporting consistency a structural guarantee rather than a manual effort.

Approach

Key Decisions

Fix the model, not the interface

The temptation was to redesign the form and add better labels. Surface‑level UI changes would have left the underlying duplication and inconsistency in place. The only durable fix was restructuring the data model itself — which meant designing for migration and backward compatibility from day one.

Build for client self-service

Historically, unit and job requirement data required Aya support teams to configure and maintain. I prioritized a self‑service model that transferred ownership to clients — reducing internal support load, accelerating onboarding, and giving hospital administrators direct control over their own operational data.

Migrate without disrupting live operations

Aya couldn't pause operations to rebuild a core system. The migration strategy required supporting existing workflows in parallel with the new model during transition — phasing out legacy structures without breaking live onboarding, reporting, or client‑facing tooling.

Results

Outcomes

Core data model modernized with clean separation of entities.
Duplicate records eliminated across cost centers, units, and requirements.
Reporting consistency improved structurally — not patched.
Client self‑service capabilities shipped, reducing onboarding support burden.
Onboarding workflows made more scalable for new enterprise clients.
Migration executed without disrupting live operations.

Reflection

What I Learned

Many product problems that look like UX problems are actually systems problems. Improving the surface without fixing the underlying architecture produces temporary relief. The hardest part wasn't the redesign — it was convincing the organization that a model‑level intervention was worth the migration complexity.

Back to home Talk about this work →