Why Screenshot-Driven Development Persists

A shared system has to help with the ticket in front of the team

A screenshot is easy to act on under a deadline. It shows what a screen should look like, and a developer can reproduce that appearance with familiar code. The problem is what the picture leaves open: supported states, token use, keyboard behavior, responsive rules, and the reason a particular pattern was chosen.

When those decisions are made locally across several products, a later correction can become a search for all the different implementations. A component library helps only if the team can use it in the same delivery conditions that made the screenshot attractive.

That was part of the problem I inherited with a stalled enterprise design system. The design library was partial, the written guidance was uneven, and the route from a frame to coded behavior was not dependable enough. I coordinated the design, framework, theme, Storybook, and guidance work to make that route practical.

The handoff needs to carry the decisions a picture cannot

I pulled Code Connect TSX and token JSON as part of the developer handoff. Regular reviews with framework developers, theme implementers, the dedicated Storybook developer, and product teams connected the design decisions to implementation. Written component guidelines gave requirements and quality engineers a reference they could use alongside the code.

A team should be able to find the released component, inspect its states, understand the usage and accessibility requirements, and check the result in a product screen. Each link needs maintenance. A stale example or an unexplained discrepancy gives the team another reason to fill in the gaps locally.

Migration effort belongs in release planning

Some changes come through a shared theme. Others need a check in each screen, and structural changes may need manual implementation. We separated those categories in the migration guidance so teams could plan the work.

The timing mattered. EDS 1.1 was followed by a late-July color hotfix and the August 28 EDS 1.2 release while application development was underway. Some teams were still absorbing earlier changes; others had legacy conversion work to finish. The lesson was to communicate the next EDS scope before application release planning and release it before development begins.

A deferred adoption is not automatically resistance to standards. Client contracts, bandwidth, and conversion from a Kendo-based codebase to React/MUI can determine when a team has room to do the work. The shared path has to account for those constraints.

Make the checks part of the development path

Our workspace agent instructions support starting with a PRD and assembling a page from EDS patterns. The developer reviews the generated code, runs the required EDS linter, and corrects findings before a commit or push. Code review and product QA follow. The linter checks configured rules; it does not replace contextual accessibility or behavior testing.

We also set expectations against hardcoded values and unapproved custom variants. When a product need exposes a gap, teams need a way to get a decision. Guidelines, release notes, migration guidance, and a cross-functional communication hub support that conversation.

Requirements, software, and quality engineers are incorporating these resources into their practices. We continue to refine the handoffs and checks as adoption expands. That work includes the design team too: agent-assisted assembly gives us an initial workflow to review and refine, rather than removing the need for design judgment.

Separate system reach from observed adoption

EDS supports 22 teams and more than 200 developers, requirements engineers, and quality engineers. As of October 4, 2026, 16 of those teams were using EDS 1.2. The remaining teams were constrained by application planning, contractual commitments, bandwidth, or legacy conversion work.

That adoption count does not show that every implementation is correct. Product checks still need to verify shared tokens, component states, accessibility behavior, and documented exceptions. We have not established a comparable whole-delivery cycle-time or defect result, so those are separate questions to measure.

A standard is easier to adopt when its implementation path, migration effort, and support are credible on a difficult delivery day. The EDS recovery case study shows how we made those decisions concrete.