Design Systems: When Your Product Earns One, and What It Costs

A design system is a repository of visual and interaction decisions, plus a team with the authority to change them. Your team can build the first part in a few weeks. The second part decides whether the system is still alive six months later. That is why the decision starts with one question: from today on, who approves a change to the button? If you have no answer, you are building a component library, not a design system.

Nielsen Norman Group defines it as a complete set of standards for managing design at scale through reusable components and patterns, and adds that it has two parts rather than one: the repository, and the people who manage it. This guide covers both, then hands you a calculation to run with your own numbers before you commit.

What separates a system from a tidy Figma file

The difference is not the component count. A Figma file with a hundred organised components is still a file. It becomes a system when three things are added: shared values that design and code both read, a known version for every component, and a written rule saying who changes what and when.

The third is what is usually missing on local teams. You find an excellent Figma library, a parallel React library, and then a developer who adds a new button on the invoices screen because the existing one did not fit the size. Now you have two buttons. A year later you have seven. Atlassian names this risk directly among the benefits of its own system: when knowledge is not documented, teams risk losing it during staff changes.

What design systems actually contain

Instead of listing what a system "should" contain, here is what respondents actually have, from the zeroheight Design Systems Report 2025, a survey of just under 300 people with data collected between September and November 2024:

The figure worth stopping on in that report is code libraries at 73%. More than a quarter of the people who say they have a "design system" have no code library, which means their system lives in the design tool alone and gets rebuilt by hand on every screen. That is exactly the case you pay for twice: once in design and once in engineering.

The figure that moved fastest is tokens: 84% this year against 56% the year before, in the same report.

Design tokens: the layer that connects Figma to code

A design token is a name and a value. The name stays, the value moves. When the designer's file and the developer's code both point at the same name, the colour is the same in both places even after its hex value changes, as the Material Design 3 documentation explains.

Material organises tokens into three layers, which remains the clearest model of the structure:

The system layer is where theming happens. It is what turns dark mode into a switch in one reference instead of a review of every screen. And among the contexts the documentation lists explicitly, alongside device form factor and dark mode, are right-to-left writing systems. In practical terms: the right-side inner padding of an Arabic interface can be settled once in the token rather than handled by each developer in their own file. If Arabic is your product's first language, that alone is reason enough to build the token layer before any component.

What changed in 2025

For years, exchanging tokens between tools meant a mess of proprietary formats. On 28 October 2025 the W3C Design Tokens Community Group announced the first stable version of the specification, numbered 2025.10, after three drafts running from 2021 to July 2025 as the version table in the group's repository records. The files themselves are ordinary JSON, not a proprietary format that needs one particular tool to read.

What this means for your team is three things: light and dark modes and multi-brand themes managed without duplicating files, support for modern colour spaces such as Display P3 and Oklch, and a single token file that generates code for iOS, Android, web and Flutter. The group cites reference implementations in Style Dictionary, Tokens Studio and Terrazzo, and more than ten design tools supporting or implementing the standard, among them Figma, Sketch, Framer and Penpot.

The actionable takeaway: if you are building a token layer this year, build it on this format rather than one tied to a single tool. The cost is the same today; the difference shows up the day you switch tools or add a platform.

Automation is less common than it sounds

Tokens are a popular idea and the automation behind them lags. In the same zeroheight report, 26% have no automation at all in their token pipeline, and 21% describe themselves as "not yet, we're working on it". The biggest challenge respondents name is defining token architecture (57%), then managing tokens (39%), then integrating them with an existing codebase (37%), while 29% complain openly about the sheer quantity of tokens they have to manage. In every one of these cases the obstacle is an unsettled human decision, not a missing tool.

The lesson for a small team: start with a number of tokens you can hold in your head. A system layer of thirty names that actually get used beats three hundred names where the developer cannot tell which one to pick.

Governance: who approves a change to a component

This is the question most articles skip, and the one that decides whether the system survives. Governance here means one thing: a stated rule for who adds, who edits, and who says no.

How contribution rights are distributed among zeroheight's respondents:

So roughly a third of teams restrict contribution, and a restricted model is not automatically wrong. Atlassian opens contribution to its own employees only, accepting fixes and small enhancements such as adding an icon to the existing library, while stating that major enhancements and new components may not be accepted because they require coordination across code, design and guidelines. The page adds an admission that is rare in company documentation: "It is currently difficult to contribute to the design system — we're working on improving this." In return, the team runs a fortnightly critique session.

Look at the trade-off as it is: the wider you open contribution, the faster you move and the less consistent you get; the tighter you close it, the reverse. There is no setting that is correct for every team. What the report says is that satisfaction with governance leans positive (37% satisfied and 6% very satisfied, against 18% dissatisfied and 3% very dissatisfied), and that the recurring reason behind that satisfaction is light, basic governance: the "just enough" level.

The most relevant finding for you specifically: in the same data, satisfaction with contribution falls as the company grows, from 44% at companies under a hundred employees to 28% at companies between 500 and 999. Your advantage right now is that your team is small, and the process you set today is cheaper than the one you will need in three years.

The minimum that works for a team of five to ten: one person owns the merge decision on the shared library; one channel where requests are logged in writing rather than spoken; and a rule that any new component lives in its own team's code first and only moves into the shared library once a second team uses it. That last rule alone prevents most of the bloat.

Versioning: changing a component without breaking the product

A shared library is an API, and changing it breaks whatever depends on it. The industry answer is semantic versioning with a stated deprecation policy, and the clearest published example is Shopify Polaris's deprecation guidelines.

What Shopify does when withdrawing any element:

