We took two projects without design systems, analysed and built a new design system for them and after this we decreased time to market from 23 days to 4 days. It was a long journey, but in the end we brought a lot of value for our business.
So, we have two products at Trevolution.group where clients can buy flight tickets — ASAP Tickets and Skyluxtravel. Let's start from ASAP Tickets
At ASAP Tickets, clients are able to purchase tickets together with an agent. They leave a request through the search on our websites, after they receive a call from the agent and a link to their email, which leads to a page for filling out their information.
Here is a rough diagram of how the service works:
This website is designed for a budget segment and for an age group of 35-60 years old, for those who are afraid to buy tickets because there the high price for mistake. For example, in the USA the average cost of ticket equal $2400, this is an expensive price, honestly for our audience. At Skyluxtravel we have a liitle different audience, i mean with difference goals.
Skyluxtravel is a very similar product to ASAP Tickets, but it is designed for business-class tickets and the average price is accordingly higher. The target audience on this platform is between 40-55 years old. Here, users expect the service of a personal concierge.
When I joined the company in 2023 and started looking into how projects were done, I noticed that designers and developers were making pages without thinking much about consistency. For example, every time a developer saw a button in a Figma and develop it from scratch and it happened every time.
It's obviously that if you create each element from scratch, time-to-market willing to increase. At ASAP Tickets and Skyluxtravel in May 2023, development took an average of 23 days after designers handed over their mockups. It's not hard to guess that this significantly affects potential profits when launching new initiatives.
I want to add that this project is mainly about the frontend, not the backend. So, if we fix design system for frontend part, we can fix time-to-market terms.
First of all, we wanted to understand how big the problems were and set a goal to reduce, not increase, development time.
We asked the developers to gather all the code pieces they had created into one place, organized by category. This resulted in a list of buttons, avatars, input fields, radio buttons, and so on. For example, here are the buttons from ASAP Tickets before the design system was implemented:
We discussed with the tech lead amount of growth zones and tried to imagine how much a design system would help us avoid chaos and speed up development. We already had experience implementing design systems in other companies, so there was no doubt about the need for it. However, we had to present it to stakeholders in a way that would secure resources for it.
We outlined a rough roadmap for components, atoms, and organisms for the design system and provided very rough timelines. We calculated the ROI of the design system using https://www.knapsack.cloud/calculator.
Finally, we created a large presentation about the financial benefits and why we need the design system. Here is an example of a nice slide from that presentation, we tried to show that design system help the company.
And in the end this is the final slide:
In the future, the design system would help us deliver projects so quickly. As a result, we got the green light from stakeholders and started the work at the end of summer 2023. The plan was as follows:
We defined the key components and patterns that needed to be included in the design system. Together with developers, product managers, and designers, we created an initial list of components ready for development to kickstart the project. We organised a workshop using this scheme:
And we agreed on the following approach:
Design and development teams agreed to divide components into iterations based on their importance and complexity.
At the start of each sprint, developers select specific components to create and update during the sprint.
The design team tests and reviews the updated components to ensure they meet the design and user expectations.
After successful testing, the updated components are implemented into the product and become available to users.
After implementing the updated components, we assess their effectiveness and impact on the user experience to determine how well they address the set goals.
The process of changing components on the front end is iterative. After releasing new components, the next cycle of feedback analysis and planning begins. This approach allows for continuous improvement and refinement of both the product and the user experience.
We also created a calendar for team
Figma introduced Tokens, but unfortunately, designers can't use them with developers unless you have an Enterprise plan. So, we used a plugin to export tokens to JSON because we didn't have time to develop our own plugin.
This isn't rocket science, and it's been done many times before by other companies. Here's what the export from the plugin looks like:
.png)
But this didn't quite suit the developers' guidelines, so I used ChatGPT to write a small Python script that converts it into a more convenient format, like this:
So, every time when designer change the color, he export the code with plugin and rewrite it for developers' guidelines. It's not a time consuming and i think in this situation it was a great decision.
We also agreed on the format of variables for spaces, border-radius, typography, and so on. Additionally, we discussed how to set tasks for developers in Jira and the best way to create documentation for them. I will show what this looks like later in the article.
So, the main idea was create one component and change it in every project
We organized the file structure into the following categories: Icons Library, Components, Atoms, and Variable Library.
ASAP Tickets and Skyluxtravel are similar projects, so we decided to create a shared base of tokens in the Variables Library and then create aliases for the projects based on these variables. Here is what the color overrides for the projects look like:
So, you have a simple color category like "Azure" with different contrast levels, and in the ASAP Tickets project, you define it as "Accent-high". After defining the main global variables, we created the Atoms file. Here is an example for ASAP Tickets:
And example for Skyluxtravel:
After the created Atoms file, we went to create the Components file:
.png)
So, for every project we have initial component, when you connect it to your project, it inherit tokes which you set up in this project
We pasted critical components, like buttons and fields, into current mockups and created prototypes to ensure they worked as well as, or better than, the previous versions if they were changed.
It turned out we were good designers, haha and the components didn't cause any significant issues for real users in the prototypes tested through Useberry.
Since we constantly communicated with developers and designers about documentation and component functionality, we established a trend from the start for creating user-friendly documentation for everyone. We demonstrated how to use the components correctly:
Showed all the states and what atoms we use in the buttons:
Perhaps some parts of the documentation were unnecessary, but we couldn't be stopped, we wanted to create a truly convenient and understandable instruction for everyone:
Organisms in the design system were also already created, for example widgets with a price:
.png)
As mentioned earlier, we had a calendar for implementing components. Using buttons as an example, this is how the calendar worked:
Monday — We planned to analyze the legacy code, select best practices, and create the button component with documentation.
Wednesday — Discussed the interim results for buttons with the developers and received feedback.
Friday — Tested the buttons with designers (acting as Figma users) and real clients using prototypes.
Monday (Week 2) — Assigned the button task to the developers.
Wednesday (Week 2) — Synced with developers and reviewed the progress on the buttons.
Monday (Week 3) — Implemented the buttons on key pages and measured conversion rates, which did not change. After this, the developers independently created a plan to replace buttons throughout the entire project.
Thanks to the fantastic team of developers and designers, this transition was smooth and without major technical issues.
Now, 98% of components in the projects are added from new design system.
The most hardworking part was move old pages to new one in the Figma and development, but it's just routine which we include on our workflow and move new components to pages step by step.
Of course, we still have some pages with old components, but as soon as they need to be changed these pages, we will update them to the new components right away. For example, we are currently actively migrating the payment page to the new system:
We have been working with new design system since Summer, 2023 and we have already a great new numbers regarding new design system implementation:
We were really surprised when we compared the numbers in Jira for the similar tasks, so we just added admin panels, an online chat, and one more secret project to this design system, saving a lot of money for business. Designers can make new colors, new typography for thier projects, we just connect our design system and start work faster.
Today, we can launch new and manage current project faster than before. Thank you so much for helping with design system for Artem Udovichenko and Roberts Kaplans.
For new landing experiments, developers can't quickly test new forms because they have to implement new elements of the design system. Therefore, we have decided to skip the design system implementation stage during the experimentation period. However, after a successful experiment, we will officially add a new component to the design system.
When we made the decision to apply this design system to another project, we encountered many questions and realized that we lacked proper documentation for developers on how to connect the design system to the project. We quickly fixed this.
We began in Summer, 2023 and were optimistic to complete it by January, but unfortunately we had to continuously switch to other projects. We finally released the initial version of the design system in February of 2024.