Design system: how to stop redrawing buttons and start saving development time

Author: Elena Gribanova, Bulltech designer

There is a special kind of digital madness: when seven kinds of «Submit» buttons live in one project.

One is slightly higher.
The second one is slightly darker.
The third one has two pixels more rounding.
The fourth one appears only in the modal window, because «it was drawn that way once.»
The fifth one seems to be the same, but for some reason with a different indentation.
The sixth one left in the mobile version.
Nobody touches the seventh one, because it’s «on the old page, it’s better not to go there.»

And it doesn’t seem to be anything terrible. Well, there’s a button. The user does not come to the site with a ruler and does not measure the radius of the rounding. But the problem is different: the team starts spending time not on the product, but on endless reproduction of the same solutions.

Each new screen turns into a small investigation: which button to use, which header size to use, what the input should look like, what the indentation between the blocks is, where the current version of the card lies, why one thing is in the layout and another on the site.

And now the developer is no longer developing a new feature, but clarifying:
«Is this button the same as on the main one?»
The designer replies:
«Almost the same, just a little different here.»
The manager looks at the deadline and feels the «panic» tab opening somewhere in his soul.

It is at this point that the design system enters the scene. Not as a buzzword from a presentation, but as a normal working tool that helps the team stop reinventing the interface every time.

A common mistake is to think that the design system is a folder in Figma, where there are buttons, input fields, checkboxes and a couple of neat cards. It looks beautiful, you can show it to the client, everyone nods.
But if no one uses it, if the developer doesn’t understand how to transfer it to the code, if the designer unpins the component every time and draws «almost the same, but a little different», then this is not a design system. This is a museum of interface blanks.
The design system does not start with a button. It starts with an agreement: how we design the interface, how we name the elements, what states they have, how they behave on different screens, and what is considered the norm for the product.
It’s not about «doing it beautifully once.» It’s about making things faster, more stable, and without unnecessary arguments.
In a good design system, a button is not just a rectangle with text. It has a purpose, dimensions, states, limitations, and usage logic. The main button is needed for the main action. Secondary — for additional use. A dangerous action, such as deleting, should not look like the usual «Save». The inactive state should not be a mystery to the user.
It would seem like small things. But it is precisely from such small things that an interface is formed that looks solid, and not like a communal apartment, where each screen was made by a separate neighbor.

At the start of a project, it often seems that a design system is not needed. Especially if the project is small. There are several pages, clear logic, the designer draws quickly, the developer makes up quickly. Everything is cheerful, the coffee is hot, the deadline is still far away.
And then the project grows.
A personal account appears. Then the administrative panel. Then the filters section. Then the product cards. Then the order statuses. Then the mobile version. Then there’s a new script that «needs to be added urgently, it’s kind of just a form.»
And now, «just a form» suddenly requires answers to questions.:
What does the required field look like?
How do we show the error?
Where do we place the hint?
What happens if the field is not filled in?
What does the disabled state look like?
How does the form behave on mobile?
What should I do with long text?
What are the margins between the fields?
What is the style of the drop-down list?
If there are no answers, the team starts accepting micro-solutions anew each time. And it’s a very quiet time eater. He doesn’t look like a big problem. No one will say, «We’ve lost a week because we don’t have a unified approach to inputs.» This is usually spread out over the project in small pieces: here an hour, there two, here an edit, there a recheck, here the designer clarified, there the developer redid.
As a result, the team works a lot, but it feels like it’s skidding in the sand.
The most annoying thing is that such losses are difficult to notice right away. They don’t lie in the same task called «Wasting 18 hours on interface chaos.» They hide in comments, phone calls, correspondence, and endless «what should it be like here?»
A design system is not needed to make everything look beautiful. Beautiful is a nice bonus. The main benefit is that the team stops solving the same thing ten times.

