Discovering the World of Design Systems

A year ago, if someone had asked me what a design system was, I probably would not have had an answer.

Everything started when I decided to revive an internal frontend framework that had been sitting unmaintained for around six years. My original goal was simple. I wanted to modernize it and make it useful again.

As discussions with another frontend team progressed, they became interested in contributing to the project as well. To keep the responsibilities clear, we divided the scope. My team would focus on building reusable UI components, while the other team would handle charts and data visualization.

At that point, I still had no idea that what we were building was essentially a design system.

It was only after someone from the other team casually referred to the project as "design system" that I searched the term online. That simple search opened a completely new world for me.

I discovered that almost every major technology company has its own design system. There were mature systems like Material Design, Polaris, Carbon, and many others. The more I explored them, the more fascinated I became.

For me, a design system is where design and software engineering meet. It is the intersection between visual design, user experience, accessibility, architecture, and code implementation.

As someone who genuinely enjoys designing interfaces, writing code, and architecting software, I immediately felt that this was the kind of work I wanted to dive deeper into.

Of course, learning about design systems also meant discovering concepts I had never encountered before.

Two of the biggest surprises for me were MCP servers and DTCG.

Initially, I thought storing component documentation inside an embedded vector database for Retrieval Augmented Generation (RAG) would be enough for AI assistants. After learning more, I realized that RAG has an important limitation. It is only a snapshot of the knowledge at the time it was indexed.

If a component changes tomorrow, the vector database will not automatically know about that change.

An MCP server approaches the problem differently. Instead of relying on a snapshot, it allows an AI model to retrieve the current specification directly from the design system. That means the AI can work with live information instead of potentially outdated documentation.

I also found the Design Tokens Community Group (DTCG) specification fascinating. Before learning about it, I thought design tokens were simply a collection of CSS variables. I did not even know that design tokens are commonly managed as structured JSON files, making them much easier to organize, maintain, and share across different platforms and tools.

The DTCG specification introduces a standardized format that makes design tokens easier to exchange between design and development tools. It also helps automated systems, including MCP servers, retrieve and understand design tokens more accurately.

The more I learn, the more I realize how much there is still to explore. Design systems are much more than component libraries. They involve accessibility, documentation, tooling, AI integration, design workflows, developer experience, and many other disciplines that all come together.

Looking back, it is funny that I accidentally started building a design system before I even knew the term existed.

Now, it has become one of the most exciting areas of frontend engineering for me.

There are still countless topics waiting for me to explore, and I am excited to continue learning. I have a feeling this journey is only just beginning.