DesignOps: what it is, and where to start
DesignOps is the work that lets designers do their work. Not one more role on the org chart: a way to organise tools, processes and people so design moves fast, stays consistent, and gets adopted by the rest of the company.
A simple definition
When a design team grows from three to thirty people, the problems change. Talent is no longer the issue, consistency is: three ways to build a button, files nobody can find, developers rebuilding what already exists. DesignOps deals with that friction.
In practice, it is the set of practices that make design repeatable: a maintained design system, review rituals, shared tooling, a clear way to contribute, and people who know all of this exists.
What DesignOps is not
- A renamed project management role. DesignOps ships things: components, documentation, tools, training.
- Just a design system. The system is often the first deliverable, but without adoption it is one more Figma library.
- A big-company thing. A team of five already needs naming conventions, a source of truth and a review ritual.
The three workstreams
- Tools and system: the design system (tokens, components, documentation), Figma file structure, the link with code, templates.
- Process: how requests come in, how a component is proposed, reviewed, released and versioned, who decides what.
- Community and adoption: onboarding, regular touchpoints, relays in every team, day-to-day support.
The third workstream is the one most often forgotten, and the one that makes the difference. On ENGIE’s design system, regular events, onboarding content and a network of relays across entities turned the system from a tool into a shared practice.
Measuring adoption
- Coverage: the share of screens or projects using system components.
- Adoption: the number of active projects, teams or entities, and its growth.
- Drift: components rebuilt by hand, hard-coded colours.
- Satisfaction: a short survey for designers and developers.
- Contributions: proposals coming from outside the core team.
Community, the underrated lever
- Relays: one person per team or entity who brings needs up and news down.
- A short, useful recurring meeting: what shipped, what is coming, a demo, an open question.
- A thirty-minute onboarding anyone can follow alone.
Where to start: a 90-day plan
- Weeks 1 to 3: listen. Interviews with designers, developers and product leads, inventory of files, components and pain points.
- Weeks 4 to 6: lay the foundations. Tokens, naming conventions, file structure, a first component end to end.
- Weeks 7 to 9: enable contribution. A written process to propose, review and release a component, and a changelog.
- Weeks 10 to 12: launch the community. First relays, first meeting, onboarding, and a first adoption measure.
Signals it is time
- The same question comes up every week in the design channel.
- Two teams ship two versions of the same component.
- Onboarding a new designer takes more than two weeks.
- Nobody knows which Figma library is the source of truth.
I do this work with teams, from startups to large companies: design system, governance, community. This site’s documented, versioned design system is a small example.