Let’s take a simple example: a button.
Without a design system, the designer draws a button in each new layout. Sometimes he copies the old one, sometimes he does it a little differently, because «it’s compositionally better here.» The developer rebuilds it or adds a new class. A month later, the project already has several versions of the same entity.
Then the task comes: to change the style of the main buttons on the site. For example, make them slightly larger, change the color, adjust the rounding, or add a different hover state.
If there is only one button and it is normally wound up as a component, the change is made centrally. We updated the component and the changes spread across the interface. The developer adjusted the basic component in the code, and the product became uniform.
If there are seven buttons, the archaeology begins. Where is which one used? Which one is relevant? Is this one exactly the same or not? Why is the button made in a separate style here? And if you fix it globally, nothing will break?
At this point, the button stops being a button and becomes a small swamp.
The design system does not negate the complexity of the product. But it removes unnecessary complexity where it shouldn’t be at all. The button should be predictable. The input field should be predictable. The card should be predictable. The user interface does not have to give the team a creative exam every time.

Иногда дизайн-систему воспринимают как инструмент для дизайнеров. Мол, им удобно собирать экраны из готовых компонентов. Это правда, но только часть истории.

Разработчикам дизайн-система часто нужна даже больше.

Когда в макете есть понятные компоненты, состояния и правила, разработчику не нужно гадать. Он понимает, что перед ним не «новая уникальная кнопка с авторским настроением», а стандартный компонент Button в варианте primary, размере large, состоянии default. Это можно быстро перенести в код, использовать повторно и не плодить лишнюю верстку.

Для менеджера дизайн-система тоже полезна. Она делает оценку задач адекватнее. Если нужно собрать новый экран из готовых компонентов, это одна история. Если нужно проектировать новый нестандартный сценарий с нуля, это другая. Когда компоненты уже описаны, проще понимать объем работы и не превращать каждую страницу в загадку.

Для тестировщика дизайн-система тоже подарок. Появляется эталон: как должно выглядеть поле, как должна показываться ошибка, как ведет себя кнопка при наведении, как выглядит пустое состояние. Проверка становится не вкусовой дискуссией, а сравнением с правилами.

Для бизнеса польза еще проще: меньше хаоса — меньше часов. Меньше часов — ниже стоимость изменений или больше полезной работы за те же деньги. Продукт развивается быстрее, а не тонет в косметических переделках.

This is a popular objection. It seems that the design system is needed only by large services with hundreds of screens, design teams, and individuals with positions like «chief button keeper.»
In fact, the design system can be of different scales.
For a large product, this can really be a large library of components, documentation, design tokens, accessibility rules, a separate update process, and synchronization with the front-end.
But for a company’s website, online store, service, or administrative dashboard, a design system can also be useful. It’s just going to be more compact.
You don’t have to start with a monumental 120-page document. Sometimes it’s enough to fix the basic things.:

• typography;
• colors;
• buttons;
• input fields;
• cards;
• modal windows;
• tables;
• notifications;
• grids and margins;
• the states of the elements.

This already greatly reduces the number of random decisions.
The design system should not be «like the big guys». It should match the size of the product and the objectives of the team. A small project does not need an interface spaceport. He needs a proper kitchen, where the knives are in one place, and not in a new cabinet every time.

There are projects where the lack of a design system starts to hurt almost immediately.
The first case is personal accounts and web services. There are many repetitive elements: forms, lists, tables, filters, statuses, cards, notifications. If they are not standardized, the interface quickly begins to spread.
The second case is online shopping. Product cards, filters, purchase buttons, favorites, availability statuses, shopping cart, checkout. Everything seems familiar, but there are a lot of details. If each block lives by its own rules, the user begins to feel insecure. And uncertainty in e-commerce often ends with a closed tab.
The third case is administrative panels. They are often underestimated because «it’s not for the client, but for the employees.» But the employees are also people. If the admin panel is chaotically assembled, they take longer to learn, make mistakes more often, and constantly ask where to click. As a result, the business pays not only for development, but also for daily inefficiency.
The fourth case is products that will take a long time to develop. If it is already clear that the project will not end after launch, but will be overgrown with functions, it is better to lay the design system earlier. Otherwise, you’ll have to put the accumulated interface garage in order later.

