Inside DisneyHR Portal Modernization
Leading the design system implementation for Disney's ServiceNow migration. Balancing enterprise brand guidelines with SaaS platform constraints and distributed team dynamics.
This work is under an NDA. Designs, components, and processes have been modified for public case study viewing. Read more about the disclaimer here.
About the Project
Disney was moving their HR portal off WordPress and onto ServiceNow, a cloud-based SaaS platform that would become the foundation for multiple departments. My job as UX Lead was to help transition their existing branding elements and introduce a comprehensive UI component kit and Design System for this new platform, starting with the HR admin portal. I was brought in by LTI as a contractor to sit embedded with Disney's US corporate team for the duration of the project. This wasn't just about redesigning screens—it was about bridging two worlds. I had to take Disney's established brand identity from the WordPress environment and adapt it to work within ServiceNow's configuration model, then build the design tokens, component library, and documentation that would enable other teams across Disney to build consistent experiences. The foundation I established would directly impact how multiple departments worked on ServiceNow going forward. And I had four months to get the handoff elements ready so in-house teams could start designing and building branded content in ServiceNow.
Challenges & Issues
This project had some real constraints that shaped how I had to work. Here's what made it challenging:
Pain Point
Four months to deliver: We had to establish design foundations, create a comprehensive component library, build prototypes, and set up complete documentation in a compressed timeline. Every sprint had to count, and prioritization became critical.
Pain Point
Working with teams across time zones: I was managing four offshore designers while coordinating with business analysts, the project manager, product owner, ServiceNow consultant, and domain experts. This meant 6am meetings to sync with the offshore team and 11pm calls to maintain momentum. Sleep schedule was brutal.
Pain Point
Tightly scheduled hands-on work timeframes: Between morning scrums, sprint planning, stakeholder meetings, and design reviews, finding heads-down time to actually do the work was a constant challenge. Every meeting had to deliver value or it was wasting precious time.
Pain Point
Knowledge transfer and RACI assignment management: The offshore team needed context about Disney's brand, ServiceNow's capabilities, and design decisions. I had to structure work using RACI matrices to create clear ownership and enable them to work independently across the time zone gap.
My Process
We worked in a standard Agile setup: sprint planning, daily standups, reviews, retrospectives. The real work happened in how I structured the design work within that framework. I focused on keeping stakeholders aligned, making sure the offshore team had what they needed to work independently, and delivering components that hit our milestones. As the project progressed, I eased out of some meetings to spend more time on hands-on work.
Foundation & Discovery
Started by reviewing all existing design files from the WordPress site—branding documents, old UI elements, everything. Then dove deep into ServiceNow's design system and component library to understand what we were working with. The key discovery was ServiceNow's 'configure, don't customize' philosophy, which fundamentally shaped our approach. I also analyzed how the previous Disney design team had worked and found a mess: lots of hands touching the same files without formal processes, shared elements getting overridden, minimal documentation. That informed my decision to set up a proper master component checkout system in Sketch.
System Architecture & Planning
Working with business analysts and ServiceNow consultants, I helped sized features and stories to understand what was feasible in our timeline. Prioritization came from product owners, but I had to translate that into a roadmap based on dependencies. Set up RACI matrices for the design team so everyone knew exactly who owned what—critical when working across 12+ hour time differences. Mapped out the full component ecosystem: what we needed, what depended on what, what could wait.
Design Tokens
Set up the core design tokens: colors, typography, spacing, iconography. These became the atoms everything else was built from. Disney's brand requirements were straightforward—specific colors, fonts, usage rules—but some requirements had to be created specifically for ServiceNow's patterns. Which brand elements could appear in which ServiceNow UI components? Those decisions needed documentation. Color combinations were tested for accessibility, typography was calibrated for web rendering, and icons were selected to be clear at small scales while maintaining Disney's personality. Used standard industry practices for establishing design tokens and semantic naming conventions.
Component Library Development
Started the component library with all interaction states, accessibility specs, measurements, and usage guidelines. Each sprint, I'd assign component work to the offshore team with clear specifications. They'd execute, I'd review, we'd iterate. The key was making sure they understood not just what to build, but why we were building it that way. Organized everything in Sketch using symbols and shared styles so updates would propagate correctly. The offshore team could grab a component, customize it for their use case, and it would still inherit updates from the master.
Documentation & Prototyping
Created static documentation in Sketch explaining each component: what it's for, how and when to use it and when NOT to use it. With components and documentation, the offshore team could make good decisions on their own. Built interactive prototypes in Sketch and Adobe XD for key workflows, particularly the Admin Dashboard. These served dual purposes: stakeholders could click through to understand how things would work, and developers got reference implementations showing exactly how interactions should behave.
Handoff & Knowledge Transfer
Set up the system so teams could work independently: clear component specifications, design token references, implementation guidelines. The goal was making the design system maintainable without constant oversight. Conducted knowledge transfer sessions with the offshore team and documented decisions so context wouldn't get lost. As we moved through the project, I reduced meeting attendance to focus on hands-on work and proper handoff documentation.
My Role
As UX Lead, I was the bridge between Disney's corporate team and our offshore design team, between brand requirements and platform constraints, between business objectives and technical reality. My days started with 6am calls to sync with the offshore team and sometimes ended with 11pm meetings. In between was the daily Agile process routine: morning scrums, sprint planning, keeping designers and developers synced, managing design-to-dev handoff, and making sure nothing fell through the cracks. That coordination piece between designers, business analysts, and the ServiceNow consultant was crucial but meeting-heavy.
- Design system architecture: Led the development of the design system, establishing component patterns, token definitions, and documentation standards that balanced ServiceNow's platform constraints with Disney's brand guidelines. Set up master file structure and component checkout systems to prevent the organizational chaos that was identified in previous design work.
- Distributed team leadership: Managed a team of four offshore designers across significant time zone differences, which meant 6am and 11pm meetings were standard. Created RACI matrices to establish clear ownership and decision-making authority. Structured sprint work with detailed specifications so the team could execute independently without constant check-ins.
- Requirements translation: Worked with business analysts and the ServiceNow consultant to size features and stories, translating business requirements into actionable design specifications. Served as the communication bridge between what stakeholders wanted, what the brand guidelines required, and what the platform could actually do.
- Brand adaptation: Collaborated with Disney's brand team to understand which brand elements could translate directly to ServiceNow and which needed reimagining. Created new brand requirements specifically for ServiceNow's UI patterns—essentially extending Disney's brand guidelines to cover scenarios they hadn't encountered before.
- Cross-functional coordination: Daily coordination between designers, business analysts, developers, product owners, and the ServiceNow consultant. Managed design-to-dev handoffs, sprint planning, and made sure work didn't get blocked while people were asleep on the other side of the world.
- Quality assurance: Reviewed all component work from the offshore team, ensuring consistency, accessibility compliance, and alignment with both brand guidelines and platform capabilities. Built iterative review cycles into sprints so feedback happened quickly and nothing had to be completely rebuilt.
Methodologies
Discovery & Research
The discovery phase was about understanding two systems simultaneously: ServiceNow's platform and Disney's brand. ServiceNow operates on a 'configure, don't customize' philosophy, which fundamentally shaped our approach. We weren't building a custom design system from scratch—we were figuring out how to apply Disney's major, recognizable brand within ServiceNow's data platform constraints. That constraint actually made decisions easier once I understood it. Instead of infinite possibilities, we had clear parameters to work within.
I started by going through all the previous design files—branding documents, old UI elements from the WordPress site, everything. What I found was revealing: the previous Disney design team had lots of hands touching the same files without any formal process or master file structure. Shared elements were getting overridden, documentation was minimal, and there was no clear system for who owned what. That directly informed one of my first decisions: set up a proper master component checkout system in Sketch so we wouldn't repeat those mistakes.
On the ServiceNow side, I immersed myself in their design system documentation and component libraries to understand what we had to work with. Working with the ServiceNow consultants helped me understand what the platform could do natively versus what would require workarounds. Looking back, we probably could have found and made better use of available ServiceNow UI resources sooner instead of recreating some patterns from scratch.
Disney's brand requirements were fairly basic and common—specific colors, font styles, usage rules. But they were optimized for consumer-facing touchpoints, not enterprise SaaS platforms. Some brand elements translated directly. Others needed adaptation. And some requirements had to be created from scratch: which brand elements could appear in which ServiceNow UI components? Which types of content could or couldn't be used in certain ServiceNow UI patterns? Those decisions needed documentation and brand team approval.
Prioritization was structured by business and product owners. Working with analysts and consultants, I accurately sized features and stories to understand dependencies: what do other teams need first? What unblocks the most work? Those foundational components became priority one.
ServiceNow's 'configure don't customize' philosophy was a constraint that made decisions clearer. Once I understood the platform's boundaries, I could design confidently within those parameters rather than constantly questioning what was possible. The platform has real constraints, but they became useful design parameters.
Disney's brand guidelines needed smart adaptation, not direct application. The question became: what makes something 'feel Disney' versus what's just a specific implementation for a different medium? That distinction shaped everything and required creating new brand requirements specifically for ServiceNow's patterns.
The previous design team's file management chaos taught me that organizational systems matter as much as the designs themselves. No amount of good design work survives poor file organization when multiple people are collaborating. Setting up proper master file structures and checkout systems from day one prevented repeating their mistakes.
Foundational components had to come first based on dependencies, not based on what seemed most interesting to design. If other teams were blocked waiting for form fields, form fields became priority one. Strategic sequencing was more important than comprehensive coverage.
Working with the ServiceNow consultants early helped me understand what was native platform capability versus what would need custom work. That knowledge informed every design decision and created a communication bridge between brand wishes and technical implementation.
The Design System
We delivered a comprehensive design system in Sketch that enabled Disney's product teams to build consistent HR experiences on ServiceNow. The system included design tokens, component libraries with full interaction states, static documentation, and interactive prototypes that served as reference implementations. Everything was architected for practical adoption: clear RACI ownership, self-service documentation, and patterns that worked within ServiceNow's configuration model. The Admin Dashboard prototype became the centerpiece—a fully interactive click-through that showed stakeholders how the system would actually work and gave developers a reference implementation.
Design Foundations
The design tokens became the foundation: colors, typography, spacing, and iconography. For colors, I used standard industry practices to create semantic naming conventions—not just 'blue-500' but 'primary-action' and 'error-state'—so designers would understand when to use what. Every color combination was tested for WCAG contrast ratios. Disney's brand colors mostly translated directly, but we had to ensure they met accessibility standards within ServiceNow's rendering environment. Typography required recalibration for web font rendering and ServiceNow's font stack limitations. Created a clear hierarchy that worked at all screen sizes: five heading levels, three body sizes, specific use cases for each. The scale gave designers enough options without being overwhelming. Icons presented an interesting challenge because Disney's visual language is playful, but enterprise software needs clarity first. Found a middle ground: icons that had Disney's friendly aesthetic but were immediately recognizable at small sizes. Each icon was tested at various scales to ensure clarity.
Component Library
The component library was the heart of the system: buttons, form fields, cards, modals, navigation elements, data tables, everything teams would need to build HR workflows. Using standard industry processes for component development, each one needed all interaction states (default, hover, focus, active, disabled, error), accessibility specifications (ARIA labels, keyboard navigation, screen reader text), usage guidelines (when to use this versus that), precise measurements and spacing, and code-friendly naming that matched what developers would write. Organized everything in Sketch using symbols and shared styles. The offshore team could grab a component, customize it for their specific use case, and it would still inherit updates from the master. That organizational structure isn't glamorous work, but it's what makes a design system actually usable at scale when multiple people are working in the same files. Static documentation was just as critical as the designs. Created documentation pages in Sketch for every component explaining what it's for, when to use it, when NOT to use it, and common mistakes to avoid. The offshore team and future designers needed to make good decisions without asking me every time.
Brand Integration
Adapting Disney's brand for ServiceNow required systematic evaluation of brand guidelines against platform capabilities. Without compromising the brand we had to figure out how Disney's visual language could live within ServiceNow's configuration model. Some brand elements translated directly. Others needed creative adaptation. Worked iteratively with Disney's brand team to identify what could configure natively in ServiceNow versus what would require workarounds. We had to create new brand requirements specifically for ServiceNow's UI patterns—essentially extending Disney's brand guidelines to cover enterprise SaaS scenarios they hadn't documented before. Which brand elements could appear in which ServiceNow components? Which types of content could be used in certain UI patterns? How should Disney's playful aesthetic translate to data-heavy admin interfaces? Those decisions needed documentation and approval. The key was maintaining brand integrity while respecting platform constraints. The result didn't look like committee-designed compromise. It looked like Disney—just adapted intelligently for a different medium and purpose.
Interactive Prototypes
Static designs only tell part of the story, so I built interactive prototypes in Sketch and SeviceNow for key workflows. The Admin Dashboard prototype was the what I'm most proud of from this project. The click-through became the reference implementation for the project moving forward. These prototypes served two critical purposes. First, stakeholders could click through and understand how things would actually work. That's when people really get it. The prototypes closed the gap between design intention and stakeholder understanding. Second, developers got reference examples showing exactly how interactions should behave, what transitions to use, and how error states should appear. The prototypes became the source of truth for implementation details.
Admin - Add a new role
Admin - Roles related pages
Admin - Add new page
Admin - Page related pages
Key Learnings
Insights and knowledge gained from this project that shaped my approach to future work.
Designing Within System Constraints
This project taught me to see platform constraints as design parameters rather than limitations. Take time to learn as much as you can about the platform capabilities and how the system works first. As a designer, learn how to design within system guidelines and not outside the box. It's important to understand the platform and its workings. ServiceNow's 'configure don't customize' philosophy initially seemed restrictive, but once I understood it deeply, it made decisions faster and clearer. When you truly understand a platform—not just how to design for it, but how to think within its mental model—you make better decisions and avoid expensive mistakes. That knowledge compounds on every subsequent project. Similar to my previous experience with Salesforce, learning the IT Service and CRM platform deeply was invaluable.
Synchronizing Across Time Zones
The need for a lead to make the time, even if it means odd hours, in order to synchronize deliverables between on-site project teams and distributed design teams is crucial. Working with an offshore team taught me that clarity is everything when there's a 12-hour time difference. I had to schedule 6am and 11pm meetings throughout the project to maintain momentum. Ambiguity that would be fine when everyone's in the same office becomes a project-blocking issue when someone's waiting for you to wake up and respond. I learned to over-communicate and over-document: write down decisions and reasoning, record meetings, create detailed specifications. It feels like overhead in the moment, but it prevents days of lost time. A question that takes five minutes to answer in person can cost a full day when you're working asynchronously.
Organization and Documentation
Good file organization isn't always fun, but it's critical when multiple people are collaborating in the same files. Making component and UI design kits requires treating Sketch file structure as seriously as the designs themselves: clear naming conventions, logical grouping, well-organized symbols, proper master component systems. The previous design team's chaos—multiple designers overriding shared elements with no formal process—taught me this lesson clearly. The difference between a design system that gets adopted versus one that gets ignored often comes down to whether people can actually use it without confusion.
Bridging Brand and Technical Reality
Designing within another design system is crucial. It's important to know the constraints and capabilities, and make sure there is a communication bridge between brand wishes and tech implementation. Enterprise design work requires constantly bridging brand aspirations and technical constraints. It's not enough to understand the brand guidelines or know the platform capabilities—you need to be the translator between those worlds. Understanding Disney's requirements and ServiceNow's technical capabilities, I learned more about facilitating conversations between teams and creating solutions that respected both sides.
Strategic Prioritization Under Pressure
Four months sounds like a lot until you break it down into sprints and account for review cycles and handoff. I got better at identifying what's truly foundational: what do other teams need first? What unblocks the most work? I had to deliver value in the right sequence so the project keeps moving forward. Working with business analysts to size features and stories, I learned that strategic sequencing based on dependencies matters more than client "wants".
Project Overview
Techniques
Tools
Tags
Ready to Work Together?
Let's apply this process to your next project and create something amazing together.