Sweep with a broom. Refactor the design system to make layouts painless
Hi! My name is Denis, I am a product designer at X5 Tech. Over the past few months, my colleagues and I have been tidying up, refactoring, cleaning up and polishing the design system of X5's internal back office for the employee's personal account. I will tell you what pitfalls we encountered, what to prepare for and why refactoring in design is necessary at all.
A design system is an incredibly important and useful thing. Not just a UI Kit and a color palette – now it’s a whole set of artifacts, components, and rules for comfortable product design.
A well-established design system is a great tool for comfortable work. But sometimes the opposite happens: something went wrong, something was not monitored somewhere. And now your system, designed to restore order and make everyone happy, itself is overgrown with weeds and falls apart.
What is the product, what is happening and where are we
We do the design and all that stuff.
A personal account for employees of a large company is always an interesting project. Legacy, old and new services, a monolith cut into microservices, a diverse user experience. An explosive mixture of back office and operating system, B2B and B2C.
Some time ago, X5 scaled the Pyaterochka personal account to other business units. It was possible to replicate the working solution to different structures of the company (from Perekrestok to the X5 office), save the budget and resources, achieve unified processes and consistency, and do without a zoo of various products.
Ideally, all corporate red tape, internal process design, and company-employee relationships should be handled using an effective design system. Closest analogues:
Open system Public services from the G2C side → applications, certificates, document flow, employee needs.
Designing Business Processes in Initiatives Contours → commercial products, working with business requirements, unique services.
From the design side, the personal account has turned into a marketplace with a bunch of services for different users. An office employee has his own set (pay slips, applications, vacations), the store director has a completely different one (employee work schedule, internal statistics), but everyone is under one roof.
And a solid, convenient design system is critically necessary for maintaining uniformity in layouts and on the front end, supporting various functionality, problem-free review and fast synchronization.
Why did you decide to refactor?
The time has come.
The contractor's team was in charge of the Pyaterochka personal account and its distribution to other X5 business units, being fully responsible for the technical part. For the distribution, they chose the fastest and most straightforward way: repaint the main elements on the front without design and research. Interfaces, layouts, components remained from Pyaterochka.
The business task of scaling was successfully solved. Now the user had the same personal account as Pyaterochka, but with a logo, colors and colored elements according to the brand book of the business unit in which he works.
The contractor quickly added new services and customized the functionality for different roles. But in everyday work, the following appeared:
a bunch of unassembled legacy and design debt from the old office;
significant discrepancies between development and design;
lack of clear rules for designing interfaces for new business units;
a long and expensive stage of additional checking of finished layouts.
A large number of disparate services gathered in one place, vast mountains of legacy, non-standard solutions outside of common patterns – all this was destroying the system from within and interfering with work. At this point we appear and dive headlong into the problem.
The components and libraries were rapidly becoming more and more disorganized. There was not enough time and resources for a systematic approach and uniformity in layouts, the budget was allocated strictly for release tasks, and the already heavy design debt was growing.
As a result, without attention and care, a design system stops working. Components become obsolete, rules are not updated, processes fall apart and decline. Why is this icon the wrong size? Where did this shade of green come from? Where did the notification component go, I was just there?!
First of all, it affects the deadlines. A simple task for several layouts turns into an endless reassembly of the same elements. Again, for each standard solution, crutches are invented, because the design system does not have it, or it does, but we could not find it.
The designer's productivity and the value of his work are falling sharply. Not only do you have to allocate more time to the task (and it should be the other way around), but the design system, which is supposed to facilitate and speed up the processes, has turned into a pumpkin and an obscure legacy (and it should be vice versa).
The unkemptness of the system forces one to return to the classic approach of “it's faster for me to assemble and draw it on my knee” than to try to get used to an inconvenient tool. I say this without any judgment: a person consciously and/or unconsciously reaches for what is convenient and avoids discomfort.
Does a design system need refactoring? How do you know if current solutions aren't working? In our case, diving into processes, analyzing and diagnosing problems revealed the following:
The contractor's involvement in the product decreased and the ownerless design system stopped working on its own without constant support.
The control of the design ambassador, a specialist who is fully responsible for the operation of the design system on a permanent basis, has been reduced.
The product interacts with both employees within the company and with external specialists (freelance/outsourced/outstaff) without a clear division of roles.
The single entry point to design processes has been lost. Without competent onboarding and expertise gathered in one place, each designer is assembling his own bicycle.
Ready-made layouts for current tasks become outdated within a couple of months and require complete reassembly.
What to do? Call the design fire brigade, allocate resources for refactoring, and start spring cleaning.
There is another good business rationale for refactoring a design system. An employee's personal account is needed in many places, and almost every business unit, structure, department, and division requires its own service for organizing work processes.
A clean, refactored system can be easily scaled to any other product, providing a single, seamless experience for employees. This is unlikely to be possible with a “dirty” design system.
How we cleaned and brought to life the design system
Just like that, just like that, one-two and it's done.
Design processes often lack structure and organization. They lack their own style guide, like PEP8 in python or SQL guidelinesAt X5, we get a lot of help from design frameworks, but sometimes even they are not enough.
Refactoring a design system is a thorough and systematic process, and you can’t do without clear rules and standards. Therefore, the general principle is as follows: we adopt methods from frameworks within the company and mix them with the best industry practices.
We manually vacuum cluttered components, archive outdated files, update documentation, show changes to the team, collect feedback. And Figma itself is in love with clean, organized layouts:
We have brought order to the naming of layers and the overall structure → Multi-edit The functions started working faster and the names of elements almost stopped confusing.
Got rid of groups in favor of Auto-Layout, set up modes «Fixed width», “Hug to content”, “Fill container” for elements → We received normally stretchable adaptive layouts as a bonus.
We assembled mockups based on the principles of html/css layout → We made work easier for front-end developers, and Figma revealed amazing possibilities in prototyping mode.
Added descriptions and necessary notes in Dev Mode → Made the work even easier for frontends and said “Thank you” to ourselves when preparing documentation for the release.
The same Kontur has excellent ones guideshow to keep your layouts clean and when to stop.
Branches
Using branches helped us tame the chaos of a bunch of unnecessary sandboxes, save the master file from becoming a dump, and also see who is responsible for rebuilt components.
Branches really save Figma from clutter. Branches still have limited functionality and their own peculiarities. For example, you can't merge a branch into a branch, public links to individual branches don't work well, and updates in the master aren't always correctly uploaded to the branch.
But to protect layouts from garbage, get rid of a dozen archive files, assign a designer to a new task using branches – that’s it.
Variables
One of the most significant updates is that we have moved the design system to Variables. Without tokens, there is no point in either creating a new system or refactoring the current one. Everything that can be driven into parameters (typography, colors, rounding, indents, CSS) is written into tokens and becomes a single entry point for designers.
Tokens helped to completely rework the palette taking into account the differences between X5 retail chains and business units. Finally, it was possible to solve a big problem with the layout of unified layouts according to different brand books, when one personal account service needs to be included in both the Perekrestok guidelines and the Pyaterochka brand, and also follow the rules of the design system itself.
Even in its current state, the token library already allows us to significantly speed up design processes. Figma supports switching between different modes for the same variables: it is now much easier to assemble and adapt interfaces for business units. The personal account for Pyaterochka instantly switches to the personal account for the X5 office.
Documentation
We started to put the documentation in order and describe how everything works in the system. The main principle: the texts should be understandable to everyone. First, we get rid of officialese and corporate language. Second, we decided to divide all the guidelines into two groups of artifacts:
Usability documentation. Design rules and techniques → behavior of elements, user experience, interaction, support.
System documentation. Technical memos for development and design → indents, CSS, tokens, layout features, individual details on frameworks.
Guidelines, tokens, branches, clean components, rebuilt layouts, your own evangelist in the design system – a basic list of updated and refactored things.
What happened?
We built and built and finally built it.
We've done a lot of work. Now we have the opportunity to formalize the rules for passing design reviews. Before this, mockups for tasks were submitted for review, and each case was considered separately, manually comparing what was in the task and in the disorganized design system. This approach took up a lot of time at the stage between design and development.
After refactoring, we can put together a clear algorithm of actions, how and what should be assembled: efficiently, quickly, following the rules. It has become easier to fit non-standard solutions and unique situations into general processes – something that was missing before the update. Interim results after several months:
cleared the backlog of current tasks and design debt;
freed up designer resources for new products;
significantly simplified the design review process;
With clean components and updated rules, layouts build faster;
The design system can scale and adapt to new conditions.
Next steps
Refactoring is done. Long live new refactoring!
We continue to update and refine the design system in a calmer, background mode. Refactoring does not affect work tasks and occurs in parallel with the main processes. Interaction with the product becomes more obvious and constant.
Now we can connect third-party designers to the product without long and painful implementation. Before, a specialist had to monotonously review the old system, outdated guides, compare with relatively fresh layouts and development, and only then dive into new tasks.
The plans include refining the standards and polishing the documentation: dividing it into usability and system parts, tidying up the texts and, together with a technical writer, simplifying complex formulations.
Almost everything is ready for deeper synchronization with the frontend. Inconsistencies between design and code have not yet become critical, but require attention. Unified tokens and JSON/TS/CSS manifests should cope with this. Let's take it into service practices VK and we will rework it for ourselves.
We will prepare a separate comprehensive onboarding for new designers, managers and customers to lower the entry threshold. We will add universal support for identity and brand books for different business units (Pyaterochka, Perekrestok, Chizhik, Mnogo Lososya).
X5 is a huge company with a wide variety of design processes. This article only touches on a small part of them, the best part is in corporate blog. For example:
Have an easy design!