There is one more important thing: visual integrity.
The user may not understand why one interface seems neat and reliable, while the other causes a feeling of «something is wrong here.» But it reads it very quickly.
When the site has different margins, button styles, header sizes, and element behavior, the interface starts to look random. Even if technically everything is working. It’s like coming to a company’s office, where the reception is marble and coffee in porcelain, and the meeting room is designed as a back room after moving in. The company seems to be the same, but trust has already dropped a little.
The design system maintains a single visual language. It helps the product to speak with one voice. It’s not like the main page is in the «premium minimalism» style, the personal account is in the «2011 table» style, and the application form looks like it was found in an old archive and was regretted to be deleted.
For the user, the integrity of the interface is a signal of order. And the order in the interface is often read as the order in the company. Especially when it comes to B2B, complex services, expensive products or services where reliability is important.

Putting aside the fancy words, the design system consists of several levels.
The first level is the basic visual rules. Colors, fonts, grid, margins, radii, shadows, icons. This is the foundation. If it is not fixed, each subsequent element will be built by eye.
The second level is components. Buttons, fields, checkboxes, radio buttons, radio buttons, drop-down lists, tabs, cards, badges, notifications, modal windows. It is important not just to draw them, but to show the states: normal, hover, active, inactive, error, loading, success.
The third level is patterns. These are no longer individual elements, but typical scenarios. For example, a registration form, directory filtering, a table with actions, confirmation of deletion, an empty list, an error in uploading data. Patterns help you not to reassemble each scenario from the details.
The fourth level is the rules of use. When to use the main button, and when to use the secondary one. How to write error texts. Where to place hints. How to show long titles. How to create required fields. What to do if there is no data.
The fifth level is development communication. The components in the design must match the components in the code. Otherwise, the design library lives in one reality, the frontend in another, and the manager runs between them with the eternal question «why not like in the layout?».
This is where the real savings begin. When Figma and the codebase speak the same language, the team works faster. Not perfect, not magical, not without mistakes. But noticeably calmer.

Almost every interface mess starts with this phrase.
«Let’s quickly make a separate button for now.»
«Let’s change the indentation here a little bit, then we’ll bring it to the system.»
«Let’s launch this screen now, and then carefully rewrite it.»
«Let’s not start a component, it’s a small task.»
Sometimes it’s really justified. There are urgent tasks, temporary solutions, and hypothesis testing. The problem begins when «so far fast» becomes a permanent way of developing.
Temporary solutions have amazing survivability. They remain in the product, become overgrown with dependencies, become part of the user’s script, and then it’s scary to touch them.
The design system does not prohibit flexibility. It just makes sure that exceptions remain exceptions. If each new block requires a unique design, then the problem is not in the product, but in the process.
A good system should help, not stifle. If a designer has to break a component in every second layout, then the component is poorly thought out. If it’s easier for a developer to write a new element than to use an existing one, then the system is inconvenient. If the team does not understand where to look for the current rules, then the documentation is done for show.
A design system is not a cabinet with a «do not touch» sign. This is a working tool. It needs to be maintained, updated, and sometimes honestly acknowledged: the old solution is no longer suitable.

The worst way to implement a design system is to announce: «We will now stop all tasks for a month and build the perfect system.»
First of all, it won’t be perfect anyway.
Secondly, the business is unlikely to be happy.
Thirdly, the team will start to quietly hate this great interface repair in a week.
It is better to go gradually.
First, conduct an audit of what is already there. See how many options for buttons, fields, cards, headers, and modal windows live in the project. It’s usually very sobering. Sometimes a team thinks it has «a couple of discrepancies,» and then finds a whole zoo of components.
Then select the basic elements that are used most often. You don’t need to start with a rare complex widget that appears on one page. It’s worth starting with something that repeats all the time: buttons, typography, forms, cards, tables, statuses.
After that, you need to bring the components to a single logic and fix the rules. Not just «here’s a beautiful button», but where it is used, what states it has, what sizes are acceptable, and how it looks on mobile devices.
Next, it is important to synchronize design and development. If the component appeared in Figma, but did not appear in the code, the savings will be half. If there is a component in the code, but the designer draws it differently, discrepancies start again.
Finally, we need to agree on the rules for the development of the system. Who adds new components? When can I make an exception? How do updates get into the project? Who makes sure that the system does not turn into a dump of old options?
Yes, that sounds less romantic than «creating a visual ecosystem of the brand.» But it works.

