Firms that build the operating layer around a live system — contribution models, decision rights, versioning, and adoption — so it survives the eighteen months after launch.
Most design systems don't fail during the build. They fail in the eighteen months after, when there's no process for change requests, no clear owner, no versioning discipline, and no reason for teams to adopt over building their own. The firms here fix that layer: the contribution models, decision rights, release cadence, and adoption mechanics that keep a system alive. This is operations — not strategy and not components — and it's the work that decides whether the investment lasts.
Runs the operating layer
Six firms that keep a system alive
Each builds the contribution models, decision rights, release discipline, and adoption mechanics around a live system. Ordered by depth of DesignOps practice, not scored.
A Copenhagen consultancy that treats DesignOps as its core discipline, Blixt & Dunder aligns governance, process, tooling, and culture so a system runs rather than stalls. Where most firms bolt DesignOps onto a build, here it's the headline: the operating model, contribution rules, and adoption metrics are the deliverable.
Services
DesignOps operating models, governance and decision rights, contribution workflows, tooling and automation, adoption and velocity metrics.
Notable work
DesignOps and platform work for European enterprises, including merging two Nordic mobile wallets; publishes the Design Leadership Map benchmarking design authority across 55 companies.
Ideal client
Product organizations that want DesignOps built and run as a measured, strategic capability.
Copenhagen, founded 2014 · Independent · DesignOps-ledblixtdunder.com
Governance and contribution models that make adoption happen.
Overview
Rangle treats the system as a product, and its governance work is the operating layer that keeps many teams contributing without fragmentation: contribution workflows, decision rights, and the multi-brand token discipline that holds a federated system together. Operational, not theoretical, since it runs these models on live enterprise systems.
Services
Governance models, contribution workflows, DesignOps, versioning and token discipline, adoption across teams.
Notable work
Enterprise system governance and operations for UNIQLO, Sanofi, and Staples, among other large enterprises.
Ideal client
Enterprises with multiple teams that need governance and contribution rules that actually get followed.
A named DesignOps service line for enterprise teams.
Overview
A San Francisco boutique focused on the software people use at work, Neuron runs DesignOps as an explicit service: the Figma-based workflows, tooling, and automations that keep designers and developers aligned across a live system. It bridges design, engineering, and product to remove the operational friction that stalls adoption.
Services
DesignOps, Figma workflow and automation, tooling governance, process optimization, design-development alignment.
Notable work
Enterprise UX and DesignOps work for Listrak, Vendr, and AcuityMD, systematizing complex internal tools and the operations around them.
Ideal client
Enterprises whose design workflows, tooling, and handoffs are slowing teams down.
San Francisco · Independent · Enterprise software onlyneuronux.com
A global consultancy inside Capgemini Invent, frog runs DesignOps as an organizational capability for enterprises with hundreds of designers and thousands of developers, backed by a published DesignOps framework. The operational focus suits organizations where the challenge is keeping a system governed and adopted across many business units.
Services
DesignOps frameworks, governance, cross-team operating models, tooling and process at scale, adoption.
Notable work
Large-scale DesignOps and governance programs across global enterprises, on decades of design history.
Ideal client
Very large organizations operationalizing and governing design across many teams at once.
Founded 1969, global studios · Part of Capgemini Inventfrog.co
Governance and adoption for systems that have to stick.
Overview
Josh Clark's firm is known for the harder half of systems work: not standing one up, but governing it and getting it adopted across teams. Its operational advisory centers on contribution models, decision-making structures, and the adoption strategy that determines whether a system survives its first year.
Services
Governance models, adoption strategy, contribution and ownership structures, operating-model design, systems operations consulting.
Notable work
Governance and adoption work for major organizations including Samsung, eBay, and Time.
Ideal client
Large organizations whose system exists but isn't being governed or adopted well.
Bitovi runs the governance layer around systems that live in code: contribution workflows, versioning and deprecation discipline, and the process that keeps design and engineering releasing in step. Its operational credibility comes from maintaining these systems in production, not advising from the outside.
Services
Contribution workflows, versioning and release governance, design-to-engineering process, DesignOps, documentation.
Notable work
Governance and modernization for a Fortune 500 financial-services company, plus enterprise work for Yum! and Coinbase.
Ideal client
Enterprises that need governance and release discipline around a coded system, run next to their engineers.
Distributed, US-based · Independent · Figma Service Partnerbitovi.com
Questions
Keeping a system alive
What is DesignOps, and how is it different from the design system itself?
The design system is the components and tokens. DesignOps is how design work happens around them: who decides what gets added, how teams request changes, how versions ship, how the system stays in sync with engineering. You can have excellent components and broken operations, and DesignOps is what fixes the second. It's the machinery, not the parts.
When does an organization need governance and DesignOps help?
Usually when the system already exists and the cracks are operational: change requests pile up with no process, teams build their own components rather than wait, versions break products because there's no release discipline, or nobody actually owns the thing. If you're feeling the pain after the build rather than during it, this is the category you need.
What does a governance model actually define?
Who can contribute, how a change gets proposed and reviewed, who has authority to approve or reject, how versions are released and deprecated, and what happens when a team needs something the system lacks. A good model is designed to be used, not to be correct: governance requiring three approvals and a fortnightly meeting gets bypassed within a month.
How do these firms drive adoption?
By treating it as an organizational problem, not an announcement. That means fast, easy contribution paths, quick turnaround on requests, migrating one team properly and using the result to persuade others, and measuring adoption openly. A mandate from leadership without a working contribution path reliably fails, and the firms here know it.
Is this a one-time project or an ongoing engagement?
Both models exist. Setting up a governance model and DesignOps practice is often a defined engagement of a few months, but many organizations then retain a firm or embed one to run the operations until the internal team can own it. Ongoing, retainer-based DesignOps suits systems specifically, since they need continuous small investment rather than a single build.
How is this priced?
Governance and DesignOps setup is commonly scoped as a project in the mid five figures, depending on organization size and number of teams. Embedded or retained DesignOps is priced monthly. It's usually cheaper than a full build and far cheaper than rebuilding an abandoned system in three years, which is what happens when the operational layer is skipped.
