If Antoni Gaudí had a design system, maybe the Sagrada Família wouldn't be taking over a century to finish.
As a development studio, we know one thing for sure: Without structure and consistency, even the best idea can turn into chaos. When building tech solutions for businesses, chaos leads to logic gaps, delays, and endless revisions. Time is money, and last-minute fixes always cost more.
That’s why we’ve built a culture of thinking not just for each other, but with each other. From day one, our designers think about how components will be handed off to the development team. Our developers stay synced with the library and see how things play out in real-world scenarios.
Recently, this mindset saved us on a complex project: building a custom internal platform for managing MICE (meetings, incentives, conferences, and exhibitions). Spoiler: it was a real challenge. There were dozens of screens, layered logic, dynamic tables, status states, and data validation. One misplaced button could cause a travel manager to lose a group’s entire flight itinerary.
Here’s how we survived the chaos and used our design system to transform unpredictability into a fully functional product.
:Puls. Custom Hybrid Event Management Software – from Guest Lists to Logistics
Where It All Started
Our designer, Nastya, was the first to join the project. The tech spec was already complex, with all the logic laid out in lengthy documents and flowcharts that took time to decipher. One thing was clear from the beginning: the interface would be complex. There would be dozens of screens. There would be repeat elements with different logic and conditions. We needed more than just attractive screens – we needed structure.
To give everyone a clear view of the product, we decided to create a high-fidelity prototype right away. This helped both the client and our team understand how everything would work and whether it would truly solve their business needs.
Why An Outsourced Development Team Should Be Part of CustDev
Sure enough, changes started rolling in from the very beginning. The client kept revising flows, removing steps, and moving blocks around. With deadlines closing in, we merged the prototyping and design stages. Nastya mapped out the key sections and created reusable components from the design system to speed up the development handoff.
Scope Wars: How We Got the Client to Rethink the Product Without Ruining the Relationship
How do we rethinking Atlassian
Designing a complex internal tool is tough enough. Doing it in a niche industry? That's the next level.
As a reference Nastya chose Atlassian’s design system, which is layered, well-structured, and complete with tokens and patterns. It matched our goals almost perfectly and provided a solid foundation for customization.
That decision paid off. Without a structured component library, our interface would have collapsed under its own weight. Every tweak would have meant reworking dozens of disconnected elements. However, with the design system, Nastya built prototypes from ready-made blocks that transitioned smoothly into the final UI. We could make updates on the fly without starting from scratch or breaking the flow.
Building the full library took about a month. After that, we moved on to full-scale development, and that’s when the system really proved its worth.
Need a team for rapid development? Tell us about your project
How it affects development process
Front-end developer Andrey joined the project after the design system had already been assembled. The components, from inputs and buttons to cards and hovers, were neatly arranged in blocks with a clear structure and decomposition. This set the right pace immediately: practically nothing needed to be adapted. Only the layout needed to be arranged according to modularity. Although this required a large amount of work, it would result in minimal future costs.
One of the most difficult modules was the transfer logic. Participants, hotels, venues, flights, and accommodations had to be collected in a table section that was convenient for managers. Many changes to the agreed-upon business processes occurred during the process. When we finally released it, we found that the logic we had designed three months ago simply did not work in reality.
We had to rebuild the logic in a week. At that point, we almost switched to live coding mode. If the logic didn't work somewhere, we changed the interface on the spot. Edits were made during conference calls. In a couple of minutes, Nastya and I rebuilt entire modules for the new logic.
To keep everything synchronized, we created a separate Change log tab in the library. In it, the designer recorded all additions to the design system, including the date, description of the edit, and links to the layouts. Any changes — color, text, size, or icon — were automatically rolled out across the entire project.
During assembly, Andrey selected the necessary components and immediately obtained their parameters, including styles, states, indents, and fonts. No measurements or manual adjustments were necessary because everything had already been designed during the library assembly stage.
The Pain Points
Even though the system was flexible and scalable, the size of the library came with technical challenges.
Publishing and syncing the library in Figma was time-consuming. Five minutes might not sound like much, but in Figma terms, that’s slow. Sometimes, the design file would barely load because of the number of components and links.
And then there were the tables.
We wanted to unify the tables, but it just wasn’t realistic. Each table had unique logic. Trying to force them into one structure would have taken more time than designing them from scratch. So, each table became its own thing.
Why We’d Do It All Over Again
We spent about 100 hours building the design system. And it was worth every minute. The result is a robust, reusable component library containing hundreds of versions of buttons, checkboxes, inputs, switches, calendars, and breadcrumbs. Each one is documented and ready for development, complete with styles and logic.
This gave us the following:
- Scalability – reusable components that don’t conflict or break;
- Consistency –every screen follows a shared visual and logical structure;
- Speed – no time is wasted recreating elements because they're simply reused.
- Clarity – everyone knows what to build, how it works, and where it lives;
- Flexibility – we adapt quickly, even when the logic changes at the last minute.
Most importantly, it’s all documented. If the project is handed off, the next designer can update every button and font across the entire product in minutes. No broken screens. No guesswork. No lost logic.
That’s what we call a systematic approach.
