Your Component Library Isn’t a Design System (But it Could Be)

Let’s explore the differences between a component library and a design system and how you can leverage them.

If you haven’t worked with a design system—or a component library—before, the terms can be a little hazy. What’s the difference between them? The short answer is that a component library is just one part of a larger design system.

It is possible for component libraries to stand alone without integration into a design system, or for design systems to exist without a component library. However, most of the time a full-featured design system will include a component library.

Let’s take a closer look at what each of these terms means and what they typically include.

Component Library

A component library is a collection of reusable, modular components that developers can use to speed up the creation of user interfaces. They include everything from simple components (like buttons, dropdowns and checkboxes) to really complex ones (like data grids, spreadsheets and data visualizations).

Component libraries can be built in-house, but most of the time it’s more efficient to leverage a preexisting one (like Progress Kendo UI). When developers use a component library, they can spend less time building components from scratch and more time combining them into unique and useful applications.

Using a component library is especially helpful for creating consistent interfaces—and consistent code! When a team of developers is dividing up the work, sometimes two developers might build the same element (like a button) in slightly different ways when working on different features in the app. Over time, this creates an interface full of components that all work a little bit differently, both for the user and the developer. This makes the UI hard for users to learn, and the code challenging for developers to scale and maintain.

In general, it’s better for everyone if the same component is reused across the entire application; by collecting the commonly reused components all in one place and documenting how they should be used, component libraries make that goal much easier to achieve.

A component library is primarily used by developers, but designers will often reference it as well during the early stages of feature ideation and design. When designers know what components the developers will be using to build out their designs, they can get aligned early in the process. This lowers the amount of iteration (and frustration) during the handoff phase. Think of it like knowing which Legos you have available in your kit. Once you understand what you have, you can start to think about how to use the pieces in different ways to build what you want!

Design System

A design system is intended to be much broader—a collection of interconnected visual elements, organized and documented for easy reference. You can think of it as a library of all the design resources and assets you could ever need, customized specifically for your application. As you might guess, that can (but doesn’t have to) include components. Some of the most common elements that you’ll find in a design system include (but aren’t limited to) design tokens, grid systems, icons, components, style guides and brand language or tone-of-voice guides.

Much like component libraries, you can build a design system in-house or leverage one that already exists (like Material or Fluent). Which option is the right fit often depends on company size and design vision. For small companies without many resources who aren’t particularly focused on creating a unique look and feel, a preexisting design system can save a LOT of time and effort.

However, for a larger company—especially one with a dedicated design team that either needs to coordinate among many different departments or is highly invested in a custom brand—the upfront investment of creating an in-house design system will pay off in spades.

Design systems are also hugely useful because they make sure that everyone is speaking the same language. Have you ever been in a situation where two people thought they were disagreeing on something, only to discover they were actually describing the same thing the whole time—just with different words?! Maybe one was calling it a “toast notification” and the other was calling it a “snackbar”? Or maybe your idea of “sky blue” was different than what your designer envisioned? When you’re using multiple different libraries, frameworks or languages, it can be incredibly easy to get wires crossed; design systems can help uncross them.

Unlike component libraries, design systems are referenced widely by lots of different people across different teams and departments: designers (of course), but also developers, product managers, copywriters, social media managers and more. Honestly—pretty much everyone benefits from having access to the design system.

Which Does Your Team Need?

If you don’t have anything right now and are trying to figure out where to start, my recommendation is to begin with a premade component library. By beginning with a collection of prebuilt resources, you can start seeing those consistency and design benefits without having to invest a lot of time in setup to get things up and running.

If that’s working well, then you can start thinking about expansion. Maybe you want to start customizing the look and feel of those components, or documenting specific ways you want to use those components within the scope of your app. Maybe you can look at your CSS color variables (or Figma design tokens) and turn those into more formal brand guidelines. Maybe you mostly use a preexisting icon library, but you had to create a couple of custom ones—so you create a repo where they can all live in one place.

Before you know it, your component library is growing into a design system. In fact, we even offer a Design System Kit to help you intentionally expand Kendo UI components into a full custom design system!

Of course, it’s also possible to sit down with intention and create a design system completely from scratch. If you’ve got a team of talented designers at your company, that’s probably even the best way to do it—the ideal.

However, realistically, a lot of folks aren’t working with the ideal, and I think it’s good to remember that it’s also OK for design systems to grow organically. Start with what you’re using now, get it all collected in one place and document how you use it. As you add new components, colors, UI patterns, fonts—or anything else—add it to your collection. That’s a design system, too!

You wouldn’t write the same function over and over again in your code; you’d export it once, so you could import and call it wherever you needed it. Component libraries and design systems are exactly the same—component libraries help you standardize and reuse UI components, and design systems help you standardize and reuse visual assets. They’re two great tools that are even better when they’re combined and used together!