1. Mark it deprecated inside the code itself, pointing at the replacement.
2. Update the documentation page and record the reason and the alternatives.
3. Write an automated migration (a codemod) that applies the change to consumers' codebases.
4. Announce all of it at least a month before the next major release.
5. Remove the element only in the next major version branch.

The detail most teams miss: at Shopify this cycle covers more than components. It applies to a prop, to a specific value within a prop, and to the token itself. Naming a token is a long-term commitment exactly like naming a component, so renaming color-primary to color-action without a deprecation cycle breaks every screen reading the old name, however much it looks like tidying inside the design file.

A small team does not need all this machinery. Three commitments are enough: a version number on the shared library, a changelog with one sentence per change, and a rule that nothing is deleted before being deprecated for at least one cycle. Deprecating before deleting is the difference between an upgrade that takes an hour and one that stalls the team for a week.

When it is worth it for a small team in Egypt or the Gulf

This section is trying to talk you into waiting, because the wrong timing is the most expensive mistake here.

The numbers say enterprise-grade systems are not the norm at small companies. In zeroheight's data, among companies under a hundred employees, 60% have no design system team at all, 25% are partially resourced, and only 15% have a dedicated one. The average team size in that segment fell from 5 to 3 people between the two surveys. The trend at small companies points to less, not more.

Nielsen Norman Group says the same thing in decision terms: for a proof of concept or an initial prototype likely to change, building a full system does not generate a desirable near-term return, because the whole benefit sits in future repetition. Material's documentation adds a parallel constraint: tokens are less helpful for an existing app with hard-coded values that is unlikely to change in the next year or two.

Signs that building now is the right call:

• You run more than one surface on the same product — a site, an admin dashboard, an app — and want them consistent.
• More than one designer or more than one frontend developer works on different screens at the same time.
• You repeat the same screen with variations: an orders table, an invoices table, a users table.
• You foresee repeatable design work stretching over years, not months.
• Arabic is the product's first language, and you pay for RTL decisions screen by screen.

Signs that it is too early:

• The product has not settled its shape and you may redesign it entirely within six months. Start from a minimum viable product instead.
• One designer and one developer, coordinating in a short conversation.
• The product is a landing page or a brochure site you will not add screens to.
• You do not yet know what the user needs from the screen. A system unifies appearance; it does not fix function, and that is the job of user research.

Between the two sits a middle option most articles ignore: adopt rather than build. Nielsen Norman Group describes three approaches, adopting an existing system as is, adapting it, or building your own, and notes that cost and time rise with customisation. For a team of six in Cairo or Jeddah, adapting an existing open system and adding a token layer for your own brand delivers most of the benefit at a fraction of the cost.

What it costs: a calculation you run with your own numbers

There are no reliable published prices for building a design system in the Egyptian or Gulf market, and any ready-made figure you read is usually imported from another market. The only honest method is to calculate it from your own inputs. If what you want is the market price of buying a system as a service inside a design quote, that is the subject of our UX/UI design cost guide.

The formula is simple: cost = person-months × your monthly cost per person.

Person-months come from two documented points: Nielsen Norman Group puts the minimum system team at one interaction designer, one visual designer and one developer, and the average team at companies under a hundred employees is three people. But those three need not be full-time, which is why a quarter of small companies describe their team as "partially resourced".

A hypothetical example. The figures below are assumed inputs to show the method. They are not market rates and not Snaabble's rates. Substitute your actual fully-loaded monthly cost per person:

Notice what the arithmetic exposes: year two costs more than year one. Building the system is a project that ends; maintaining it is a recurring line that does not. The data bears this out: the biggest challenge respondents name in the zeroheight report is lack of resources at 63%, and Nielsen Norman Group describes it as a time-intensive activity rather than a one-and-done solution.

Break-even is calculated like this: divide total person-months by the number of screens you intend to ship in the next twelve months, then compare the result against the time the system actually saves you per screen. If you cannot write down a projected screen count today with confidence, you are in the postpone phase, not the build phase.

Three decisions lower the cost without hollowing the system out: start with tokens and eight to twelve components that cover most of your screens rather than aiming for full coverage; write the code library from day one so you do not land in the quarter that owns design with no code; and build WCAG accessibility standards into the component itself, because fixing it later on every screen costs more than building it once.

What to do now

If the postpone signals apply to you, postpone, and build one habit instead: a shared file of colours, spacing and type that both design and code read. That is the token layer in its simplest form, and it is all you need today.

If the build signals apply, this is the order that works: a token layer on the stable format, then the components that repeat most, then short documentation answering "when do I use this component and when do I not", then one named person against the merge decision. Sort those four out before you draw the thirteenth component.

And before you sign with any vendor to design your product, ask how they hand over the system and who owns it afterwards. That question belongs to a longer list in how to choose a UX/UI design agency, and it helps to know the UX/UI design principles they are supposed to apply before you get there.

If you are planning a design system for your product, or unifying interfaces you already run, send your idea to Snaabble's UI/UX design team and you will get an initial plan with a time and cost estimate within 24 hours, free and with no commitment.

Sources

• Design Systems 101 — Nielsen Norman Group, last reviewed 27 August 2026.
• Design Tokens specification reaches first stable version — Design Tokens Community Group (W3C), 28 October 2025.
• Design Tokens Community Group — specification repository and version table — DTCG.
• Design tokens — Material Design 3, Google.
• Deprecation guidelines — Shopify Polaris.
• Contribution and About the Atlassian Design System — Atlassian.
• Design Systems Report 2025 — zeroheight, data collected September–November 2024.

All links reviewed on 22 September 2026.