Should this component be part of the Design System?

Intro

Every team that builds a design system eventually runs into the same question: should this component be part of it or not? At first, the answer feels clear. Buttons, inputs, and checkboxes belong. But as the system grows, it becomes less obvious. What about a pricing table, or a sign-up form? Deciding where to stop can be harder than building the component itself.

The Problem

It can be tempting to put every piece of UI inside the design system. Having everything in one place sounds efficient. But if the system gets too big, it becomes harder to maintain, more confusing to use, and slower to update. On the other hand, if the system stays too small, teams end up rebuilding the same things in slightly different ways. Both extremes create problems.

Criteria 1: Reusability

The first thing to ask is whether the component will be used in more than one place. Buttons and inputs are used everywhere, so they belong in the system. A one-off marketing banner does not. If a component will not be reused, it may not be worth adding.

Criteria 2: Frequency of Use

Some components may not be reused across many products, but they are still important because users see them often. A modal or a navigation bar is a good example. Even if they only appear in a few areas, they play a big role in the user experience. In those cases, it makes sense to include them.

Criteria 3: Brand Consistency

Some parts of a system are less about reuse and more about brand identity. A custom illustration style or a special call-to-action may not appear everywhere, but they carry the company’s voice. The design system should set the rules for these elements so they stay consistent.

Criteria 4: Maintenance Cost

Every new component adds long-term work. It needs documentation, accessibility checks, testing, versioning, and updates. The more complex the component, the more costly it is to maintain. Sometimes it is better for a product team to own a special component instead of putting it into the central system too early.

The Balancing Act

A strong design system grows carefully. Add too much and it becomes cluttered. Add too little and it fails to help. The best systems are clear about what belongs and what does not, and they adjust as the company matures.

My personal take

There is no single answer that works for every company. What belongs in a design system depends on the project, the team setup, and how ownership and governance are defined.

I experienced this challenge with product listing pages. In Europe, the view was often that all listing pages should look the same across countries. But in China and Japan, the conversation was very different. The “internet UI language” in those regions has little to do with what we use in Europe, and product owners there had completely different expectations for how a listing page should look, as I learned while working at Softonic, and a pattern that I continued seeing throughout my professional career.

Also, different holidays, seasonal events, and even one-time promotions often demanded custom layouts or styles that would never appear in a traditional design system. More on that later.
Edit: On Design Systems and customization

For me, this is the real takeaway: deciding what belongs in the design system is not just about reuse or efficiency. It is also about context, team ownership, and respecting the needs of different markets. This is not a decision for one designer alone. It should be part of the cultural mindset in your company.