Who owns a design system months after an agency hands it over? What happens when a new component needs approval, and nobody knows who makes the call?
The agency has moved on, but the system hasn’t. It still needs decisions, updates, documentation, and someone responsible for keeping it in use.
Isadora Agency’s published guidance treats governance as part of the system itself, with clear responsibilities and processes for keeping it useful over time.
“Governance is what keeps a design system working after the build is over.
"Without clear ownership and a process for making decisions, teams can have the right components and still end up working around the system instead of with it,” says Isadora Marlow-Morgan, President at Isadora Agency.
Design System Governance Problems
Zeroheight’s 2026 Design Systems Report shows adoption remains uneven:
- 7% say their design system is fully adopted across all teams
- 31% report wide adoption across most teams
- 38% report moderate adoption
- 22% report minimal adoption
- 1% report no adoption
- Teams with poor adoption reported that 73% cite a lack of company mandate and 55% cite weak governance
“A design system needs clear ownership from the start,” Marlow-Morgan says.
“Teams need to know who can approve changes, how requests are handled, and where the latest guidance lives. Without that structure, teams start making their own decisions.”
The agency recommends defining roles, responsibilities, and processes for maintaining the system, alongside regular communication and a structured process for updates.
Zeroheight found that 83% of organizations now have a dedicated design system team, up from 78%in 2025.
Yet 61% of teams said they didn’t have enough people to meet their goals, according to zeroheight’s 2026 Design Systems Report.
The day-to-day workload reflects that. Thirty-five percent of practitioners identify prioritizing updates and changes as a maintenance challenge.
Another 27% cite managing contributions from different teams, while 31% struggle to maintain consistency across teams.
Then a new component request lands.
Someone has to decide whether it belongs in the system, whether an existing component can do the job, who should approve the change, and how everyone else finds out about it.
For companies with limited internal capacity, handing over a design system doesn't have to mean ending the agency relationship.
Continued agency support can give internal teams additional capacity for updates, documentation, development, or governance as the system evolves.
What Happens After a Design System Handoff?
Isadora Agency’s work for Kelley Blue Book shows how ownership can be built into the design system process before handoff.
The agency developed the system end to end, including page templates, a component library, and detailed guidelines and rules for ongoing use.
The internal team was trained on the system, while Isadora Agency supported the KBB dev team through implementation to help ensure it could be maintained after handoff.
Autotrader presented a different model.
The agency served as a technical design and development partner, building a foundational multi-brand design system within the existing platform.
The framework and documentation were created as a starting point that Autotrader's internal team could continue to build from with scale for production use across Autotrader’s brands.
In both models, the question of who would own the system next shaped what needed to be delivered.
These two projects show how the transition model can be planned around the team that will own the system afterward.
Training, documentation, implementation support and continued agency involvement can be built into the project according to that model.
A successful agency-to-client transition is possible, but the transition must be designed as deliberately as the design system itself.
Marlow-Morgan says successful handoff depends on preparing the organization to inherit the system.
“The real test comes after the project ends. If the internal team can’t maintain the rules, make decisions, and keep people aligned, even a strong system will lose relevance.”
That aligns closely with the 2026 research.
Fifty-five percent of respondents with poorly adopted systems cite weak governance, and 56% of all respondents identify staffing and resources as a maintenance challenge.
Isadora Agency’s guidance puts some specific requirements around that ongoing work. A design system needs:
- Clear roles and responsibilities for decisions and updates
- Regular team discussions to review what needs to change
- A structured update process tied to the product roadmap
- Current documentation that stays aligned with the system
- Changes applied to live products, so the system and the applications using it don't drift apart
- Shared ownership across disciplines, rather than treating the system as something one team polices
Marlow-Morgan also recommends treating the design system as a product rather than a project with a fixed end date.
A design system isn't a deliverable you hand over and call finished. It's infrastructure. If no one owns its evolution, it starts becoming outdated the day it launches.
The numbers don't establish that agency handoffs cause design system failure.
They show that adoption, governance and resourcing remain significant problems once the system is in use.
That changes the way the handoff should be viewed.
Delivery is one milestone.
The harder job is giving the organization enough ownership, capacity, and decision-making structure to keep the system useful when the original team is no longer in the room.
The launch gets the announcement. Year two gets the real test.
