Questions to Ask Before Building a UI Component Library

Whether you plan to introduce a UI library top-down or develop it organically via user initiative (bottom-up), implementing a UI library in a large corporation is challenging. The following questions are designed to help you anticipate the realities behind initial enthusiasm.

You'll need frontend experts who thoroughly understand the underlying technologies, including frameworks like React, Angular, or Lit, as well as the essential technologies HTML, CSS & JavaScript. They need to be proficient in writing unit tests. They need to have a design intuition to understand what your designr team asks for. They need to show ownership for the UI-Library. They need to be empathic about your future users, other developers, so they get the developer experience (DX) right so people are willing to adapt what you build.

You need people who know how to release & publish software on distribution channels like npm, Nexus or Artifactory. They need to be strong communicators as they will spend a lot of time talking to other developers using your UI-Library, either explaining the usage or listening to concerns about bugs and missing features.

The decision to build a UI-library doesn’t happen in isolation. Often it’s happening parallel to a project where it’s needed. I would even say that our preferred way to do it: Grow organically with people who actually need it and get their feedback often.

This creates some kind of tension though: You want to deliver the product and on the other side you spend time on creating components that ask for longevity. This requires a level of pragmatism paired with the discipline to clear the collected technical debt later to keep the UI-Library on track.

Once your team has built a solid foundation of components as the first version of your UI-Library, you want to encourage adoption. Ideally, other teams will hear about it and come to you, asking if they can use it.

As people start using it, you’ll receive feedback—sometimes positive, but often about bugs, missing features, or usability issues. Occasionally, you'll face harsh rejection from individuals who prefer their favorite Open Source component libraries.

Managing all this feedback is resource-intensive. Your involved developers won’t be able to work on the current project or even on the UI-Library itself. It becomes a trade-off: disappoint newly involved teams with unsatisfactory responses or build up a backlog of work while developers spend time on communication.

That’s why it’s important to start slow. Don’t release your library too early. Give your team the necessary time to grow with the responsibility.

The worst software is the one that breaks unexpectedly after an upgrade. Delivering early software, however, requires breaking it occasionally. In semver, which is short for semantic versioning and a versioning scheme for software, this is called a breaking change. In the beginning, you want to leave the door open to break things to allow your team to redesign their approaches. If you deliver your version 1.0 too early, you indirectly promise not to break things.

Of course, with semver, you can break things with the next major version. But if you overdo this, you break promises too early and kill trust. Stick to semver's special major version zero during the initial development phase. This gives you the freedom to break things as needed. Combine this with crystal-clear communication that you are in the initial stages. Say it often and loud that things will break, and offer help to your important early users.

Ideally, things gain momentum in the beginning, with more teams and projects using your UI-Library. However, this can lead to problems. Instead of enjoying the library, people may start taking advantage of you, asking for features you must implement or even entire new components that don’t fit into a UI-Library.

You find yourself at a crossroads: you must say no, but bureaucracy and hierarchy in large organizations may pressure you to comply. This risk turning your team into a UI component workbench for other teams. Instead of improving your UI-Library, you deliver code to other teams, degrading its quality and blurring its scope by adding features the general public doesn’t need. This may endanger the success of your entire endeavor.

Starting a UI-Library is easy: work on some components, bundle them, publish, and let people use it. However, with every project that adds your library as a dependency, you take on more responsibility. Soon, you can neither give up nor change your fundamental approach.

You’ll want to keep your most seasoned developers for your own operative projects, but it’s crucial to retain these experts for your UI-Library as well. This can be challenging due to (developer) natural boredom from handling the same topic for a long time. Therefore, you need to actively train additional developers to reach the required level of expertise and sustain the project if someone leaves.

IT evolves rapidly, so you need to constantly adapt and innovate to stay relevant. If you don’t, you might be stuck maintaining old projects while everyone else moves on to new approaches and new UI-Libraries. Think of new framework versions or features or topics like design tokens.

Lastly, consider the financial aspect. If your UI-Library is subsidized from your actual IT project budgets, be prepared for it to remain a long-term financial commitment.

UI-Libraries are not widely considered to contribute directly to business value, however that’s something often not defined clearly. Any financial decider who should release budget for a shiny new UI-Library would ask: "Will that earn me more money?" You’d have to admit it doesn’t, since the UI-Library itself doesn’t generate revenue—the customer-facing application does.

On the other hand as a UI-Library expert, you do believe in its business value due to cost savings from the reduced amount of code it requires. Cost savings translate into business value. Additionally, enhanced quality and accessibility can attract more users and retain existing ones, leading to increased customer satisfaction and loyalty, ultimately driving sales and business growth.

You need to be ready to articulate the business value of your UI-Library to secure its future. Otherwise, you’ll struggle to maintain financial backing, even if the technological side is successful.

Software needs good user documentation, but writing it is a difficult task. Without proper documentation, people might not use your software at all, use it incorrectly, create bugs and blame your library, or ask naive questions. Well-written documentation is also crucial for preserving project knowledge, making future maintenance easier.

A dedicated technical writer isn't always necessary; skilled developers can bring the same skills or even learn them.

That’s a quote from innersourcecommons.org where you can find many more details about this approach. InnerSource is such a great idea because it explains you the power that drives the successful development of Open Source projects so you can apply it to company internal projects.

A much needed orientation in the world of enterprises where teams often get stuck working in isolation and miss the chance to share great ideas and solutions.

A design system is almost a commodity when developing a modern product for the web these days. It provides guidelines for designing a digital product. Although not required, it ideally includes one or multiple implementations of a component library reflecting these rules and guidelines.

Designers typically own the design system, while developers own the technical UI component library. Ideally, these teams work together. In practice, they usually don't form in parallel and grow with different expectations. Designers focus on alignment, while developers work on implementing the rules for reusable software. This can create tension over the vision and decision-making for details.

Building a UI component library is easier said than done. You need the right people to manage the technical expert task itself but then, there are so many more nuanced challenges that you simple can’t foreseen. I hope my list gave you an idea of the complexity beyond the raw idea to lead your very own enterprise UI-Library to success.

Feel free to contact us. We're eager to share our experience and excited to have our team support your UI component library efforts, whether it’s Angular, React or Lit.