Process

Design Systems for Complex Products: Why It's an Investment, Not an Expense

Written by

Bohdan Kononets

Andrei Zolotukhin

Category:

Process

25 March 2026

12 min read

This article is part of the Flatstudio × Stavka.tv case study. Written for product teams and designers building or scaling a digital product. Main article in the series — here.

--------

There's one thing we hear regularly: "we'll launch first, then systematize."

Over eight years of working across different products, we've never once seen that "later" arrive on its own. What we have seen: the product grows, the team expands, every new designer or developer starts improvising where there are no rules — and a year later you have an interface where buttons look different on different pages, and developers ask "what should this look like?" every single week.

A design system gets built from day one — at the right scale for where the product currently is.

A System Even for a Landing Page

We build a design system for every project. Even when designing a single-page landing, we establish a base library from the start: color tokens, type styles, a responsive grid, foundational components.

The difference between a landing page design system and a sports social network with 3,500+ components is only in scale and complexity. The principle is the same: anything that repeats more than once becomes a component. Anything that might change globally becomes a token.

It's a decision that pays off by the third screen.

[→ 🎆 example: minimal design system for a landing page vs. the full Stavka library]

The Foundation: Five Layers

Every design system we build rests on five layers — from most abstract to most concrete.

Color tokens. Named variables tied to a role: primary background, text, accent, error, success. If the brand decides tomorrow to change the primary blue — you update one token, not 400 components.
Type styles. Headlines, subheadings, body, captions, buttons — each level with defined size, line height, and typeface. For Stavka: Inter for interface text, Stavka BoldItalic for accent headlines and promotional materials.
Spacing system. A fixed scale: 4, 8, 12, 16, 24, 32, 48, 64. Designers choose from the scale rather than inventing values — and developers receive a token instead of an approximate number.
Responsive grid. Three breakpoints (desktop, tablet, mobile) with defined columns, gutters, and margins. Every component knows what environment it lives in and how it behaves when the viewport changes.
Base components. Buttons and inputs are the foundation everything else is built on. From day one, every element gets a complete set of states: default, hover, active, disabled, error, focus. That's the baseline. A component without a full set of states is unfinished work.

[→ 🎆 Stavka color tokens: roles and values] [→ spacing system: scale and usage examples] [→ buttons and inputs — all states]

How We Work in Figma

We use every capability Figma offers — and we know where it hits its limits.

Variables, Auto Layout, Slots — these are standard tools in our daily workflow, not experiments. Variables let us bind tokens directly to components and switch themes in one click. Auto Layout lets us build components that adapt to content without manual updates. Slots let us nest different content into a single template component.

We use Figma Make for animations and for quickly visualizing a brief — when we need to show a client how something moves before designing the final screen.

When Figma can't do what we need quickly and cleanly, we write a plugin. That's how the plugin for substituting real team logos and athlete avatars was born — described in the 2.0 → 2.1 article. For us, this is standard practice: the tool serves the process, not the other way around.

Handoff to developers goes through Figma Inspect and Zeplin with Avocode. The developer sees exact token values, spacing, and dimensions — no PDF with "approximate" numbers.

[→ 🎆 Variables and tokens in Figma — example component connection]

2.0 → 2.1: When We Rebuilt the System for Ourselves

We covered the pivot from 2.0 to 2.1 in detail in a separate article. But from a design system perspective, there's one important distinction worth making here.

In 2.0, we built a system from scratch — and it was a well thought-out foundation. But when we developed 2.1, we didn't copy the system from 2.0. We built a new one, using 2.0 as a reference. This is similar to what we now offer clients through our Rebuild. Rebrand. Reignite. solution: preserve the logic and experience of what already exists — but reassemble the system on a better foundation.

A design system is a way of thinking about a product, not just a file with components. When you rebuild it with fresh eyes, you shed the compromises that have accumulated and no longer fit the current scale.

The 2.1 system came out significantly stronger than 2.0 — better component organization, deeper tokenization, and dark mode readiness built in from the start.

[→ 🎆 file structure comparison: 2.0 vs. 2.1]

Dark Mode as a Result of Good Architecture

When we designed 2.1, we built the system so that dark mode would be possible without reworking the foundation. The logic is simple: if every color is tied to a role rather than a specific value, switching between light and dark should cost minimal time. You find the right shades for the dark variant, then go through the screens to catch anything that broke.

That's exactly how it went. When dark mode became an actual task, the adaptation took four times less time than it would have starting from scratch. That's what a properly organized system delivers.

Stavka's dark mode is planned to launch in Q3 2026.

[→ 🎆 dark mode: switching between variants in Figma] [→ example: the same components in light and dark mode]

When the System Paid for Itself

A design system is a hard sell at the start — its impact isn't visible immediately. But there are a few concrete moments where we felt the investment return.

Developer questions dropped by 7x. Before the system: "what color is the button here?", "what's the spacing between these blocks?", "what does the disabled state look like?" After: the first place a developer looks is the design system. They open Figma Inspect and find the answer without going to a designer.
New designers get up to speed fast. After a few sessions, a new team member can independently design new features and screens — within the system, without risking a break in consistency. In products where every previous designer did things their own way, onboarding becomes a real problem as the team scales.
3,500+ main components. Not a number for the sake of it. It's the scope of the product — every screen, every state, every platform (web, iOS, Android) covered. When a new feature gets added, it gets assembled from existing parts, not drawn from scratch.
Dark mode in a quarter of the time. Covered above — but it's the clearest example of how good architecture saves future hours.

[→ 🎆 fragment of the Stavka library — Main Components in Figma]

The Main Lesson

A design system is product infrastructure.

Like any infrastructure, it's invisible when it's working well. But it's very visible when it's absent: developers improvise, designers duplicate work, quality degrades with every new person added to the team.

Starting it "later" means paying interest. Building it immediately — even in minimal form — makes every subsequent hour of work cheaper than the one before it.

--------

If your product has grown to the point where the absence of a system has become a real pain — and you need to rebuild not just the design but the product architecture — that's exactly what we do through our Rebuild. Rebrand. Reignite. solution.
‍

← Back to the main article in the series: "Sports Predictions Platform: An 8-Year Case Study with 3M Monthly Visits"