Improving Predictability within Design Teams

Using Design Metrics to Uncover Interrupt Work

Digging into our planning and management tools, I analyzed a year’s worth of design data to get a clearer picture of our output. If there were concerns about delivery speed, the data would reveal the truth. At first glance, everything seemed on track—quarter after quarter, the design team was meeting expectations.

So why did it feel like design was missing the mark?

To find out, I looked deeper. By running additional queries, a pattern started to emerge: many of the Stories being delivered weren’t planned at the beginning of the Sprint. In fact, about 30% of completed Stories had been created during the Sprint itself. This insight had been overlooked in previous analyses, which focused only on total output.

A new theme became clear: interrupt work.

Unplanned requests were often sent directly to individual designers instead of going through a Design Lead. Because of this, these requests were prioritized over planned work, creating a ripple effect that delayed critical commitments.

Key Insight #1: Only 49% of Planned Work Was Delivered.

How might we understand the root causes of interrupt work in the design process and create workflows that enable product and design teams to adapt while still delivering on planned work?

With a clearer understanding of the problem, I began mapping where the process was breaking down. Too often, small requests from product teams were bypassing our established ways of working, landing directly on designers’ plates. This put undue pressure on individual contributors to say yes, leading to a cycle of delays.

At its core, the solution was simple: prevent work from bypassing the prioritization process. Not only was this unplanned work delaying major milestones, but it was also undermining the team’s established workflows.

Refining the Process

To move forward, I met with Design Leads and Managers to assess the current state. Was our process failing, or was there simply a lack of cross-team education? After gathering insights, we refined our ways of working and aligned with the product team on a new approach:

Our Improved Ways of Working:

1. All unplanned work must be reviewed by a Design Lead. If a designer receives a direct request, they should either escalate it or ask the product partner to go through the Design Lead.

2. Clearly label interrupt work. Any new Story added to the backlog during a Sprint must include the prefix [Interrupt] in the title, making it easy to track.

3. Trade-offs are required. If an interrupt Story is introduced, an equivalent number of Story Points must be removed from the Sprint. For example, if an unplanned request is estimated at 2 points, at least 2 points of existing work must be deprioritized to maintain delivery expectations.

By making these adjustments, we created a more balanced workflow—one that allowed for flexibility while protecting our ability to deliver on commitments. This shift not only improved efficiency but also reinforced the importance of structured prioritization across teams.

Building a Better QA Process to Reduce Design Debt

One of the biggest challenges we faced was the Design QA process. When product teams moved designs from Figma into production, there was a gap in expectations around design verification. Without a clear process in place, design often wasn’t reviewing implementation until after work had gone live—leading to urgent fixes that disrupted future Sprints.

Reducing these unexpected QA-related tasks became a top priority.

Key Insight #2: A broken Design QA process was generating excessive unplanned work.

How might we improve the Design QA process to ensure alignment between design and product teams, reducing unexpected work and preventing future sprint disruptions?

Refining the Design QA Process

To address this, we focused on streamlining communication, improving documentation, and integrating QA into the design and development workflow.

Our Improved Design QA Process:

1. Establish a single source of truth. We consolidated four different QA artifacts into one unified document, ensuring clarity on expectations.

2. Introduce a Design Buddy system. Developers are paired with a designated design buddy during testing, giving them a direct point of contact for any design-related questions.

3. Plan for QA within the Sprint. Product teams now communicate expected completion dates for Stories, allowing designers to create dedicated QA Stories within the same Sprint—making the process proactive rather than reactive.

4. Make QA accessible. Testing environment links are now included within Design QA Stories, ensuring designers can easily access and review work before it goes live.

By embedding QA earlier in the development cycle and improving collaboration between design and product, we reduced last-minute fire drills, improved design fidelity in production, and freed up designers to focus on planned work rather than reactive fixes.