I’m a Platform and Systems Designer with about 10 years at Workday, focused on scaling UI architecture across 70,000+ product surfaces.
My work sits at the intersection of design systems, product, and engineering. The throughline is straightforward: reduce fragmentation, increase reuse, and turn platform investments into product adoption.
Technical Lead - Workday Design CouncilLead Librarian - Workday Pattern LibraryUX Organization Educator & MentorCo-created the UX Platform design role and support process
Conversation frame
What will we be learning today?
01
Operating model
How framework work and embedded product work reinforced each other to create real adoption.
02
Decision lenses
The decision lenses I use to standardize the right things, preserve the right flexibility, and create leverage across teams.
03
System stories
Two examples where local product problems became reusable system models that teams could adopt at scale.
My Role in Platform
I operated as a multiplier across the product suite.
At Workday, I split my time between building frameworks and embedding with product teams to drive adoption. The value of the role was not producing more artifacts. It was reducing fragmentation, introducing reusable models, and making sure platform work translated into real product implementation.
Identify fragmentation early, before teams lock in one-off solutions.
Define frameworks, patterns, and constraints that increase reuse across product areas.
Drive adoption through real implementation, not guidance that sits outside product work.
Shape how the system evolves over time, not just how one screen gets built.
Operating model60%
Frameworks, patterns, and system architecture
Defined reusable models, framework guidance, and architectural constraints that helped teams implement faster with less local reinvention.
Operating model40%
Embedded product work to operationalize adoption
Embedded with product teams so the system proved itself in real workflows, real constraints, and real shipping conditions.
Platform UX map
How my role connected Design System, UI Platform, and product-wide adoption
Primary Partner
UI Platform
Consumes Canvas guidance and turns it into reusable framework and pattern infrastructure.
98% suite reachCanvas consumerLegacy UI
Feeds product teams.
Home Organization
Design System
My home team and the source of Canvas tokens, guidance, and pattern foundations.
Canvas tokensPatterns
Feeds platform inputs.
Collaborator & Adopter
Product Teams
Consumers of platform solutions in real product implementation.
My work is less about following a standard design process and more about making the right decisions at scale.
In platform environments, the challenge is rarely inventing a new flow. It is deciding where standardization creates leverage, where flexibility still matters, and how to make the system easier for teams to adopt than a one-off solution.
Lens 01
Audit
Find where patterns diverge across product areas and begin creating avoidable complexity for teams.
Lens 02
Align
Decide what should standardize, what should remain flexible, and where the system boundary should live.
Lens 03
Define
Reuse proven primitives when possible so teams can build from the system instead of rebuilding locally.
Lens 04
Adopt
Measure success by adoption, not just by how polished the first implementation looks.
Lens 05
Document
Document the model so teams have a clear path to use it without reopening the same decisions.
AuditPrioritize → Map layout → Deconstruct
AlignDeconstruct → Partner
DefinePartner → Design / test
AdoptDocument / ship
DocumentGuidance → Ship
Product
Design
Platform
Prioritize
Use roadmap visibility and org signals to target the most meaningful system gap.
Map layout
Identify the relevant pagetype, layout, ownership seam, and product impact area.
Deconstruct
Pull apart the flow into components, layout logic, and repeatable architecture.
Partner
Work with impacted teams so the solution addresses local needs while staying universal.
Design / test
Iterate in product, validate with feedback, and refine the system under real constraints.
Document / ship
Turn the work into adoption guidance, implementation assets, and repeatable rollout paths.
Component
Layout
Page Type
Framework
UIC-Features
WD-C
Canvas
10 yrs
Platform UX experience inside Workday’s design systems and product ecosystem.
70k+
Product surfaces, tasks, and reports shaped by the larger system architecture decisions behind this work.
60 / 40
Framework definition balanced with embedded product work to make adoption real.
Scale
The focus was not isolated UI polish. It was system leverage across design, product, and engineering.
Case Study 02
Customer Center Migration
Faced with a high-pressure migration from Salesforce Classic to Lightning, I uncovered outdated and misaligned design work and redirected the effort into a two-phase migration plan grounded in standards and accessibility.
Context
Support teams had to move from Salesforce Classic to Lightning fast
The migration allowed only modest UX updates to a product suite that had gone more than a decade without meaningful design work, so every decision had to balance modernization with timeline risk.
Problem
Initial design direction was outdated, out of scope, and rejected
The first proposal was six versions behind standards, misaligned to business goals, and introduced sweeping UX changes beyond agreed scope. Stakeholders rejected it to protect delivery timelines.
System patternMigration pressure exposed a governance gap: without shared standards and scoped phases, teams defaulted to either risky redesign or low-value lift-and-shift.
Key Decision
Reset the plan into a phased migration strategy
I introduced a two-phase plan: Phase 1 focused on safe migration with Canvas and accessibility alignment, while Phase 2 created space for deeper experience improvements after stabilization.
Solution
Standards-based delivery with stakeholder alignment built in
The work combined UX audit findings, scoped improvements, tracking for hierarchy/content updates, and weekly reviews with cross-functional partners to keep decisions moving and delivery stable.
Case Study Walkthrough
How the migration moved from rejected proposal to shippable phased delivery
Act 1 Discovery
I started by auditing the current support feature set and pressure-testing the original proposal against standards, scope, and business constraints.
Audited Tenant, Contacts, and Case Management flows to establish migration reality.
Documented that the proposed direction was outdated and outside agreed UX scope.
Captured the timeline risk that had already blocked decisions for months.
01 Identify gapsMigration proposal reframed around practical constraints.02 Scope calibrationPhase one focused on feasible usability and structure improvements.03 Decision pathA working model for communication and governance across teams.
Act 2 Alignment and planning
With the risk visible, I redirected the effort into a phased approach that protected delivery while still improving experience quality.
Introduced a two-phase roadmap to separate migration safety from deeper redesign.
Mapped content hierarchy and verbiage updates into a trackable, scalable process.
Kept stakeholders aligned through regular review points and clear decision boundaries.
04 Technical alignmentPartnering with engineering to constrain scope and de-risk implementation.05 Design source of truthSpecs and component decisions were organized for handoff and consistency.06 Stakeholder approvalA practical proposal that balanced UX progress with timeline constraints.
Act 3 Delivery and migration
The final stage was execution: ship safely, preserve alignment with standards, and keep communication tight as feature-level decisions landed.
Delivered specs with trackbacks into the Figma repository for implementation clarity.
Introduced targeted usability path improvements where developmentally feasible.
Ran weekly cross-functional reviews to keep scope, quality, and momentum aligned.
07 Phase one rolloutUsability and hierarchy updates delivered within migration boundaries.08 Program rhythmOperational cadence that kept stakeholders informed and engaged.09 Execution supportDeveloper-ready guidance helped migration work ship with fewer surprises.
A shared design source with component and specification artifacts that supported phased migration delivery.
Solution details
How the migration strategy translated into delivery mechanics
Audited features across Tenant, Contacts, and Case Management before proposing change.
Created a scalable process for tracking hierarchy and content updates across surfaces.
Introduced usability improvements only where technically feasible within timeline limits.
Delivered spec screens with traceability to source files while development built in parallel.
90%+
Design system alignment across migration outputs.
4
Product areas migrated.
30+
Features safely migrated.
2
Phased migration plan balancing stability and modernization.
Impact
A stalled migration became a deliverable cross-functional plan.
The reset replaced rejected work with an executable roadmap, aligned to Canvas and accessibility standards, and gave teams a clear path to ship safely under pressure.
Why It Matters
It protected timelines without defaulting to low-value lift-and-shift.
By structuring work in phases and grounding decisions in standards, the team reduced delivery risk while still improving usability and long-term maintainability.
Case Study 01
Case Study 1: IIR Support Case Routing
To address growing complexity in case routing and delegation across Workday Support teams, I led research and strategy work that clarified scope, risk, and resource planning for a more scalable routing model.
Context
Case routing complexity was outpacing team coordination
More than 10 support teams across three time zones were managing delegation with inconsistent rules, language, and workflows, making routing behavior harder to scale and maintain.
Constraint
Routing logic had concentrated ownership and weak shared vocabulary
The case routing UI and logic had largely been managed by one contributor, while terminology and process expectations varied by team, increasing operational and scalability risk.
Delivery conditionBefore implementation planning, teams needed a common language and a clear sizing model to align scope, complexity, and resource requests.
Insight
Research showed wide variance in delegation patterns and terminology
Targeted sessions with Directors, Managers, and Analysts surfaced inconsistent routing expectations across regions, which made feature-level planning unreliable without framework alignment.
Key Decision
Use research outputs to drive a shared phased effort model
I translated findings into collaborative workshops and a shared deck that mapped enhancement options by effort, risk, and value so BSAs could frame realistic development asks.
Case Study Walkthrough
How case routing moved from fragmented local rules to a shared planning model
Act 1 Discovery
I started by planning and running targeted discovery sessions to understand how teams delegated and received cases across regions and roles.
Facilitated structured sessions with Directors, Managers, and Analysts across support teams.
Used a custom interview script to surface delegation pain points and expectations by timezone.
Captured gaps in terminology, routing logic, and workflow consistency across teams.
01 Discovery synthesisResearch outputs that exposed routing variation and planning blind spots.
02 Pattern framingWorking sessions used to align needs across teams and contexts.03 Framework alignmentArtifacts connecting routing decisions to scalable framework behavior.
Act 2 Collaborative workshops
After discovery, I synthesized findings with the working team and used workshops to align on realistic enhancement paths rather than one-off local fixes.
Clarified where current routing behavior could be stabilized versus redesigned.
Connected support-team needs to likely development effort bands.
Built shared understanding between UX, Product, Dev, and BSA partners.
04 Interaction constraintsAccessibility and behavior constraints made explicit for routing flows.05 Effort modelShared reference for evaluating implementation options.
06 Scoped variantsDesign options mapped to complexity and risk.07 Framework signalWorkshops made the path to scalable routing clearer for partners.
Act 3 Planning and resourcing
The final stage translated insight into a strategic deck and planning language that helped teams size work, prioritize investment, and sequence delivery.
Outlined levels of effort for proposed enhancements, with associated risk and value.
Enabled BSAs to frame resource requests with clearer scope assumptions.
Established a shared vocabulary to support scalable delegation system decisions.
08 Implementation guidancePattern guidance linked routing behavior to practical implementation constraints.09 Shared deckA common planning artifact used to align leadership and delivery teams.
10 Effort tiersOptions framed to support prioritization and phased investment.11 Shared vocabularyArtifacts that improved cross-team alignment on routing terminology and workflow rules.
Reference artifact tying routing behavior, usability, and accessibility decisions back to a scalable framework direction.
Framework details
How routing discovery became a shared planning and delivery model
Ran multi-role research sessions across distributed support teams.
Synthesized findings into workshops that aligned UX, Product, Dev, and BSA partners.
Built a shared deck with effort tiers, risk framing, and value tradeoffs.
Created a clearer path to scale case delegation logic beyond local team configurations.
1
Shared deck used by leadership to frame resource requests.
3
Development effort tiers defined for planning and prioritization.
6
Support teams able to tailor custom routing rules.
10+
Teams researched across 3 time zones to align delegation workflows.
Impact
Fragmented routing assumptions became a shared strategic plan.
The work gave teams a clearer way to size engineering effort, align terminology, and prioritize enhancements for a more scalable case delegation system.
Why It Matters
It reduced planning risk before expensive implementation decisions.
By aligning cross-functional teams on effort, vocabulary, and constraints, the initiative created stronger foundations for future routing investments and delivery confidence.
Frameworks & Closing
Across the work, the throughline is turning fragmented product experiences into scalable systems.
Not by adding more components, but by defining the right constraints. The work I do best is identifying patterns that should exist, defining how they scale, and driving adoption across teams.
Capability 01
Campaign Management
Send Message Enhancement
Document Generation Framework
Survey creation
Capability 02
List Detail Functionality
Inbox functionality
Notification Architecture
Capability 03
Business Process Framework
Parallel step functionality
Capability 04
Page Builder Platform
Expression & Loop builder
Flow builder
App Creation Dashboard
UX investment model
Capability 05
Configurable Security
Worked inside a structural permissions framework where architecture clarity and product usability were tightly linked.
Capability 06
Implementation Home
Connected platform structure to onboarding and implementation guidance so customers had clearer entry points into setup and configuration.
System-level throughline
The work I do best sits above the individual screen.
Identify patterns that should exist
Define how those patterns scale
Drive adoption across product teams
Reduce variability through the right constraints
Closing
That’s the work I’m excited to continue doing.
What continues to pull me toward architecture and systems design is the chance to make product teams more effective by giving them better primitives, clearer choices, and a stronger path to reuse. That’s the throughline of my work: defining systems that scale across teams, reduce one-off work, and turn platform decisions into product impact.
