Jesse Rego

Intro

Hello Team. Appreciate you taking the time today.

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 Council Lead Librarian - Workday Pattern Library UX Organization Educator & Mentor Co-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 model 50%

Frameworks, patterns, and system architecture

Defined reusable models, framework guidance, and architectural constraints that helped teams implement faster with less local reinvention.

Operating model 50%

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 reach Canvas consumer Legacy UI
Feeds product teams.
Home Organization

Design System

My home team and the source of Canvas tokens, guidance, and pattern foundations.

Canvas tokens Patterns
Feeds platform inputs.
Collaborator & Adopter

Product Teams

Consumers of platform solutions in real product implementation.

Student HCM Support Privacy Talent Recruiting Financials Security Learning Extend
How I Work

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.

Audit Prioritize → Map layout → Deconstruct
Align Deconstruct → Partner
Define Partner → Design / test
Adopt Document / ship
Document Guidance → 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 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.

IIR Support Case Routing configuration screens across setup, edit, and ranking logic views
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.
Case routing research and synthesis board
01 Case Routing Exploration Exploration and understanding of the case routing UI while setting up the research work.
Evolution toward scoped routing patterns
02 Research Planning Brief A research planning document shared with my Systems Analyst and Program Management partner.
Tokenized theming and framework implementation artifacts
03 Usability Script and Synthesis Custom usability script, session recordings, synthesis outputs, and timeline planning.
Case routing interaction and accessibility pattern reference
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 pillars 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.

Case Study 02

Case Study 2: Lightning Migration Playbook

Customer Center was a mission-critical internal platform migrating from Salesforce Classic to Lightning. I led a phased strategy to unblock delivery, stabilize risk, and set up a reusable modernization model.

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.

Workday Support Classic-to-Lightning migration overview
Team & Scope

Cross-functional migration at scale

Team structure included 1 lead designer, 10 Salesforce developers, and 5 BSAs (principal and senior). The effort covered Contacts Management, Case Management, and Tenant Management.

Operating modelDesign lead plus program driver across product, business, and engineering rhythms.

Phase 1

Stabilize and enable

Start with lift-and-shift fundamentals to reduce migration risk, preserve core behavior, and establish a Canvas-aligned foundation the team could confidently implement.

Phase 2

Modernize and reuse

After stabilization, improve workflows, reduce cognitive load, introduce suggestive patterns, and feed contribution components back into the shared system.

Case Study Walkthrough

How the Lightning migration moved from deadlock to a reusable delivery model

Act 1 Heuristic baseline

The first step was making migration quality measurable through side-by-side analysis between Classic and Lightning surfaces.

  • Ran heuristic analysis to expose high-friction interaction and content areas.
  • Tracked UI alignment issues across navigation, section headers, voice and tone, and layout spacing.
  • Created a single baseline that gave all teams the same definition of done.
Baseline migration screen for Customer Center Lightning work
01 Salesforce Classic Case Detail Salesforce Classic case detail baseline, supported by a support team maintaining 2 million lines of custom code.
Alignment planning and migration phase breakdown
02 Two-Phase Migration Proposal Proposal for a two-phased development approach: platform stabilization first, then Canvas Design System groundwork.
Standards and research artifacts used for migration execution
03 Tenant Management Usability Audit Usability analysis overview of the Tenant Management suite and 18 of its features.
Modernization quality pass examples across classic and lightning screens
04 Layout, Tone, and Navigation Enhancements Low-hanging enhancements to improve overall layout, voice and tone, and navigation.
Act 2 System contribution

With migration stabilized, the work shifted into system contribution and reusable component strategy.

  • Established a domain-level design system direction for migration outputs.
  • Defined contribution components including date/time picker patterns, progressive counter cards, and severity indicators.
  • Connected migration decisions back to long-term platform reuse.
Contribution model content tracking sheet for migration reviews
05 Scaled Content Tracking Model Scaling content tracking so designers across product areas could follow migration and maintain consistent patterns.
Component set evolution examples across migration system surfaces
06 Support Suite Component System Support Suite mini design system assembly, with weekly Support UX alignment and components contributed back to the core Design System.
Act 3 Cadence and outcome

Execution held through an intentional communication cadence and handoff checks between business and development partners.

  • Business-team syncs 2x per week to keep scope and decisions aligned.
  • Developer-team syncs 2x per week with handoff validation checkpoints.
  • Outcome documented as a migration playbook teams could reuse.
Sequencing model delivery tracker for tenant and case management workstreams
07 Cross-Functional Sync Loop Two-times-weekly syncs kept System Analysts and Program Managers in the UX loop with full project trackback transparency.
Operating cadence artifacts with changelog, feature states, and rollout planning
08 Developer-Facing Changelog Developer-facing changelog mirrored the analyst version while fitting the workflows and spaces engineering teams used most.
Shared Lightning migration artifacts across tenant, case, and request surfaces
Shared artifacts used to align business and engineering decisions during migration execution.
Outcome Summary

Playbook outcomes from the slide deck

  • Migration unblocked after prolonged deadlock.
  • Teams aligned on sequencing, scope boundaries, and contribution strategy.
  • Foundation established for future UX modernization in Lightning.
  • Delivered a reusable UX Migration Playbook.
38
Features delivered.
3
Product suites updated.
5
Designers aligned.
1
Shared design system foundation used across migration work.
Impact

Delivery regained momentum without sacrificing long-term system quality.

The two-phase model protected near-term migration goals while establishing reusable standards and components that future teams could build from.

Why It Matters

The migration became a platform learning loop, not just a one-time conversion.

Instead of stopping at compliance, the program produced a repeatable playbook that linked business cadence, design standards, and engineering execution.

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.