Case Study

Building a Design Operating System for a Growing Product Team

Reducing manager dependency and increasing designer autonomy through a scalable design operating model.
  • Role: UX Manager / UX Lead
  • Company: Yum! Brands
  • Team: I5 Product Designers, Engineers, Product Managers, Business Analysts, and cross-functional stakeholders
  • Duration: 4 months
  • Focus: Team scalability, designer enablement, delivery visibility, stakeholder alignment, and design operations

Some details and visuals have been redacted or adapted to protect proprietary information. The case study emphasizes leadership approach and outcomes over exact designs.

Horisontal infographic showing key UX process transformation outcomes: JIRA automation linked to design stages; delivery time reduced from 244 to 88 days; centralized FigJam documentation hub; weekly design team syncs and retros; process scaled to multi-location teams.

Executive Summary

As the design team grew from two designers to five, I realized our way of working was no longer scalable.

Project status, process expectations, and delivery planning largely lived in the manager’s head. Designers frequently depended on guidance for next steps, engineers lacked visibility into design progress, and stakeholders had limited insight into delivery timelines.

To address this, I designed and implemented a lightweight design operating system that introduced shared workflows, planning practices, visibility mechanisms, and team rituals. The goal was not to create more process, but to help designers become more independent, improve predictability, and allow the team to scale without increasing management overhead.

The result was a more autonomous design team, improved stakeholder visibility, stronger cross-functional collaboration, and significantly faster delivery cycles.

πŸ”„ JIRA Automation

Dynamic workflows based on UX stages; auto-generated tickets with Definitions of Done, Steps, Templates, and Best Practices

🧭 Design Process Framework

Standardized across 5 core stages (Kickoff β†’ Research β†’ Design β†’ Handoff β†’ ValidationΒ  ) with clear checkpoints and sign-offs

🧠 Centralized Knowledge Hub

FigJam workspace storing project timelines, research summaries, and design links in one source of truth

🀝 Design Team Enablement

Shared planning practices, weekly syncs, and retrospectives that increased designer ownership and reduced dependency on manager guidance

πŸ“‰ Time-to-Delivery Improvement

Reduced average delivery time from 244 days to 88 days.

Directional metric based on available historical project data.

Β 

πŸ˜€ Engineer Satisfaction Score

Informal feedback rated around 8.4/10, with engineers noting smoother handoffs and better design clarity.

🌍 Scalability

Operating model adopted by additional teams and locations, creating a shared language for planning, delivery, and collaboration

CHallenge

As the design team expanded, I began noticing a recurring pattern: project progress depended heavily on manager coordination.

Designers regularly asked what to do next, project status was difficult to track, and important process knowledge existed primarily through informal conversations. Engineers often relied on direct updates to understand where projects stood, while stakeholders had limited visibility into timelines and progress.

The existing approach worked when the team was small. As the team grew, it became increasingly difficult to maintain quality, consistency, and delivery speed without creating bottlenecks.

The challenge was creating a way for the team to scale without making the manager the coordination point for every decision, project, and milestone.

Screenshot showing a Slack conversation between cross-functional team members discussing design versioning confusion. Messages reveal uncertainty over which screen version to implement, concerns about developer misunderstanding, and discussion of icon placement. A blurred Figma preview is partially visible on the left, representing the overlapping design assets that led to misalignment

My Role

As UX Manager, I led the initiative from problem identification through rollout and adoption.

My responsibilities included:

  • Identified team scalability bottlenecks.
  • Designed and introduced the operating model.
  • Coached designers on planning and project ownership.
  • Drove adoption across design, product, and engineering partners.

Β 

Rather than introducing a rigid framework, I focused on creating enough structure to improve predictability while preserving team autonomy.

Understanding the Problem

Before proposing solutions, I examined how projects were actually moving through the team.

This included:

  • Reviewing past projects to identify delivery delays and recurring bottlenecks.
  • Conducting informal conversations with designers, engineers, PMs, and business analysts.
  • Analyzing retrospective feedback and recurring team frustrations.
  • Mapping where coordination depended on manager intervention.

Several patterns emerged:

  • Designers lacked confidence in planning and sequencing work.
  • Project milestones were inconsistent across teams.
  • Engineers struggled to understand design status and readiness.
  • Stakeholders had limited visibility into progress.
  • Delivery timelines were difficult to predict.
The underlying issue was not a lack of talent or effort. It was the absence of a shared operating model.

Designing the Operating Model

Rather than imposing a top-down process, I worked collaboratively with the team to define what an effective design workflow should enable.

Together we aligned around several goals:

  • Clear ownership.
  • Greater delivery visibility.
  • Consistent planning practices.
  • Reduced dependency on manager coordination.
  • Better collaboration with engineering and product teams.

Β 

Result

The resulting framework introduced five core stages:

Kickoff β†’ Research β†’ Design β†’ Handoff β†’ Validation

Each stage included:

  • Defined objectives.
  • Expected outputs.
  • Definitions of Done.
  • Ownership checkpoints.
  • Supporting templates and guidance.

Β 

Tools

To improve visibility and consistency, I also introduced:

  • JIRA workflows linked to design stages.
  • Automated status transitions.
  • Shared project tracking.
  • A centralized knowledge hub in FigJam.
  • Weekly team reviews and retrospectives.

These tools were not the goal themselves. They existed to reinforce shared behaviors and expectations.

Outcomes

Team capacity growth

The most meaningful outcome was increased designer autonomy.

Designers became more comfortable planning their own work, defining milestones, identifying when additional research was needed, and communicating progress to stakeholders.

Instead of relying on manager direction for every step, they developed a shared understanding of how projects moved from discovery through delivery.

While leadership support remained important, the team became significantly more self-sufficient and predictable.

Cross-Functional Impact

Available historical data showed a reduction in average delivery timelines from approximately 244 days to 88 days across comparable projects.

While project scope varied, the trend indicated faster decision-making, earlier alignment, and reduced rework.

Delivery Improvements

The initiative also improved collaboration across disciplines:

  • Engineers gained greater visibility into design progress.
  • Stakeholders received clearer delivery expectations.
  • Design reviews became more structured.
  • Project status became easier to communicate and track.

Engineer feedback averaged approximately 8.4/10, with common themes including improved clarity, smoother handoffs, and better collaboration.

Scalability

The framework was later expanded to additional teams and locations, providing a foundation for broader design operations practices across the organization.

Side-by-side visual of two design process stages showing structured goals, Definitions of Done, and key alignment steps. The left side focuses on the research phase, outlining research objectives, findings, and stakeholder sharing. The right side highlights the design delivery phase, including requirements for high-fidelity Figma files, accessibility standards, and multi-role reviews for sign-off.

What I Learned

This project reinforced that scaling a design team requires more than hiring additional designers.

As teams grow, knowledge, expectations, and decision-making processes must become shared rather than manager-dependent.

The most valuable outcome was not the workflow itself, but the capability it created. By giving designers a common language, clear milestones, and greater ownership of their work, the team became more confident, predictable, and effective.

The experience strengthened my belief that good design leadership is not about creating dependency on managers. It is about building systems that help teams operate successfully with increasing independence.