Redesigning How Designers Ship at Scale

Meta · AI Vibe Coding

Hundreds of documented UX/UI issues sat unresolved across Meta's advertising platforms, not because designers lacked solutions, but because the delivery path required engineering bandwidth that was never available. I identified this as a systemic problem, validated a new approach myself, and led a cross-org Fixathon that shipped 83 production fixes in one week.

The Systemic Problem

A delivery model that structurally couldn't clear its own backlog.

Meta's advertising platforms — Ads Manager, Meta Business Suite, and Lightweight Ads — had accumulated 83 documented usability issues across 3 platforms serving $16B+ in advertiser surfaces. Inconsistent spacing, wrong component variants, unclear copy, misaligned elements. Every single one had a known design solution.

The bottleneck wasn't design judgment. It was the delivery model itself.

This wasn't a one-time failure, it was the predictable output of a model where engineering is both the implementer and the bottleneck for an entire category of low-complexity work. The model needed to change, not the backlog management.

The Design Insight

The backlog wasn't a design problem, it was a routing problem.

When I analyzed the historical fix backlog, a structural pattern emerged: nearly three-quarters of unresolved issues fell into two repeatable categories with well-defined design answers. The correct fix was already known. The problem was that every issue, regardless of complexity, was routed through the same engineering-dependent pipeline.

These weren't design problems requiring creative exploration. They were execution gaps, cases where the implementation diverged from a known standard. The design decision was already made. The only remaining work was precise specification and implementation.

That's exactly where AI coding tools can intervene, but only if the specification is precise enough. Precision is a design skill. It requires knowing the component tree, the correct token values, the interaction model, and the edge cases. A designer without that knowledge produces vague prompts and broken output. A designer with it produces fixes in minutes.

My Role

From hypothesis to org-level practice, in three phases.

This initiative wasn't assigned. I identified the opportunity, tested the approach solo to build credibility, then secured leadership support to scale it. The Fixathon was the output of that arc, not the starting point.

The Framework

A complexity taxonomy that made design judgment transferable.

The core challenge of scaling this approach was that not all issues are equally safe or straightforward to fix. I developed a four-tier taxonomy that gave every designer a shared mental model for assessing issues, and knowing when to proceed, when to ask, and when to escalate.

The taxonomy also determined who handled what, Tier 1-3 issues went to all Fixathon participants. Tier 4 issues I handled personally, their complexity required deep product system knowledge that couldn't be transferred quickly enough for the Fixathon format. This was a deliberate risk-control decision that protected both design quality and engineering trust.

Tier 4 issues required knowing which component owns a behavior, how state propagates across the surface, and why previous engineering attempts failed. That judgment can't be transferred without deep product context. Keeping Tier 4 outside the Fixathon boundary was a deliberate risk-control decision, it protected both design quality and engineering trust.

The Execution Model

Designer judgement first. AI as the implementation layer.

The model I designed positioned AI at step 3, not step 1. Every fix starts with a designer's assessment of the problem and ends with engineering review of the output. AI handles the translation from specification to code, not the decisions on either side of it.

Fixathon Infrastructure

What I built to make 20+ designers independently effective.

Running a cross-org Fixathon at this scale required more than a kickoff meeting. I created the infrastructure that let designers to operate with confidence and consistency, without needing me to unblock every decision.

Leading by Example

I took the most complex issue to ensure that the model held at full complexity.

Example #1:Critical action buttons cut off by expanding Meta AI panel.

TIER 4 · COMPLEX Unresolved in 6+ months ~8% of advertisers impacted

At 1280px viewport width, the Meta AI panel expansion pushed the Campaign Table's primary action buttons off-screen, making core advertiser actions inaccessible to ~8% of users.

Why this issue was strategically important to take on.

This issue had been open for over six months. The team had identified it early, but two specific factors kept it unresolved: the fix lived inside the Campaign Table, one of the most complex surfaces in the product, and previous engineering attempts had introduced additional bugs, causing the fix to be abandoned after two weeks of investigation. As engineers prioritized higher-impact roadmap items, it was repeatedly deprioritized.

I chose this issue deliberately. If I could ship it, it would demonstrate that the model worked not just for simple padding fixes, but for long-standing layout problems that engineering had already attempted and failed on. That proof of concept was essential to securing org-level buy-in.

The design judgment behind the fix.

The fix required identifying that unnecessary space in the layout was consuming horizontal width that should be available to the action button row. Previous engineering attempts had failed because they addressed the symptom (button visibility) rather than the cause (space allocation). My diagnosis pointed to a specific component, and the prompt reflected that precision.

Leading by Example

I took the most complex issue to ensure that the model held at full complexity.

Example #2: Sidebar disappearing at specific browser widths

TIER 4 · COMPLEX Unresolved in 2 weeks Engineering investigated, no conclusion

The navigation sidebar on Ads Manager Campaign Table became hidden at certain viewport widths, an intermittent layout failure that engineering spent three weeks investigating without resolution.

Why engineering couldn't close it.

The Campaign Table's component dependencies were too complex to confidently isolate the root cause. Two weeks of investigation ended without a fix or a clear path forward. Attempts to fix the sidebar directly were treating the symptom.

Not because of any technical advantage, but because I could isolate the correct system-level failure point faster. The component hierarchy on the Campaign Table is a design artifact as much as an engineering one.

My Perspective

AI vibe coding tools don't make design judgment easier. They make execution faster, but only when the designer already knows precisely what the correct state should be.

"Make it bigger" produces broken output. "Change the padding-top from 8px to 16px using the spacing token on component X" produces a shippable fix. The difference isn't AI skill, it's design knowledge. Which means the designers who can use these tools effectively are exactly the designers who understood the system deeply in the first place. Vibe coding doesn't lower the bar for design expertise. It raises the return on it.

Result

83 fixes. One week. A new delivery model for the org.

What changed, and what comes next?

The Fixathon established a new norm in the Monetization org: designers can own the full delivery loop for a defined category of work. That shift is now being formalized, this model is on the H2 2026 roadmap to become part of designers' daily workflow across the org.

But beyond the org, the broader implication is about what design expertise looks like in an AI-native environment. The designers who will have the most leverage going forward aren't the ones who write the best prompts. They're the ones who understand the product system well enough to specify problems with surgical precision, and who have the judgment to know which problems are worth solving, which are too risky to touch, and which will unblock ten other things once fixed.

That judgment doesn't come from the tool. It's built over years of doing the design work. What AI does is finally give that judgment a direct path to production, without waiting in a queue that never clears.

-- THE END --