Restructuring a Platform's Data Layer to Unlock Scale and AI

Background

Workday Journeys is a platform built for the moments that matter most at work: onboarding, parental leave, a job change. HR teams use it to guide employees through complex, personal transitions at scale, delivering the right guidance at the right time without doing it manually for each person.

The problem

The journey category, the data layer above every journey object, controlled the end-user experience: users could only have one active journey per category at a time. The assumption made sense at launch, but the longer the field existed, the more it constrained what customers could do. An admin who distributed an End of Year Career Conversations journey in 2025 could not redistribute it in 2026 without starting from scratch. If Sally took a parental leave, once for each of her kids, she would not receive the parental leave journey that second time around. Admins were bloating workspaces with duplicate builders and tracking content in spreadsheets because the system gave them no other option. More than 300 customers had requested a fix, more than double any other investment request.

The problem went deeper than distribution. We had no product data on how customers were actually using journeys because category names were customer-defined and never quantifiable. That gap blocked integrations and AI at a time when both were becoming priorities across Workday.

How I approached it

This problem had been plaguing customers for years, but workarounds existed and higher-priority value drivers took precedence. I pumped the breaks until the product scaled enough AND the fix became critical for where the product needed to go next.

We went in knowing distribution was broken. Research surfaced how much bigger the downstream impact was: admins couldn't organize workspaces, couldn't maintain or duplicate journeys without starting over, and were keeping complicated documents just to collaborate and build content. None of this was known before we started.

The strategy had to stay tighter than the problem. Together with my design partner, engineering lead, and research partner, I designed a one-year approach: bitesized value slices, each delivering independently, each with a heavy emphasis on product metrics because it was just as critical for us to understand how the product was being used as it was to fix the experience. I rated every slice by business criticality and alignment to the fundamental problem. Most of what admins had cited (duplication, maintenance, collaboration) got moved into independent initiatives. Those were real pain, but they didn't work toward fixing the data model, which was the prerequisite for integrations, AI, and product-wide scale.

What changed

A new use case field on the category, paired with a marketing partnership, gave us product data we had needed for years. Our team could FINALLY see how customers were using Journeys across 12 core use case categories and convey that scale to the rest of the organization.

Unlocking multiple distributions was a small change that created a huge lift. Customers who had been working around the limitation for years were thrilled that we were listening and delivering.

A simplified admin workspace let admins focus and organize instead of navigating a deep sea of everything.

Those three phases, combined with the self-service initiative, unblocked the product's path to integrations and AI-driven suggestions. Those next steps fell outside this initiative by design. We were focused on the tightest components, maximizing near-term value while setting up what came next.

What I'd do differently

This initiative grew legs because of how connected each piece was to the next and how fundamental the data model is to everything the product produces. The phased approach and value slices were right, but we could have scoped even tighter: CORE items only, more design critiques, and harder cuts to scope.