## Design Systems and Legacy Products

Implementing a Design System is not an action, but a process. Especially when considering legacy products, where the technology used is old.

In GitLab’s case, they want to update their technologic stack but, at the same time, build a consistent Design System based on that technology.

Companies cannot simply build a Design System on top of the current interface — they need a plan that involves development and design.

“We want to have our house in order before building a castle”

– Pedro Moreira da Silva, Senior Designer at GitLab

### How companies are doing it

💡Start with the basics

Going for the big and daunting tasks can prove itself a mistake later. The companies we visited started with the basics such as typography and colors, moving on later to discover other inconsistencies in their interfaces.

These discoveries are the result of interface audits. In audits, every component is investigated and filed for review. It is important to understand the reason for such inconsistency and work on guidelines that will help avoid repetition.

💡Developers and designers must be hand-in-hand

The code needs refactoring and updates. Design needs consistency. To foster this evolution, developers and designers can save time by aligning themselves during the adoption phase. Developing with a new technology and a Design System should be in sync.

It can be done as a Boom, where teams redesign and code the whole system in one go. Time is invested upfront to launch the system as a whole. Or it can be done as an Incremental process, adopting the basics (such as colors) and moving to more complex parts of components.

It becomes essential to have the process planned by Product Managers/Owners. These people will define the roadmap for the Design System across the product and enhance the communication between developers and designers.

💡Building a live Design System

As companies move from old technologies to more popular and supported stacks, they want to update their Design System in the same measure. GitLab, for example, is working on a Design System that will be updated in real-time with their product.

“We don’t want screen shots, we will only have the live code so everything is in sync.”

– Pedro Moreira da Silva, Senior UX Designer at GitLab

Therefore, every component of the Design System exists in the product. The rule of “the component only goes into the Design System if it’s coded” supported by GitLab helps keep the library documentation up-to-date and avoid legacy-product-problems in the future.

## Getting everyone on board

It is definitely one of the biggest companies face. The bigger the company, the harder it gets to scale a Design System to all the teams.

“Getting everyone on board is a fight. It is very hard.”

– Nuno Amorim, Visual Designer at XING

### How companies are doing it

💡 Invite everyone to the party

There is no use in a Design System that doesn’t solve the team’s needs. If it fails, teams will not use it.

“People need to work on the system to understand it. It needs to grow in the real world.”

– Bruno Silva, Lead Designer and Founder at Unbabel

A system cannot simply be imposed. It is important for teams to work on it from the very beginning. They need to express their problems and feel ownership of their .

💡Single Source of Truth

Companies must work on making their Design System accessible for teams. GitLab is a great example of that — they keep an updated handbook on how they run the company and they update their Design System in a public way.

A Single Source of Truth (SSOT) like that allows the whole company to access changes and updates. On top of that, it creates a common language between stakeholders, contributing to better communication.

💡Peer-to-peer reviews

A peer-to-peer review system can help get teams on board the Design System. By reviewing their colleagues’ work, teams increase their Design System awareness. It helps designers understand if the Design System can scale to their needs or if it needs improvement.

Some companies have special teams focused on reviewing work. In these cases, a single source of truth — such as GitLab’s Design System — becomes essential to help these teams. Yet, that same source of knowledge must continue to be public to the whole company. Its main goal is to educate everyone about how design should evolve inside the company.


For every action, a reaction. For every update, a notification. Design Systems are not a static tool, but a living organism inside companies. The increased need for updates requires a bigger effort to get everyone on board to know what’s new.

Companies must strive to create a system that informs stakeholders of changes to the Design System. That system can be in the form of video calls, blog posts, channel announcements or a changelog every time there is a change. The goal is to keep everyone on the same page.

Wrap up

Despite the trend in the design community, Design Systems are not a simple choice. Companies are facing many challenges while implementing their own system. These challenges are tied with the scale of the company, the team and the product itself.

Like a living organism, the Design System evolves as an integral part of the company. It adapts to the ever-changing, fast development cycles of product development and scales efficiently if built with care. It becomes of huge importance for companies to weigh and challenges, to understand the return on investment of implementing their own Design System.


Source link


Please enter your comment!
Please enter your name here