What is a design system?

It depends on how we look at it. There is a lot of innovation in design systems at the moment, which is why there is so much talk about it. There are many reasons why this is happening. Just to name a few:

• Developers don't want to repeat the same work on different media.
• Companies want to be more efficient.
• Product owners and product designers want the products they work on to be faster, more accessible and still look consistent.

These are all real problems that we face every day and have driven us to develop new technologies, new ways of working and new ways to better manage and scale design.

These are just some of the reasons why companies are investing so much more in design systems. However, as it is a new term, its meaning and process is still unclear, vague and inconsistent. This is why we see debate, buzz and the occasional good old meme.

As far as I know, there is no formal definition of what a design system is. I think because the problems it solves (especially in the digital product space) have only recently emerged. To explain I will give a real world example.

We have a number of products that all have separate code bases and more or less separate teams/owners:

• Main platform
• Prototype viewer
• Design tools
• Mobile apps (iOS / Android)
• Mac apps (sketch plugin)

We also develop and support some static sites:

• Marketing website
• WordPress Blog
• A number of isolated back-end templates

We also send HTML emails on a daily basis:

• Some of them are automated
• Some of them need to be specially created

We also have different teams working together on a daily basis

• Product
• Frontend
• Back-end
• Marketing
• Sales

With all these different platforms, channels, teams and processes, there are a number of challenges. For example:

• How do we make design accessible to all teams?
• How do we ensure that each team uses the same technologies, elements and patterns
• How do we ship new features for each product without repeating the same work over and over again? Or in other words, how do we stay efficient?
• How do we bring consistency to all of this?

I have briefly mentioned some of the problems we faced before we developed design systems. So the benefits are to find solutions to the problems I mentioned, e.g. developing consistent and accessible software across different media, reusing and maintaining code and design in a more efficient way. And, of course, improving cross-team collaboration.

It is a challenge to develop a design system that scales well as the team grows. Especially when the products grow in scope and complexity at the same time. It takes a lot of time and effort and there always seem to be hurdles.

What we have realized in the last two years is that it can be very helpful to treat the design system as a separate product. It needs its own requirements, its own features, a solid roadmap and clear prioritization.

For example, our pattern libraries are not something we built and then left to their own devices. They evolve every day because there is an ever-growing backlog of feature requests (internal only). Managing all these things while making sure the products stay consistent, don't break or look seltsam proved to be the hardest part. At the end of the day, it's a mix of design and software, so it needs to be handled in the same way.

Other things we realized were critical to the process, especially when time and resources are tight:

• Detailed documentation
• Regular testing
• User research
• Testing

Lastly, it may sound very obvious, but we've noticed that anything new that is complicated (a UI kit or pattern library or even a design process) is slow to be adopted - unless it's religiously enforced.

If it takes effort to learn and time to get used to, people get confused and ignore it. The reason is that everyone wants to get their work done quickly, which means he/she is more likely not to invest time in something new that will slow them down in the short term. It's just hard to see the long-term efficiency gains. Any deviation from the regular workflow will take some time to make adjustments. Therefore, it is also a challenge to ensure that the solutions are simple, understandable and straightforward.

Another question we don't have a concrete answer to, as every project is different. The first thing we do is an audit of the existing brand, products and user interfaces.

When we start creating a style guide, Page may already have been around for two years. It's an established product that already has a good, consistent design that people loved and enjoyed using. However, it may come to a point where important features are introduced and it becomes a platform rather than a single product, so the need for consistency becomes more important.

We then perform an audit of the existing code base and identify some issues, for example:

• Identical components were implemented inconsistently.
• Colors were not properly balanced.
• Transitions were set seemingly at random.
• There were too many different font sizes.
• We counted many slightly different shades of the same gray.
• Many CSS files were either duplicated or not used.

From there, you decide on technology and the approach to solve the following problems:

1. Create a framework to standardize all design values
2. Create a pattern library to make existing user interfaces consistent
3. Establish clear guidelines and rules for use

We don't think it's one specific thing and would say that it definitely comes down to execution. But we think these points are crucial to a good design system:

• Good, concise documentation
• Rules and guidelines that are easy to understand
• Clear rationale for why certain decisions were made (A good example of this is Bulb's design system, which provides insights under each component and context for why certain decisions were made - mostly supported by user research)

if it overcompensates and clogs up colleagues' workflows with unnecessary processes, it's not a good solution. In fact, it wouldn't be a solution at all.

It is enough to have a pattern library without calling it a design system. You can use a simple UI kit. Or a set of design variables when building a simple website. If it helps you build faster, then it does the job. It doesn't always have to be a system.

You can design and style everything on the go. Like when you create marketing websites. Or products with a lifespan as part of marketing campaigns. It doesn't matter what and how you use as long as you are productive, efficient and get the job done.