5 Tips for Adding Design System to Existing Products
Design System is a collection of guidelines, principles, UI components, and assets, that aim to improve several aspects of the application development workflow. Here are a few of them:
- Promote standard and consistent product UX
- Increase velocity and efficiency by reducing duplications and enabling code reuse
- Improve communication between Designers and Engineers
- Single source of truth for styles and design
Many companies are getting to know the benefits of having a design system and try to adopt it. It’s particularly compelling to mid-large organizations that work on multiple products with multiple teams.
There is no question that creating a design system can speed up the workflow of building a new product, but what about the organization’s existing products? What should be the process and effort of integrating a new design system into those products?
Our Integration Story
At Outbrain, that was exactly the case. We had several products and tools used by our customers, partners, and our internal users.
As we scaled, these products got larger and more complex, while other products and tools were created. The need for improving our workflow and infrastructure increased and a design system seemed like the right answer to some of our pains.
At the beginning of 2019, we started exploring the ways to build a design system and integrate it into our current products and workflows.
While building a design system introduces many challenges, we were pretty sure we could handle them. Design systems are very popular these days, and we could follow the many examples out there and use existing tools to build our own (Storybook and Styleguidist for example).
The challenge that we were more concerned about was how to integrate such a system into our main products.
Our main products were quite aligned visually. Our designers did a great work setting common styles and following our brand guidelines.
But when you took a closer look at the structure of our products, you could see a lot of differences. Components were not exactly the same and their UX was not consistent. In addition, each product had its own internal “mini design system” — A set of basic CSS rules, colors, and components used to construct the application.
Replacing all those components in a large application requires a huge effort of the owning team(s), which was almost impossible to prioritize given the tight schedule of new features and limited team resources.
It was clear to us that we can’t do it in one shot and that we need to come up with a gradual, structured process to reach the end goal.
What we’ve learned so far?
More than a year into this process, we can safely say we’re in the right direction and learned some lessons on the way.
Our main products are now based on our new design system which has grown to be large enough to provide many of the building blocks for creating applications in a standard, aligned workflow.
We learned a lot during this process, and here are our tips and guidelines to integrate a design system into your existing products:
1. Build it from the bottom up
Design System is like Lego blocks. Complex components are built from basic ones. You can’t build a Calendar component, for example, if you don’t have your basic building blocks — colors, buttons, typography, and other blocks, because that’s what a calendar is made of.
To integrate the design system into an existing product, we need to start with the most basic stuff — CSS reset rules, color palette, fonts, etc. Otherwise, we wouldn’t be able to get to the next step.
2. Build it step by step
Once we build one part of the design system, we don’t move to the next one before it is integrated into at least one product.
The reason for that is simple — We first wanted to get feedback and rejections and fix them. Every part needed to work well and add value to the product, and since we had limited resources for building the design system, we didn’t want to move forward before we made sure the previous piece was in place.
While gradual integration might sound trivial, it does means that during the process you’ll have a mix of your old components and styles with the new Design System elements living together on the same page.
We were lucky enough to have our Design system styles pretty similar to the existing UI/UX, so old and new components could be on the same page without making it look bad.
If this is not the case for you, meaning your old and new components are too different to live on the same page, then you’ll probably need to adjust the old components to look like the new design system components to avoid breaking your UX. Sure, it will require more work, but it‘s very important to find a way to make it a gradual process.
3. Engage Stakeholders
If you only take one recommendation from this post — this should be the one.
Things always work better when all stakeholders are engaged and involved. In this project, the relevant people were designers and developers, but also team leads and product owners.
One of our basic working assumptions was to get as many of the stakeholders involved as soon as possible.
Since designers are first-class citizens when it comes to a design system, we knew it wasn’t enough to have only some of them involved. If we want to achieve complete alignment, we need them all to be part of it from day one.
We also decided to get as many engineers as possible involved in building the design system. We could assign the task to an infrastructure team, or a specific task force, but we thought it would be much more engaging to build it as a “community” project. Telling a dev team “Here is a new design system, now throw away your current code and use this instead” is not an engaging way to do it. But if they contributed to the design system and were part of the community from early stages they will be more likely to want to adopt it and integrate it into their products.
Sure, it slowed down the process as it brought many opinions to the table, decisions took longer to make and we had to onboard everyone, but it also created the champions inside the teams that pushed the project forward simply because they felt part of it.
Showing the value to managers and product owners in the early stages was also an important part of the project’s success. It is critical because they are the ones that can prioritize the creation and integration tasks and provide the resource to push the design system forward.
4. Leverage Existing code
The good news for us was that building a design system when you already have existing products is much faster and easier than starting from scratch.
Like I wrote above, each product had its own “mini design system” consisting of patterns, principles, and components which are the building block of the application.
This allowed us to cherry-pick the best parts from our existing products and merge them into our design system without having to rebuild them. It also made the integration much easier for some of the products.
Of course, each part had to be reviewed by the designers and aligned to the system standards, but those were usually small changes requiring small effort compared to building it from scratch.
5. Assign Owner(s)
In every complex ongoing project, ownership plays a key role.
Without clear ownership, there will be no one that coordinates between all the stakeholders, no one to set priorities and timelines, and no one to drive the project to its goal.
Creating a design system is such a project. Especially when you have existing products that need to be adopted.
As mentioned above, our design system was built by our designers and engineers communities (we call them “guilds”), rather than by a specific team or task force. It doesn’t mean the project didn’t have a clear owner. On the contrary — When more people are involved, ownership and leadership become more important.
The owner’s role, in this regard, is to make sure all pieces are working together, and clear obstacles out of the way.
He also needs to take care of integrating the design system to existing products, which means coordinating with team leads and product managers, allocate the resources, set the timelines for the integration and make sure any issue that is raised during the integration gets fixed so it won’t clog the process.
Being the design system owner doesn’t have to be a full-time job (at least in our case it wasn’t), it can also be more than one person (a designer and an engineer can be a good combination). The main point is that it has to be clear to both stakeholders and the owners themselves.
Summary
No matter how you decide to build it, creating a Design System is an ongoing effort. Actually, it never ends. There will always be new components or modifications to work on.
When considering whether or not to start such a project, some questions and concerns will probably come up regarding your current products, such as:
- Should existing products adopt the new design system?
- How much effort will it take to integrate the Design System?
- Is it worth it?
In my point of view, if you’re planning to scale, in terms of product features or the number of products, the benefits of adding a design system to your workflow outweigh the cost.
Don’t be afraid to start. If you’re doing it gradually as we did, you can always start with small steps, like integrating only the color palette, or the typography, then talk to your teams to get their feedback about the value it adds to their workflow before moving on to the next step.
