Jeremy Capps

Practice · Zocdoc · 2021–2024

Migrating the component every page shipped on, run as a product decision.

As a design-systems engineer at Zocdoc, I owned the header migration under a company-wide accessibility mandate. What made it land was product judgment, not more code: change the size of the reviewable unit, coordinate everyone who depends on it, and let evidence confirm each step. The same move as the Klarna call—three years earlier, and in code.

Role
Design Systems Engineer
Span
2021–2024
Reach
The header on every page
Codebases
4–5, independently owned
Team
3 engineers
01 · Context

A mandate turned a maintenance job into leverage.

Zocdoc was working toward a fully WCAG-compliant site. Mezzanine—the TypeScript/React design system many teams built their products on—was the mechanism: fix a component once, and every product surface consuming it inherits the fix. The header was the highest-reach instance of that leverage: present on every page, on a legacy API that had to be replaced rather than wrapped, and consumed across four to five independently owned codebases.

02 · The real constraint

The work was correct long before it could land.

Partway through, the feedback was to push more code to production. But the components were built and correct—they sat in review, in branches that drifted while product teams kept editing the codebases underneath them. The constraint was not how much I produced; it was how large and illegible each unit of work had become by the time someone had to review it.

Blocked by review, not by code. Changing the shape of the work—not the amount—is what moved it.

03 · Decision

Move with evidence and coordination.

Coordination

A page-by-page migration workflow.

Identify engineering ownership, bring stakeholders in early, and line up QA ahead of each change—so every dependent team advances together. I audited the legacy header and then read how downstream teams actually called it, because real usage is what would break.

Evidence

Prove the header through the A/B framework.

The design-system team's first frontend-component experiment: a gradual rollout, measured across browsers and mobile, with test/control analysis. A load-bearing change, released like a product rather than shipped in one cut.

04 · Result

A measured change the whole company kept shipping on.

Built onA rollout teams could trust

A measured, confident migration the dependent teams advanced on together.

+2–3Velocity points per sprint

Smaller, well-scoped tickets made the work legible and moved it faster.

1 workdayReturned to the team

A PR merge template that changed how the team shipped, not just my own tickets.

05 · Judgment

A load-bearing change is a shared, measurable commitment.

Coordinate everyone who depends on it, size the unit of change so it stays reviewable, and let the evidence confirm the change is good. That is the same instinct as the Klarna decision—name the boundary a strong headline hides, and move only as far as the evidence supports. Three years earlier, and in code.