Making design delivery predictable at Ring

“When will the design be ready?”

When I joined Ring’s Kyiv office in 2019, I was responsible for improving delivery for a team of nine Product Designers and one Design Manager. The team operated as an internal agency, with work passing through multiple reviews before reaching engineering.

The problem seemed simple: design delivery was unpredictable. The obvious response was better estimates, deadlines, or project management. But first, I wanted to understand whether delivery time was actually the problem.

Delivery time was a symptom, not the problem

I started with an audit, interviewing stakeholders and mapping interactions, handoffs, and friction points. The resulting service blueprint changed how I understood the problem.

There was no single process to optimize: work wasn’t consistently scoped, teams operated in silos, research was disconnected from design, and engineering builds could diverge from the intended experience. Most importantly, we lacked the operational data to understand where time was going.

I couldn’t make delivery predictable until we could see the system producing it.

I couldn’t fix everything at once

The audit exposed problems at several levels of the organization. Some were within my influence. Others, including broader issues around User Research, required organizational changes beyond the scope of my role at the time.

Rather than attempting a large transformation at once, I prioritized problems we had the authority to change and could learn from quickly. The first objective, therefore, wasn’t to make designers work faster but to make work visible enough to understand where time was going.

The goal wasn't the process, but measurement 

Working with the team, I introduced enough structure to create a consistent workflow: a shared backlog, common definitions of ready and done, regular planning and retrospectives, estimation, and visibility into work in progress.  

It gave us something we didn’t have before: a system we could observe and measure. And almost immediately, the data challenged our original assumptions.

Design work was spending more time waiting than moving

One month after formalizing the workflow, we found that some design flows could spend up to five working days in reviews for every hour of hands-on design work.

The review process had accumulated several approval steps, but their purpose and ownership weren’t always clear. Some reviews were effectively based on individual opinions rather than explicit criteria. 

This changed the problem again. The issue wasn’t simply estimation; the system itself was creating wait time.

We redesigned reviews around decisions

Instead of removing reviews, we clarified their purpose: peer review shared context, design review ensured consistency, UX testing validated solutions, and Design System review limited design and technical debt.

More importantly, design work became measurable. We could establish benchmarks, distinguish quick fixes from larger problems, and identify bottlenecks.

Measurement also showed that our first intervention wasn’t enough. Estimates remained unreliable and design–engineering inconsistencies persisted. Fixing one constraint exposed the next.

The next constraint was the team structure

Designers still operated too far from the teams building the products. The next intervention had to change the organizational relationship, not just the workflow.  We moved from an internal-agency model to embedding designers in eight cross-functional squads alongside Product Managers and Software Development Managers. 

Instead of receiving work and handing designs back, designers could build a deeper understanding of the product area and participate directly in product and engineering discussions.

We also introduced Design QA: designers, Product Managers, and Software Development Managers reviewed builds before release to help ensure customers received the designed experience. Responsibility for the experience became more shared across functions.

The next bottleneck was UX content capacity

As the design organization evolved, another bottleneck emerged. Eight Product Designers across seven tracks depended on a single UX Writer. Because the workflow was now measurable, we could quantify the impact rather than relying on complaints.

UX copy was adding an average of 21 days to the pipeline. 

I first looked for ways to use the resources we already had. The problem wasn’t individual performance, but a capacity imbalance within the system.

We made UX-content demand visible and created a style guide that enabled more people to produce appropriate UX copy. With evidence of the remaining constraint, I then supported the case for additional headcount and helped establish a dedicated UX Content team. 

The UX copy step eventually dropped from approximately 21 days to 10.8 days. The overall design pipeline also moved from about 43 to 36 working days.

Every solved bottleneck exposed another

By this point, a pattern had emerged.

• Unpredictable delivery → map the workflow

• Invisible work → make it measurable

• Review delays → redesign reviews around evidence

• Design–engineering gaps → embed designers and introduce Design QA

• UX content bottleneck → rebalance capacity and create shared standards

But the system didn’t end at design handoff. The next problems existed further upstream and across organizational boundaries.

The problem was larger than one team

What began as an intervention within one design team increasingly became an organizational problem. We extended the practices developed with the Kyiv team across additional Design Chapters. We introduced common processes and weekly Design Sprint and Design Program reporting to make progress and resource constraints visible across the organization.  

This also allowed us to examine another systemic question: Did we have the right distribution of design resources to support the product organization? Instead of treating headcount as an isolated staffing decision, we started looking at resource proportions and emerging bottlenecks across teams.

Content revealed the same systemic pattern

Another problem crossed even more organizational boundaries. Four teams were producing customer-facing content for the app, website, Help Center, and packaging. Each went through legal review independently, which could produce inconsistent revisions and late changes. Those inconsistencies could create additional design and engineering work and increase Customer Support demand. 

Again, the visible symptom was rework. But the leverage point was upstream. I helped facilitate collaboration between content, marketing, customer support, legal, and product stakeholders and helped create an Internal Product Guide to align product and communication decisions before teams started producing content.  

The resulting Content Guild reduced ad-hoc content rework by 23% compared with the previous year, while UX copy delivery improved substantially. 

The final constraint was upstream: product planning

Even after improving the delivery system, design still wasn’t fully connected to product planning. If design capacity and dependencies were considered only after product commitments had been made, delivery would always remain partly reactive. Working with design leadership, I helped create the environment for Design Managers to model timelines and resource needs before commitments were finalized. 

The result was a structural change: Design efforts and headcount became part of Ring’s OP1 and OP2 planning for 2022. What started as “Why can’t we predict when design will be ready?” eventually became “How should design participate in the system that decides what gets built?”

Impact: from an invisible workflow to an integrated system

Across the two-year transformation:

• 43 → 36 working days — average design pipeline time decreased by 16%.

• 21 → ~10 days — average UX copy cycle time decreased by approximately 48%.

• –23% ad-hoc rework — earlier alignment through the Content Guild reduced unnecessary content changes.

• Design entered product planning. Design efforts and headcount became part of Ring’s OP1 and OP2 roadmaps.

• Design QA became part of delivery. Designers shared responsibility with Product and Engineering for ensuring customers received the intended experience.

• Decisions became more measurable. Operational visibility allowed teams to identify constraints using data rather than assumptions.

What I learned: Predictability is a system property

I joined Ring to improve design delivery, but I had never led this kind of organizational transformation before. Things clicked when I stopped treating it as a project-management problem and approached it as a Product Designer: understand the system, identify a constraint, intervene, measure, and learn.

I realized that delivery time was a property of the system around it—from intake and reviews to team structure, resources, and product planning. No single process change could fix it. 

The approach became iterative: make the system visible → identify a constraint → intervene → measure → learn → repeat. The outcome was a shift from a siloed internal agency toward a measurable part of the product-development system.