In React, design systems and component libraries are common utilities one would use to standardize and simplify the implementation of their application. Different systems and libraries have different specialties, community and maturity.

Author's Note: This article will consist mostly of React-based modules but the criteria themselves works with any environment.

Design System vs Component Library

What are these two exactly? Simply put, component libraries, are modules which contain prefabbed components that can be used in an application. The components in these modules can be customizable via some sort of theme that will affect the components in that module.

Design systems could include a component library but the main difference is a design system adds context on top of those components. This means, the system provides rules on how to use these components. A system might also explain what tone should be used in messaging.

Garden, for example, has not only voice and tone described in their system but also expected grammar, punctuation, and which words are to be used.

Value

What value do these modules add to the application? The biggest value one of these modules provide is the standardization of components and rules. Communication between engineering and design will be streamlined because both parties will be talking the same language.

Productivity will also increase as basic components like buttons or alerts don't need to be reimplemented. This goes with design as well. A good module will have a design/ui kit that designers can modify to fit the product/brand without the need to remake the components.

Criteria

With all the choices out there, how does one choose what's best for the application?

There are standard requirements one will need to consider and compare against different modules.

Author's Note: The criteria listed are my personal opinion, and should be modified to fit your needs.

1. Licensing

Be warned. Just because the module is in Github, it doesn't mean the module is free to use. Always make sure the module has permissive licensing or the module will be used in a manner that will not break the license.

Example:

Polaris, by Shopify, may be available in Github but it's only allowed to be used inside of software that integrate or interoperate with Shopify software. Shopify needs approve the application if it's standalone.

Read the full license here.

2. Design/UI Kit

Design/UI kits might not impact engineering directly but it's an important part of a design system/component library. These kits are used by design to create mocks of upcoming updates to the application. Having a robust kit makes design's life much easier. It will also make it faster.

Sadly, not all modules have kits. Some have community-made kits like Mantine's. This doesn't guarantee the kit is complete or up-to-date as it needs to depend on the community to keep it up. Best case scenario is the module provides an official kit -- see MUI.

Another aspect of the kit to consider is where it's built. Usually, one design tool is used within a company. The most common ones are Figma, Sketch and Adobe XD. It's important to make sure the module provides a kit built in the tool used by design.

3. Customizability

Customizability is an important aspect of good module. That's the whole point of a using a design system or component library. A module is only as good as its ability to be customized since these are usually made with a certain purpose in mind or design that doesn't fit the product.

Design systems or component libraries usually work using design tokens. This makes it simple to theme the module.

There are many ways one can modify the themes and the way the module modifies the theme must match the expected architecture of the application. MUI, for example, uses CSS-In-JS for its method of styling. Ant Design, on the other hand, uses LESS for its styling.

4. Components

Components that exist within the module, like customization, should fit the need of the application. It's important to know or estimate which components are needed for the application. Obviously, there would be common ones like button, select, or some variation of card. Some modules expand on these common components and have things like stepper, and even tree.

It's important to have an idea of what components are needed for the application as it will reduce the need to reimplement something that already exists in the right module.

5. Accessibility

Accessibility is an integral part of being a modern application for an international audience but it's a lot of work to be accessible. Luckily, many of these design system and component libraries are made with accessibility in mind.

This is generally a problem with older modules but it's such an important requirement it deserved a point as a criteria.

6. Community

Having a strong community behind a design system or component library determines not only the longevity of the module but also the amount of support one would receive.

Community doesn't stop at being able to get support. Having an active repository with issues and pull requests being commented on, resolved or closed is also an important part of being active.

Author's Note: I've made a small query that can be modified to check Stack Overflow statistics regarding Tags -- view results

7. Other Considerations

1. Typescript Compatible
2. Handles RTL
3. Handles Localization

Design System OR Component Library

Picking on or the other, again, is determined by what the application needs. Picking a design system usually comes with rules about how to use tone or the component. If that's not necessary for the application or there are already rules established, a design system can still be selected but not use the rules portion of it.

Component libraries can also be picked in conjunction with a the rules of a design system. For example, "Company X will use Mantine as their design system and follow the rules of Adobe Spectrum."

Next Steps

With this knowledge in tow, picking the right design system or component library shouldn't be as daunting as before. Biases for a certain module will always exist; but it's important to be open minded, and select what makes sense for the application, design, and company goal.

References

https://www.architech.ca/a-design-system-so-much-more-than-a-component-library/#:~:text=%E2%80%9CA%20component%20library%20is%20just,single%2Dsource%20of%20truth.%E2%80%9D

https://medium.com/adevinta-spain-design/whats-the-value-of-a-design-system-19e47752f003