Moneyveo – the leading fintech company in online microloans on Ukrainian market. There are 2 web platforms and 2 mobile applications in the product. I am responsible for the design system and web platforms. The design system was created for the Ukrainian product Moneyveo - the market leader in the field of microfinance.
Upon joining the company, I offered to develop a system design. I developed and implemented its use. Initiated major updates to speed up tasks. I developed and supported the design system, described rules and processes, and implemented new technologies.
Objective: develop a design system
During the development of the DS, it was taken into account that the product would be actively scaled to foreign markets, both with a mobile application and with the web. To spend a minimum of time maintaining the work of DS, it was developed in a separate file from the layouts of the main product.
The first iteration of the DS was created a couple of weeks after work began. By current standards, the system was primitive. There were no options and auto layouts. To use different options for buttons, they were placed on separate frames, and their names were written with a slash.
It was decided to delete a single external file and transfer the DS individually for each place inside the file. To do this, it was necessary to set colour styles, typography, and shadows from 0. Create new components, the same as they were. Rebuild all layouts for newly created components. This work was done in parallel with the main tasks, it took a couple of weeks to complete it.
The first tasks were set to create only one layout, covering the main functionality, as, for example, in the screenshot below, initially it was only about creating one layout and its adaptive.
I started asking questions about how the user gets to this page, what he sees before, what after, what are the alternatives. After such a workshop, I began to make User Flow with all possible transitions. Instead of 1 layout, as expected, 10 layouts were implemented in the task.
After that, the tool began to be used in each task, next to the layouts there was a detailed User Flow + individual system states.
The first tests were on drop-down lists. At that point in time, I was working on a registration funnel, where there were 13 drop-down lists, in which there were 7 options on average, and a maximum of 16. It took several evenings to fully study the functionality and all its subtleties.
The result exceeded all expectations. After implementing the drop-down list, I thought that it would be possible to use the functionality not only for one component, but for the entire block as a whole, and then for the entire layout. Realizing my discovery, I jumped and danced for joy :)
A similar problem followed us from the very beginning of building a design system. There were several approaches. The first attempts at optimisation were divided into pages separate by flow, for developers and our working files. Faced with the fact that in this way it would be necessary to support several versions + there was so much information on the artboard that we got lost in it.
The next attempt was to place information in large chunks of the user's path. Nevertheless, the flow turned out so much that over time, navigation for the designers themselves became more complicated, not to mention business, BA, devs or testers.
In January 2021, there was a complex project to implement the new requirements of the regulator. Speed and navigation have become more important than ever. I proposed a new file structure - to divide the entire site into 9 large blocks, they were understandable and contained all existing pages.
This idea solved the question of which page the layout should belong to, however, there was still no rule on how to place layouts on the artboard. To do this, I suggested placing layouts horizontally in large blocks that contained all the details on the desired page.
In each block, layouts related to one page, desktop and adaptive versions, additional page states, designer comments for developers, User Flow were placed vertically.
Our lead suggested using a small component next to each layout, which would contain links to our tasks in Jira and Bitrix.
The component began to be used next to each layout that we used. With the growth of the system and the emergence of new processes, the component grew and developed. To date, we use the component in short, there are not only links to tasks, but also links to translations, legal approval, a guide with a detailed description of the components on the page.
The first solution was to place a frame next to the layouts on which the text is duplicated and translation is added. Copywriters edit the text in the text frame, after which the designer transfers it to the layout. At that time, there was no Autolayouts functionality, so if you edit the text in the layout itself, it could happen that the text imperceptibly crawled out of the possible borders of the block.
Over time, we discovered that this approach has a big disadvantage - since we had 3 sites, and the text is always the same, at times when there were many edits, some of them were missed due to constant text wrapping.
In February 2021, with fellow designer Lena Artsimovich, we used Notion as a place where we can aggregate text and then distribute it to other sites.
We have created several columns, the first for the copywriter, the second for his manager and lawyers, without these statements the text cannot be posted on the site. At the UX stage, designers placed the approved text in layouts at different sites, after which they passed it on to the fronts.
Links to platforms were placed inside the card, in the table with platforms, places were marked where the text had already been replaced. In the table below, in the first column, there is text where the designer enters text from the layout. In the second and third columns, the text is agreed with the editors and lawyers. Words or paragraphs where the text has been changed were highlighted in orange.
Because of this decision, it takes a lot of time to work with texts, statements and hyphenations. However, due to security policy and working with multiple platforms at once, this is the best solution we came up with in the time allotted to solve the problem. It's not perfect, and we keep looking in the background for another solution, but we haven't come up with anything better yet.
I started using options with simple components, buttons, inputs, selects.
Having tasted the potential of the functionality, we began to apply it not only for individual components, but also for the functionality that was used throughout the site.
I've created large master components and marked it with ⚙ so it won't show up in searches️. I stuffed as much information into it as possible, after which I hid them in a regular component and got the state I needed. After 3 weeks with a colleague, we went through the entire design of the system and rebuilt it for the use of Variants.
Initially, DS was built on the atomic principle, we created the main styles, atoms, cells, organisms. Over time, there were so many components that they simply threw themselves somewhere for the duration of the work, and then remained there, since we did not know where to put them.
I started to study how the design systems of huge products is built, studied articles on sorting information, but did not come up with anything better than alphabetical sorting. The rule was simple as a result of which there are no questions about where to put what. Lena Artsymovych formed the visual template that we followed.
We added the status of the component so that we understand the degree of its readiness. The statuses were:
– Done
– In Progress
– Need update + comments on what needs to be updated.
We also added a link to external sources to show how the component works. Over time, more Navigation and Style columns were added.
We started adding more layout details to our User Flow, information about small interactions, tooltips, promotions, and the logic of how parts of the functionality work. Because of this, 3-4 screens turned into a complex system of intricate connections. When working with Credit State, I suggested splitting it into small pieces that described one logical component - the logic of transitions, all page states, the work of functional pieces.
I also began to add links to other parts of the functionality to get a product map and make it easier to find the right layout and comments for developers.
While working on the task of breadcrumbs, Lena had a need for a detailed specification of the rules for the operation of the functional. She designed a Guide template that displayed details.
After the template was approved, she also added a paragraph with a link to where this functionality is used, so that it is always easier to find it.
At some point in time, it became the normal for us to work with an error due to insufficient memory. Sometimes the project just crashed. We lost access to the history of the file, when loading any version, it immediately crashes.
I began to dig into the reason, read articles, forums, write in support. It turned out that the project in Figma is limited to 2GB of RAM, as soon as it fills up the file crashes. I tried to increase the size of the allocated memory through deep settings, it did not help.
After reading a couple of articles, I found that we have 750k layers in Figma, which is why the file takes a long time to load. During the week, I definitely cleaned and removed unnecessary, hidden words, unnecessary layouts and functionalities. This made it possible to reduce the number of layers by 2 times.
Based on the knowledge gained, I changed the approach to the structure of the components, instead of a large and complex component, where everything was stuffed, and then divided into small ones, I began to make many small ones of which I make up one large one. To switch states, I fall down a level and set the combination to small ones.