Design
Design Systems: When They Pay Off and When They Are an Expensive Toy
Most teams asking for a design system need a component library and naming discipline instead. Where the line sits, how to calculate the payback before you start, and what actually belongs in a minimum viable version.
In short
A design system pays off with two or more products, three or more designers and front end developers, and releases more often than every two weeks. Below that line a UI kit plus naming discipline is enough. A minimum viable version, meaning tokens, 12 to 15 components and states, costs 150 to 250 hours and breaks even in four to six months for a team of ten to twelve.
UI kit, component library and design system are three different things
Nine out of ten requests for a design system turn out to be a different problem once you unpack them. The phrase usually hides one of three things: designers redraw the same button every time, front end developers build identical blocks in different ways, or nobody can agree on what a secondary button even is. Those are three problems with three very different price tags, and only the last one genuinely needs a system.
A UI kit is a set of reusable pieces in Figma: components with variants, text and colour styles, a grid. It solves the "stop redrawing" problem and takes 40 to 80 hours. A component library is the same set in code: typed components the front end imports instead of copy-pasting markup. It solves the "identical in production" problem and costs 80 to 200 hours depending on scope. A design system is the kit plus the library plus usage rules, documentation, versioning, a contribution process and a named owner for all of it.
The difference is budgetary, not semantic. A kit and a library are artefacts: you build them, you file them, you use them. A design system is a product with a backlog, releases, users (your own team) and a permanent cost of ownership. It never finishes. The moment maintenance stops, the system drifts away from the real interface within two or three quarters and becomes attractive documentation that nobody trusts.
So the first question before you start is not "which components do we need" but "how is the pain phrased". If it sounds like "layouts take too long", you need a UI kit. If it is "production looks inconsistent", you need a component library. If it is "launching a second product takes a quarter and half of that goes on reinventing the interface", now you are genuinely talking about a system.
- UI kit: components and styles in Figma. 40 to 80 hours, almost no maintenance.
- Component library: the same set in code with typed props. 80 to 200 hours.
- Design system: kit plus library plus rules, docs, versions and an owner. From 150 hours for v1 plus a permanent running cost.
- Naming discipline costs zero hours and removes half the arguments. Start there.
The three real layers, and what mature teams add on top
The first layer is visual: tokens and components in Figma. Semantic colour variables, a type scale, a spacing scale, radii, shadows, and a component set with variants and auto layout. The important word is semantic. A token named surface-elevated survives a rebrand, a token named grey-100 has to be renamed across every file the moment the palette shifts. It is the one first-layer decision that is genuinely expensive to undo.
The second layer is the code library: components in the project framework, with documented props, keyboard handling, focus management, loading and error states. This is where a system first starts saving money. As long as a component exists only in Figma, the developer still writes markup from scratch and makes a dozen micro-decisions the layout never covered. Layer two removes exactly those micro-decisions, which is why systems that stop at layer one never pay for themselves.
The third layer is guidelines: when to use a component and when not to, how to phrase button and error copy, which contrast and accessibility rules are mandatory, how empty states behave. This layer gets skipped most often because it does not look like a deliverable. Yet it answers the question every new designer hits in week one: "we have three notification styles, which one do I use?" Without an answer, they add a fourth.
Mature systems add two blocks on top: UX patterns and documentation with counterexamples. A pattern is not a component but a scenario: how a validated form behaves, what destructive confirmation looks like, how a multi-step flow is structured, what happens when the network drops. Counterexamples matter more than examples. A short "do not do this, and here is why" saves a team more time than another screenshot of the correct version.
The threshold test: do you need a design system right now
Below is the short scoring exercise we run in the first meeting. It is not science, but it removes the main risk: building a system for a two-person team and one product, where it will cost more than it saves. Run through the seven criteria, add up the points, then read the verdict under the table.
The reading is simple. Zero to four points: you do not need a system, you need a UI kit and a two-page document with layer and component naming rules. Five to eight: build tokens and a code component library, but do not set up a separate process, documentation site and owner yet, that is premature. Nine and above: build the minimum system described below, and budget for maintenance from day one or it dies within two quarters.
The argument-frequency criterion deserves a note of its own. If every design review turns into a discussion about spacing, shades of grey and caption font size, that is not taste, it is a tax. Fifteen minutes of debate per review, two reviews a week, five people in the room, is over 100 hours a year spent re-deciding something you could decide once and write down.
| Criterion | 0 points | 1 point | 2 points |
|---|---|---|---|
| Number of products or surfaces | One site or app | Two products | Three or more |
| Designers on the team | One | Two | Three or more |
| Front end developers | One or two | Three or four | Five or more |
| Release cadence | Less than monthly | Every two to four weeks | More than weekly |
| Arguments about spacing and shades | Almost never happen | About once a sprint | At every review |
| Product lifespan horizon | Under a year | One to two years | Three years or more |
| Who will maintain it | Nobody is assigned | Part of a designer time | A dedicated role or pair |
The ROI math: hours, rate and the break-even point
The payback formula is primitive, which is precisely why almost nobody runs it: savings per sprint equals hours saved per person times headcount times the internal cost of an hour. In practice a designer working with ready components and tokens saves four to six hours per two-week sprint, and a front end developer saves six to ten, because what disappears is not only markup but also the discussion of states, spacing and breakpoint behaviour.
Take a typical team: four designers and eight front end developers. Savings per sprint come to roughly four times five plus eight times eight, which is 84 hours. At an internal hourly cost of 2,000 to 3,500 RUB, the band most Russian product teams fall into, that is 170,000 to 290,000 RUB per sprint, or roughly 340,000 to 590,000 RUB a month. Building v1 at that scale costs 250 to 350 hours, with 20 to 30 hours a month of maintenance.
An honest calculation has to include three things that usually fall out. First, for the first two sprints after rollout the team is slower, not faster: people hunt for components, argue with constraints and fill in gaps. Budget a 20 to 30 percent velocity hit for a month. Second, migrating existing screens. Either you do it gradually or you never do it, and then the product runs two interfaces at once. Third, onboarding and docs. Without them the per-person saving halves, because finding a component takes longer than writing your own.
The table below shows three team configurations and what happens to each. Look at the first row: with five people the system takes nearly a year to break even, and within that year the team, the product and the requirements all change. That is why we usually propose tokens plus a component library for small teams and actively advise against a documentation portal and a contribution process.
| Parameter | Team of 5 | Team of 12 | Team of 25 |
|---|---|---|---|
| Hours saved per sprint | 20-30 | 70-95 | 150-200 |
| Cost of v1, hours | 150-200 | 250-350 | 400-600 |
| Maintenance, hours per month | 8-12 | 20-30 | 40-70 |
| Velocity dip during rollout | 1 sprint | 2 sprints | 2-3 sprints |
| Break-even point | 9-12 months | 4-6 months | 3-4 months |
| Recommendation | UI kit and tokens, no process | Minimum system with an owner | Full system, dedicated budget |
The minimum viable design system: what goes in v1 and what does not
Tokens come first, and they are defined by role, not by value. Colour: surfaces (background, elevated, overlay), content (primary, secondary, muted, inverted), accent plus its states, a four-status semantic set (success, warning, error, info), and borders. Typography: five to seven styles, not twenty. Spacing: a 4 or 8 pixel scale with at most eight steps. Radii: three. Shadows: three levels. Plus a z-index layer map fixed once, so a modal never again ends up underneath a dropdown.
Next come 12 to 15 components that cover about 80 percent of any product interface: button, text input, textarea, select, checkbox and radio, switch, modal, tooltip, toast or notification, card, table, tabs, pagination, avatar, badge. Anything outside that list, such as a scheduling calendar, a tree view, an editor or complex charts, is built for the specific case and enters the system only when it is needed a second time.
States carry half the value of a system and are the part most often skipped. Every interactive component needs default, hover, keyboard focus (a genuinely visible focus ring, not a removed outline), pressed, disabled, loading and error. Every container needs an empty state, a loading state and a load-failure state. A component without documented states saves the designer ten minutes and costs the developer half a day working out what to show while data loads.
What must not be in v1: a dark theme unless it is a hard requirement today; a hand-drawn icon set, since an open set plus a few custom glyphs is faster and better; multi-brand theming; a heavy animation library; a documentation portal with search and versioning. All of that belongs to round two, once the system has proved people actually use it. A v1 at this scope takes 150 to 250 hours. Veltos.Tech prices UX/UI work from 60,000 RUB, and a minimum system typically comes together in four to six weeks alongside ongoing product work.
- Name tokens by role, not by value: surface-elevated survives a rebrand, grey-100 does not.
- 12 to 15 components cover about 80 percent of the interface. The rest waits for a second request.
- Seven states per interactive component and three per container is not perfectionism, it is days of saved development.
- Dark theme, custom icons and a documentation portal belong to iteration two.
Design and code sync: the part that kills systems
A design system usually dies like this: Figma is immaculate, the code is three months behind, the designer works from new tokens, the developer builds from old ones, and the product looks like two products. Six months later nobody opens the library because "it is out of date anyway". The problem is not people or discipline, it is the absence of a mechanical link between two sources of truth.
The setup that works looks like this. Figma variables export to JSON, the JSON runs through a token transformation tool into CSS custom properties, TypeScript constants and, if needed, mobile platform formats. The build runs in CI, not by a designer manually on a Friday evening. From then on a colour change in Figma reaches production as one pull request instead of an email asking somebody to please adjust a shade. Setting up that pipeline costs 20 to 40 hours, and they are the best 40 hours in the project.
Component behaviour lives in Storybook, and that is the single source of truth for interaction. A layout shows how something looks; Storybook shows how it works: every state, every prop combination, keyboard behaviour, edge cases with long text and empty data. A design review run against Storybook rather than static images finds noticeably more discrepancies, simply because you cannot click through a picture.
Versioning and ownership are the last piece. The system is versioned like any library: semantic versions, a changelog, deprecation over one or two releases rather than instant removal. The owner has to be a named person whose time sits in the sprint as normal work, not as "they will get to it when free". Three funding models work: 10 to 15 percent of one designer and one front end developer; a small dedicated team once you pass 25 developers; a federated model where product teams contribute and the owner reviews. Exactly one model never works, and that is "in spare time".
- Figma variables to JSON to CSS and TS through a CI build. Manual sync never survives a quarter.
- Storybook is the source of truth for behaviour. Review against Storybook, not screenshots.
- Semantic versions, a changelog and a deprecation window instead of silently deleting a component.
- A named owner with sprint time. "In spare time" is a plan for shutting the system down.
Adoption: why teams ignore the system and what fixes it
The reasons are almost always the same, and none of them is laziness. First, the system does not cover a real case and there is no fast way to add what is missing. A designer hits a missing variant once, builds their own component, and from that moment the product has two sets. Second, finding a component takes longer than rebuilding it, thanks to poor navigation, vague names and no search. Third, nobody knows when to use what, because the guidelines were never written.
The fourth reason is the most destructive: contributing takes a week of approvals. If adding a button variant requires a committee, two reviews and a release cycle, the team stops proposing changes and starts routing around the system. The working norm is one to two business days to accept or reject a proposal, with trivial additions like a new size or icon going through with no discussion at all.
What actually fixes adoption. A coverage metric: the share of production screens and components built from the system, measured monthly and discussed. A support channel with a response time, because a component question should not sit unanswered for three days. An explicitly permitted deviation: teams may do it their own way as long as they log it, and after two such cases the component enters the system backlog. A 30 to 40 minute onboarding for every new joiner. And a linter or automated check that catches hardcoded colours and spacing in pull requests.
Last and probably most important: the system has to feel like a service, not a regulation. A regulation forbids and penalises; a service removes work. A practical test of how the team really feels: ask a designer and a front end developer separately whether the system speeds them up or slows them down. If either says it slows them down, you do not have a discipline problem, you have a product problem, and the thing to fix is the system, not the people.
Frequently asked questions
How is a design system different from a UI kit?
A UI kit is a set of components and styles in Figma, an artefact you build once and file away. A design system is that kit plus the same components in code, plus usage rules, documentation, versioning, a contribution process and a named owner. A kit costs 40 to 80 hours and needs almost no upkeep. A system costs from 150 hours for the first version and carries a running cost of 8 to 70 hours a month. Stop maintaining it and it drifts away from the product within two or three quarters.
How much does it cost to build a design system?
A minimum working version, meaning tokens, 12 to 15 components, states and basic documentation, takes 150 to 250 hours. For a team of twenty or more with several products, the first version runs 400 to 600 hours. On top of that comes maintenance: 8 to 12 hours a month for a small team, 40 to 70 for a large one. Veltos.Tech prices UX/UI work from 60,000 RUB, and a minimum set of tokens and core components usually comes together in four to six weeks alongside product work.
Does a single site or landing page need a design system?
No. For one product with one designer a system will not pay for itself: break-even sits beyond a year, and within a year both the team and the requirements change. What you genuinely need at that scale is a token set (colour, typography, spacing), 10 to 12 reusable Figma components, and a two-page document with layer and component naming rules. That takes 40 to 80 hours, removes most of the chaos and creates no maintenance obligation that nobody is there to carry.
Who should own and maintain a design system?
The owner has to be a named person whose time sits in the sprint as ordinary work. Three models work: 10 to 15 percent of one designer and one front end developer for teams up to fifteen; a small dedicated team once you pass twenty-five developers; a federated model where product teams add components and the owner reviews and guards consistency. Exactly one arrangement never works, and that is maintaining it in spare time. Spare time does not exist, and two quarters later the system no longer matches the product.
How do you know whether the team actually uses the system?
Measure coverage: the share of production screens built from system components, and the share of pull requests with no hardcoded colours or spacing. The second signal is the number of logged deviations. If it is zero, that is not perfect compliance, it is a sign people are routing around the system quietly. The third and most honest test: ask a designer and a front end developer separately whether the system speeds them up or slows them down. A single "slows down" means the thing to fix is the system, not the discipline.
Need a hand with this?
We do this work, not just write about it. Describe the task and we will scope it and send a staged estimate.
Related services
- UX/UI design for websites and appsWe design interfaces that survive contact with production: research, structure, UI kit and a clean handoff to the developers. Everything lives in Figma as components with real states and real breakpoints, not as a folder of flat mockups. The same process covers landing pages, corporate sites, e-commerce, web apps and mobile.
- Website development, end to endWe build sites that still hold up a year later: from a one-page CMS build to a store or a web application on React and Next.js. One team for design, code, integrations and launch.
- Web app and Telegram Mini App developmentFor when a site is no longer enough and you need a product: an account area, a dashboard, an internal tool or a Mini App inside Telegram. We design the architecture, write the backend and frontend, and take it to release.
Read next
- UX Research Without a Lab Budget: What Actually Produces ResultsMost teams do not need a research department, they need to stop guessing. Methods ranked by cost and payoff, the five-user rule and its important caveat, and how to turn findings into decisions without a sixty-page report nobody reads.
- Redesigning a Site Without Losing Traffic: Stages, Risks and the SEO Migration ChecklistHalf of all redesign requests are really content, speed or offer problems. How to tell them apart, why a phased rollout beats a big bang launch, and what belongs in the migration checklist so the organic traffic survives.
- What a Website Actually Costs in 2026: The Estimate, Line by LineA practical breakdown of a web development estimate: what analytics, design, front end, back end and integrations actually cost, which expenses always show up after launch, and where cutting the budget is safe.