A design system is a set of rules, guidelines, tools, and components that help teams design visually consistent and easily maintainable websites, applications or even games.

A Design System Typically Consists Of Several Parts

‍

• Component Library: Reusable UI elements such as buttons, forms, or modal windows.

• Style Guide: Definitions of colors, typography, iconography, grids, and spacing.

• Design Principles: Core values and ideas that define how a product should feel and function for the user.

• Documentation: Guides for designers and developers on how to correctly use, adapt, and combine components.

• Design Tokens: Variables like colors, fonts, or sizes that ensure consistency across the system and make it easier to work across platforms.

‍

Thanks to all of this, even a small change, like adjusting a button’s color, can be made in one place and automatically reflected everywhere.

‍

And these are exactly the main benefits a design system brings: it saves time, reduces errors, helps maintain visual consistency throughout the application, and improves collaboration between developers and designers. Everyone works with the same building blocks. Everyone knows what already exists, how to use it, and when not to reinvent the wheel. 

‍

Design systems are still not a standard part of every project. But the bigger and more complex the website or application is - with more screens, functions, and teams working on it - the more sense it makes to have a clearly defined system.

In larger projects, you often can’t do without one. It keeps everything together, saves time, and provides the team with clear guidelines to follow.

It’s essentially like a brand book but much more detailed and practical. While a brand book defines the logo, colors, or typography, a design system goes further: it describes specific components, their behavior, and how to use them correctly throughout the product.

‍

How We Designed the Design System for World of Airports

‍

The brief from the Czech game studio Flyboys was clear: modernize the outdated game interface, which had developed organically without a unified concept.

To make well-thought-out changes, we first spent time getting to know the game itself including intensive playing. The goal was to understand the game through the eyes of a regular player. That was our first and key source of insight.

‍

We also drew from several additional sources:

‍

• Internal UX testing: We ran a quick analysis with real users from our own team.

• Player feedback: Flyboys has a strong player community that helped us identify weak points.

• Flyboys’ requirements: We received a simple draft of one screen to build from, along with specific requests for new features that the new interface needed to accommodate.

‍

Based on these inputs, we designed a new design system in Figma.
We unified all game elements (buttons, cards, pop-ups) and set clear usage rules for them. Each component had variants: primary, secondary, different sizes and behaviors. For example, the basic button has 96 variants.

We regularly consulted the entire design with the Flyboys team to ensure it was based on their initial concept, aligned with their vision, and remained easy to implement for developers.

Now, if a change is needed, it’s enough to update a single component in the design system library, and that change is automatically reflected across all screens—now numbering in the hundreds. This keeps the system clear, manageable, and up to date.

‍

The Result? The Game Is Clearer and Easier to Navigate

‍

The new design system breathed new life into World of Airports. The user interface is now modern, organized, and ready for further expansion. While players needed a bit of time to get used to it, overall feedback was positive: the game looks more mature and is easier to navigate.

‍

When a Design System Makes Sense and When It Doesn’t

‍
For large websites, mobile applications, or interactive games—projects with lots of screens, features, and frequent updates—it’s worth investing in a full-fledged design system. Without one, different designers or teams may create the same component in slightly different ways, leading to unnecessary duplication and inconsistencies throughout the project.

‍

However, there are cases where a robust system may not be worth it:

• Small or short-term projects: Like one-off campaign pages or MVPs with limited lifespan.

• Small teams (1–2 people): If design and development are handled by a tight-knit team, personal communication often replaces the need for a formal system.

• Simple UI: If the interface is basic (a few screens with no repeating patterns), components can be managed without a system.

• Lack of capacity: Building a system requires time and energy. Without space or motivation, it often ends up incomplete and unused.

‍

Still, that doesn’t mean it’s not worth addressing at all. It just doesn’t need to be extensive. Even a basic UI kit with well-designed elements can help maintain a consistent style and speed up work.

When a system is well built, you know exactly what’s already been done—and you don’t have to start from scratch every time.

The approach should always match the scale and needs of the project. Large applications benefit from a robust system, while smaller ones thrive with lighter, more flexible solutions.

‍