Horizontal Design Leadership · Enterprise HCM
Re-architecting a fragmented enterprise product
As the platform’s horizontal design lead, I redefined the navigation architecture and interaction model across 8 product areas, establishing shared structural foundations that aligned 32 teams under a unified product system.
Role
Horizontal Design Lead
Scope
8 product areas — benefits, docs,
org chart, WFM, onboarding,
profile, forms, cases
Focus
IA, Navigation, Interaction
Design, Design Systems
Problem
The same interactions, all implemented differently
Dayforce grew through acquisition and parallel team expansion. Each of the 8 product areas in scope had built its own record management interactions, and page layouts. Filtering records in Benefits was a completely different interaction than filtering in Workforce Management — not because users needed it to be, but because no one had defined the shared architecture. 32 product teams in total at Dayforce were compounding the divergence every sprint.
Strategic Bet
Work horizontally across carefully selected 8 product areas simultaneously — not embedded in one module. The bet: solving shared structural problems once would be exponentially more valuable than optimizing any single surface.
Design Approach 1 · Wayfinding
One navigation architecture for all product areas
Three patterns became the architectural foundation — each designed for coherence to real user journeys, not org charts.
FRAMEWORK: NAVIGATION
Feature Navigation
6 levels of nested menus. Flattening would overload the top-level; keeping them meant users stayed lost.
Decision
Restructure around user tasks, not product modules. "Time-off requests" now lives under the employee workflow — not the WFM admin tree where engineering built it.

PAGE-LEVEL ACTIONS & WAYFINDING
Omnibar
Page title, actions, and breadcrumbs in one component. Replaced three team-specific implementations with one.

LANDING PAGES
Dashboard Page Layout Pattern
Three-tier container taxonomy — grounding orientation, aggregated action items, clear path to detail. Teams control what they surface; the how is a solved problem.

Design Approach 2 · Record Management
Record management system that scales
80% of Dayforce is data tables. Without a shared template, 32 teams built countless different configurations — the highest-leverage problem to solve.
COMMON LAYOUT
Record List Page Layout Template
Teams needed domain flexibility; users needed cross-domain consistency.
Decision
Composable template: fixed zones (header, filter bar, table, detail panel) with flexible slots. Teams configure domain content; the interaction contract — filtering, selection, bulk actions — is inherited. Design system as interaction architecture, not just component library.

DIFFERENT PERSONAS, DIFFERENT NEEDS
Persona-driven Variations
Two interaction modes from the same template: Admin views optimize for density and inline editing. Employee views optimize for clarity via side-panel editing. Every team inherits both.

ADMIN / POWER USER — Inline-editable, high density

EMPLOYEE — Side panel, focused editing
Impact
A platform that feels like one product
8
Product areas modernized
32
Teams adopted the patterns — including teams I never directly worked with
5 mo
To ship all 8 areas. Each surface faster than the last.
Before
Each product area designed independently. Same problems solved five different ways. Pattern debt compounding every sprint.
After
Interaction contracts that transfer across surfaces. Users who learn filtering in Benefits already know filtering in WFM. New features inherit architecture instead of reinventing it.
Reflection
What I'd do differently
The hardest part was organizational alignment, not design. The breakthrough: find the 80% that's genuinely common, make it undeniable through evidence, then give teams real control over the 20% that's legitimately different. Shared research synthesis earlier — bringing researchers from different modules into the same room — would have accelerated this by months.
You can't mandate quality from above. The patterns succeeded because teams wanted to use them — they were sharper and faster than building from scratch. That's the only kind of scale that holds.