DesignOps
A design system only works when someone manages it
A design system nobody manages falls apart within a year: components get duplicated, documentation goes stale, teams work around it. DesignOps is the process, tooling and training that keep the system used, up to date and owned by someone.
Written by Radosław Kołacki Updated
Trusted by
When is DesignOps worth it?
The company has a design system, built by Squares or in-house, but components exist in several versions across teams.
Documentation cannot keep up with changes and nobody knows who is allowed to change the system. New team members do not use it.
The investment in the system, for which the Head of Product answers to the management board, becomes harder and harder to defend.
Who is DesignOps for?
- The design system is in place in Figma and in code (e.g. Storybook), but nobody is responsible for it
- The number of projects and people using the same system keeps growing
- After a redesign, the Head of Product or design lead wants to keep the product consistent
How it works
How does DesignOps work step by step?
01
System health audit
We check how many teams actually use the system, where components have diverged and what needs fixing.
02
Change rules
We agree who may change the system, how versions are numbered and how changes are described.
03
Tooling
We tidy up or introduce Storybook (a catalogue of components in code), automated transfer of tokens, the named values for colours and spacing, from Figma to code, and consistency checks.
04
Team training
We teach designers and developers how to use the system and how to extend it.
05
Regular reviews
Every month or quarter we check the state of the system and compare the result with the previous review.
06
Usage analytics
We measure which components and tokens are actually used, and where teams bypass the system.
The design system is used and up to date across the organisation, with a clear change process and a regular review backed by numbers.
How much does DesignOps cost?
from PLN 2,500 net/month
Ongoing care costs from PLN 2,500 net per month. We start with a system health audit, priced according to the scale of the system. Ongoing care is billed monthly, with the fee sized to the team and how often things change.
The first step after the call is a system health audit. The company decides on ongoing care only afterwards, with the result in hand. A reply arrives within a few hours.
„I have been working with Squares for a long time and can recommend them with a clear conscience to anyone looking for reliable developers. We have delivered several websites together. The whole process went very smoothly.”
Dominika Cisowska
Google review, translated from Polish · Full review
Work
How it works in practice
NoHo Group: one system maintained for four brands
Changes to the design system reach all four sites at once. This was building a system, not an ongoing review, but it shows why a single source is worth guarding.
Case study
pompy.app: components described once
We described colours, typography and components once, so that extending the site would not pull its look apart. DesignOps guards the same thing after launch.
Case study
Training sales platform: rules for new elements
A set of rules and components makes it possible to add new interface elements without losing consistency. It was created in a delivery project, not as part of the DesignOps service.
Case study
Why Squares
We build design systems from scratch, so we know which design decisions drift in practice. We prevent that with process, not with another redesign a year later.
Questions
Frequently asked questions
What is DesignOps?
DesignOps is the process, tooling and training that keep a design system used, current and owned. It covers rules for changes, version numbering, documentation and regular reviews of the system's health. Without it a system drifts apart within a year: components get duplicated, documentation goes stale and teams work around it.
How is DesignOps different from the Design system service?
Design system is a one-off project: designing and implementing components and rules. DesignOps is ongoing maintenance of a system that already exists: the change process, tooling, training and adoption across teams. The first service ends with a finished system; the second makes sure it is still in use a year later.
When does a company need DesignOps?
DesignOps is needed when a design system exists in Figma and in code but nobody is responsible for it. The symptoms: the same components in several versions across teams, documentation that lags behind changes, no clarity on who may change the system, and new joiners who do not use it.
How much does DesignOps cost?
The system health audit is priced according to the scale of the system. Ongoing care is billed monthly, and the fee depends on team size and how often things change. We give an initial estimate after the first call. The company decides on ongoing care only after the audit, with the result in hand.
What does DesignOps include?
The service includes a system health audit, rules for changes and version numbering, tidying up or introducing Storybook and automated token transfer from Figma to code, training for designers and developers, regular reviews and component usage analytics. The result is a system that is used across the organisation, with a clear change process and a regular review backed by numbers.
How to measure the health of a design system?
We rate the health of a design system in numbers: at each review we go through the Figma file and score the system from 0 to 100 in five areas. These are colours and tokens, spacing and layout, typography, components, and naming and documentation. The score is compared with the previous review, so it is clear whether the system is getting tidier or drifting.
Does DesignOps cover a design system built by another supplier?
Yes. The work starts with a system health audit, regardless of who built the system: Squares, an in-house team or another supplier. The audit shows how many teams really use the system, where components have diverged and what needs repair. After it, it is clear what stays and what needs tidying up.
Does DesignOps include team training?
Yes. Training designers and developers to use the system and extend it is part of the scope and does not need to be ordered separately. Without training, new joiners do not use the system. In the plan of work it follows the change rules and the tooling clean-up.
How often are design system reviews held?
Reviews are held monthly or quarterly. A review needs access to the system file in Figma and to the component catalogue in code, for example in Storybook. Each review points out deviations from the system, most urgent first, and measures which components and tokens are really used.
Are there case studies for DesignOps yet?
DesignOps as a separate service is new and does not have its own case study yet. It builds on design systems we created: a single system for four NoHo Group brands and the design system of the pompy.app site, described once so that extending it would not pull its look apart. That is how we know which design decisions drift apart in practice.