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.
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.
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.
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.