Good component libraries have clearly defined goals. For example, Material UI offers "React components for faster and easier web development", Reakit helps "build accessible rich web apps with React", and Chakra UI "is a simple, modular and accessible component library that gives you the building blocks you need to build your React applications".

In a nutshell, good component libraries intend to:

• enable faster development

• improve UI consistency

• enforce best UI development practices, such as accessibility, performance, etc.

While these are admirable goals, they are not the only ones worth pursuing. So what differentiates a good component library from a great one? Great component libraries are:

• Intuitive & Inclusive. They provide a common language for multiple product stakeholders.

• Resilient. They are designed for change.

• Based on strong principles. They are in a strong alignment with organization's values and goals.

Intuitive and inclusive

Intuitive means familiar and to be so, component libraries can introduce new abstractions yet stay familiar. If a component library built for web developers in mind, it is a good idea to be based on web platform and take advantage of the existing knowledge. But building solely with developers in mind will make it less inclusive. Finding a right balance is tricky and oftentimes requires change.

Great component libraries can accommodate such changes, going beyond one target audience and serve as a common UI language for all stakeholders: designers, developers, product managers, etc.

Designed for change

Wrong abstractions are worse than no abstractions at all.

Component libraries are abstractions and this rule applies to them as well. But how to decide what's the right and what's a wrong abstraction?

Good abstractions are designed for change. With such abstractions it's easy to build upon. They don't fight you back every time the requirements change a little bit.

For example:

Although the answer to this question is "it depends", the second example is much harder to change in the future if requirements change. Let's say, we decide to add a new type of item (like a special case without a link) in the middle.

Being too flexible, though, can lead to less consistent UI and user experience and more work to create a feature.

Finding a right balance between flexibility and rigidity is something that requires a deep understanding and alignment on the organizational goals and cannot be achieved in a general way.

Strong principles

Principles help answering question at scale: instead of answering the same question over and over, a principle that answers a question can be established.

Atomic design is a good example that helps categorizing components based on some principles, SingEl principle used by Reakit library helps keep the implementation details consistent.

I follow a few of my own principles that I derived from building and maintaining component libraries and design systems for my customers.

Regardless of your organizations' principles, it’s important to document and enforce them. Even more important is to ensure everyone operates under those principles since it can avoid a lot of unnecessary discussions and confusion.

Conclusion

Good component libraries enable building user interfaces quickly and with less effort, they improve UI consistency, and enforce best practices.

Great component libraries go beyond that. They serve as a common UI language for all product stakeholders, are resilient and designed for change. Most importantly, they align with organizations’ values and goals and enforce them by having a set of strong principles.

Great component libraries are the ones that can be called design systems.

Huge thanks to Mae Capozzi for proofreading and motivating me.