Creating a Design System for Nelogica

EN

Creating a Design System for Nelogica

Nelogica

Understanding the Challenge

Nelogica is a company with over 500 employees and large teams working together to create and manage products that reach all technology platforms. The Design System (DS) aims to create bridges between the UX/UI Design and Programming teams, and with that in mind, the implementation was focused on an early-stage product that serves the cryptocurrency market.

Research

The opportunity to implement the system came during the creation of this new product, where I identified that it would be possible to enhance communication between designers and developers. So I began to study creation processes, taking the Design System course from Meiuca and Alura to understand how DS could be applied.

During the courses, what I noticed was that the Design System construction process is quite similar to the Double Diamond, which is a design process model, where we start by identifying the problem itself and go through stages of definition, development, and product delivery. Thinking about this structure, I used the construction method created by Meiuca, which is represented in the image below and will be discussed throughout the article.

Introduction

At this stage, the most important aspect was defining what a Design System is, which, in essence, is a product that aids in creating easier and more consistent interfaces. It comprises a set of styles, components, and rules that guide interface development.

Another interesting point is the mention of Design Tokens at this stage, which are essentially variables in programming. They are tokens with some identification that receive information. The key here is that we can change the information of the token and reuse it.

With this information, I was able to identify the points that could justify the construction of the system. Among them were: reducing the time for creating and developing new interfaces and improving communication between design and development teams.

Through an understanding of how the product works, it was possible to outline how the Design System would manage the application, which involves building and creating new features first for the DS and then for the brands that use it, as demonstrated in the image below:

With this understanding of what it is, how it operates, and the justification for why we should invest in building the Design System, I was able to communicate to my leaders about the positive impact this product could bring to the teams, and they agreed to take on the challenge.

Discovers

After defining some terminologies and the value proposition of the Design System, we moved into the stage of discovering the product, where it was necessary to conduct a survey of all interface style details such as: colors, typography, spacing, rounding, etc. During this process, inconsistencies in the interface were already noticeable, such as a color that varied depending on the system interface and could cause confusion for users.

It was also necessary to catalog the components, such as buttons, inputs, modals, select boxes, and any other design artifacts in the interface. This catalog was essential so that we could organize and document them, guiding both current and future designers of the company, thus reducing inconsistency in the product.

Definition

With the gathered information from the product discovery meetings, I began the process of defining what was correct to use. Various tests were conducted to understand which styles and components were being used and which ones were correct. One of the most interesting processes was the color review. With visibility and accessibility in mind, I conducted the following test: in the first stage, I analyzed the colors of both the light and dark themes of the interface, and we managed to eliminate 6 colors that didn’t have a good variation. As a result, we reduced some lines of code. Another point to consider is that in this product, the user can change the interface colors. Therefore, a test on these colors was also necessary, and it was identified that yellow did not perform very well with the light mode of the interface.

What I found interesting was that on the Design side, we already had some initiatives built through a style guide, and with the developers, there was code reuse. So, we were able to reuse a lot of what was already there to optimize the product definitions.

In the first stage, we discussed design tokens, and it was necessary to define them. The most important thing was to demonstrate what each token represents by its name. One rule I used was as follows:

In this way, when a designer and/or developer sees a design token such as “brand-primary-color,” they know that it refers to a primary color of the brand and already have indications of its usage in its name.

Implementation

“The final stage of the Design System required documentation of the product’s styles and components. Therefore, I created a file in Notion with all the details organized:”

With this documented information, I was able to make access to the Design System more democratic. After its launch, any employee could access and understand more about the principles guiding the construction of the interface of the product in question. With this, it was possible to devise an implementation strategy, in which we held regular meetings with developers and other designers to manage the Design System.

Conclusion

During the construction of the Design System, it was possible to make adjustments to our design process. There was a significant improvement in communication with developers, and it shortened the time for building new interfaces, allowing us to focus on refining details to further enhance the user experience on the interface.

Acknowledgment

Thank you very much to Bruno Caregnatto, who assisted me in this project, and together we had valuable exchanges that resulted in a lot of learning. I also want to thank the leaders Renan Paz and Roger Câmara who made this project possible.

PT

EN

PT

EN