Why component naming matters more once the library grows

Before I started working more deeply with design systems, a lot of UI decisions happened at a screen level. I would think about what spacing worked best, how a card should behave, whether a new button style was needed, or what should happen when the content became longer than I expected.

Those are all normal design questions, but working within a design system changed the way I approach them. Instead of starting with “what works best here?”, I now tend to ask whether the product has already made that decision somewhere else.

If the answer already exists in the system, I need a good reason to introduce something new. At first that can sound restrictive, but I’ve found it actually removes a lot of unnecessary decision-making. I’m not spending time choosing between several almost identical spacing options or creating a new component variation just because it fits one screen slightly better.
This decision gives me more space to think about the parts of the experience that actually need attention, like the flow, hierarchy and what the user is trying to do.

The interesting part is when the system stops working the way you initially planned. If I keep having to work around the same component, or the same exception keeps appearing in different flows, I’ve learned to treat that as useful information rather than just an inconvenience. It might mean the component needs to be more flexible, that we missed a use case, or that the problem shouldn’t be solved at UI level in the first place.

That’s probably been the biggest shift for me. I don’t really see a design system as a library of components anymore. I see it as a record of decisions the product has already made, with enough flexibility to change when those decisions stop making sense.

良いデザインシステムは、ルールを守るためだけのものではないと思います。