At one point in my career, I was leading a design systems migration with a small team.

There were three of us.

We were learning a new design tool.

We had to rebuild our entire component library.

If we set it up the wrong way, we would create more work for ourselves later. So I did what I usually do when I feel that pressure.

I studied.

I read articles.

I watched tutorials.

I looked at how other teams structured their systems.

One term kept coming up:

Master components.

The concept was simple. You create one main component. All other versions inherit from it. If you update the master, everything updates with it. It saves time. It keeps things consistent. It makes the system easier to maintain.

It made sense.

I brought that knowledge back to my team. We aligned on the structure. We built workflows around it. Soon, everything was running smoothly.

From a technical standpoint, it was a success.

But over time, something else became clear.

Around that same period, I was listening to Nas talk about artists owning their “masters” in the music industry. He paused and said something that stuck with me:

“The name ‘Masters’ is even… yikes. You know what I’m saying? There’s a psychological thing there that’s underneath it all.”

That comment made me think.

I realized I had been using the term “master” without ever questioning it. I had repeated it. I had taught it. I had built it into our system.

It felt normal.

But that is how language works. The more we repeat something, the more invisible it becomes.

I started researching.

In engineering and computing, the terms “master” and “slave” had been used for decades to describe systems where one process controls another. Over time, many people began questioning that language.

As conversations about inclusion and equity became more common, companies started changing their naming conventions. “Master” became “main,” “primary,” or “base.” The shift was small, but it mattered.

Language evolves.

And so should we.

I reviewed our design system and looked for alternatives. I saw that many teams were using the word Base instead.

It described the same idea. A foundational component that others inherit from.

Without the historical baggage.

So I made the change.

At our next meeting, I explained why. I owned the oversight and shared my reasoning. The team understood. There was no pushback.

I share this story because growth takes time.

When we learn new tools and best practices, we often adopt the language that comes with them. We focus on speed, structure, and efficiency. But words are part of the system too.

Design is not just about visuals.

It is also about values.

Something that felt acceptable years ago may not feel acceptable today. That is not weakness. That is progress.

As designers, especially those who care about inclusive design, we should be willing to pause and question the language we use.

Small changes can reflect bigger values.

We do not just design components.

We shape systems.

And systems should evolve over time.