There is a fear that the design system will make the interface boring. Everything will be according to the template, no freedom, the designers will just start moving the finished cubes.
In practice, the opposite is true. The system frees your head from the routine.
The designer doesn’t have to think every time about what size to make a standard button or how to make a typical error in the field. These decisions have already been made. This means that you can devote more time to the script, logic, meaning, convenience, and those places where strong design work is really needed.
It’s like grammar. It doesn’t stop you from writing good texts. It helps you not to stumble on every sentence. But when there is no grammar, the reader is constantly distracted not by the meaning, but by oddities.
The design system works the same way. It is not a substitute for thinking. It removes the noise.
A good interface doesn’t become good just because it has a library of components. But without a system, a large and evolving interface almost inevitably begins to disintegrate. Not immediately. Gradually. One non-standard block, one temporary button, one «let’s do it a little differently here.» And then the team opens the project six months later and realizes that it’s easier to move than to get out.

It’s important not to overdo it.
The design system should speed up work, and not turn every change into coordination with the interface ministry. If you need to go through three meetings to add a small item, fill out a form, and wait for the radius committee to approve it, the team will start bypassing the system. And she’ll be right.
The system should be clear, accessible and lively. The components should be easy to place. The rules should be written in human language. The names should be logical. The developer and the designer must understand each other without a translator from «figmovsky» to «front-end».
Bureaucracy begins where rules exist for the sake of rules. The benefits begin where the rules resolve the issues.
For example, it’s bad: «All interface elements must comply with the approved visual concept in accordance with the regulations.»
OK: «For the main action on the screen, use the primary button. It is advisable not to use more than one primary button on one screen, so that the user understands which action is the main one.»
The first one sounds solid, but it doesn’t help much. The second one can be applied in your work right now.

The greatest value of a design system is not shown at the moment of creation, but later.
When you need to quickly build a new page.
When a new section appears.
When the brand style changes.
When the product is adapted to mobile devices.
When a new designer is connected.
When a developer comes to a project and tries to understand how everything works here.
When a business asks for a «small revision» that actually affects half of the interface.
With a design system, changes go through a clear structure. Without it, every change is like a renovation in an apartment where it is not known where the wiring runs. It seems like you just need to hang a shelf, but it’s better to pray first.
If the product lives a long time, the design system starts saving time all the time. More than once. Not on the same screen. And every time the team does something new or changes the old.
This is normal product maturity: do not heroically extinguish interface fires, but make sure in advance that they occur less frequently.

To put it quite literally, a business gets three things.
The first is speed. New screens and functions are assembled faster because some of the solutions have already been adopted and implemented.
The second is predictability. The team evaluates tasks better, argues less about details, and returns to the same edits less often.
The third is quality. The interface looks seamless, it’s easier for the user to navigate, and the product doesn’t turn into a collection of pages put together in different eras by different people for different moods.
And there is a fourth, less obvious thing: calmness. When a project has a system, there is less chaos. And chaos in development always costs money. It’s just that sometimes it’s hidden not in estimates, but in correspondence, postponements, and the phrase «we’ve already kind of discussed this.»

The design system is not about drawing beautiful buttons once and proudly putting them in Figma. It’s about getting the team to stop wasting time repeating the same decisions.
It helps the designer not to redraw the basic elements. The main thing for a developer is not to typeset the same thing in different ways. The manager needs to better understand the scope of tasks. Business needs to develop the product faster and pay less for chaos.
In interfaces, as in workflows, order rarely appears on its own. If you don’t create it, it gives way to randomness. And randomness likes to multiply.: first, one non-standard button, then three card options, then five shape styles, then the whole project starts to look like it was assembled piece by piece from different boxes.
A design system does not automatically make a product successful. But it creates a foundation on which it is easier to develop it. Without making too much noise, without the eternal «what should it be like?» and without ritually redrawing the «Send» button for the seventh time.
Because the button is, of course, a small detail. But if the team stumbles over small details every day, the big product starts moving very slowly.