Why your team might need a component library

In frontend development, a component library is a curated collection of pre-built UI components, such as buttons, input fields, navigation bars, and modal windows. Instead of each webpage defining its own styles, using pre-built components allows the designer and developer adhere to a consistent design and behavior, aligning with the application's overall design system.

In practice, most frontend engineers understand that having a component library in place will dramatically increase developer productivity. Developers can quickly assemble interfaces with these ready-made components, ensuring uniformity and reducing the likelihood of bugs associated with UI inconsistencies. In my experience I typically see frontend teams using a component library move multiples of time quicker to build new products and experiments, the bread and butter of fullstack teams’ charter.

Typical company journey

I typically see companies go through phases of frontend development that look something like this:

1. MVP using basic tooling: The company builds an MVP using basic tools and frameworks. The focus at this stage is on validating the product idea and gaining initial user feedback. Design and UI are often simple, using basic CSS or lightweight libraries to expedite development.

2. Iterative Improvements: Assuming initial product launch is successful, teams will improve the product based on user feedback. This phase might involve adding more features and refining the user interface. Typically a fair amount of technical debt is introduced at this phase, as growing companies are forced to juggle multiple high priority projects while the team is hopefully scaling

3. Standardization and Branding: Eventually something breaks: the need for a more consistent and scalable UI becomes apparent. Teams may struggle with hotfixing UI issues due to discrepencies between pages, and the UI may feel sloppy or flaky. The benefits of a design system and component library become more clear, a designer may be hired, and the team will begin to tackle the challenges of developing brand identity through color palettes and a “feel” to the app.

This article will generally address point 3, though I encourage all teams to begin thinking about design systems early on - if only for the benefit of speeding up frontend develop and focus on what matters, which I believe is building products.

But how would I implement a component library? Should I pick an off-the-shelf-tool like AntD or Material design.

No!

You don’t need a component library, you need a design system

The issue for both engineers and designers is the same: they’ve inherited a set of components and webpages that are tightly coupled and difficult to work with. Nobody should be reinventing the wheel at this stage of a startup, so teams have avoided ripping apart the guts of core features. But it’s time to get serious and build a definite brand identity, and set of tools so our team can build at a pace we can all be proud of.

When it might make sense

This path is not for every team, but if your business depends on a strong user experience or brand identity, it is an important bridge to cross.

1. Strong design expertise on your team: if you have the luxury of a talented designer on your team, you are already well-equipped to tackle the most difficult aspect of componentization: the design system itself.

2. Ability to invest for the future: Many startup teams are frankly underwater and unable to take advantage of building for tomorrow. There's nothing wrong with this, though I do think it is wise to plan for the future when starting a new application. I'll discuss below how to simplify this process and make it more approachable as a business.

How to do it without breaking the bank

Designs first: tackle obvious components like buttons, menus, text fields, page headers. If using Figma, use Figma's tools to set common color palettes, font, and components as a distinct page. Use those components in all product designs, and strive to find a balance between perfection and "good enough.

Remember, once you have a design system in place, any improvements will be able to be made across the board, at least within Figma. No more design whackamole!

Bridge the gap between Figma and code carefully. There are plugins to emit straight React/Vue/Angular code from Figma, and that can seem like an attractive idea early on. In my experience though, you will basically end up maintaining a configuration yourself, and it rarely pays off.

Instead, I like to invite tech-savvy designers to contribute to code and allow them to update clearly defined source code with variables.

export const ColorTokens: {
  blue: {
    25: '#f5f9ff',
    50: '#e5f0ff', 
    ...
  },
  ...
};

But how can the designer make sure their changes are correct?

UI Workshop with Storybook

Storybook is one of my favorite tools in frontend development: it makes creating components in code dead-simple and allows for easier development cycles. In my career I have spent countless hours going through complex steps to repro a state in UI because the development environment makes it difficult to enter different UI flows without manual testing. I think any engineer can relate to that. Storybook is an excellent tool that makes the visual aspects of testing much easier. I could write a whole article just about this!

As the designers build their pages in figma, engineers can work to keep parity between the design system and their internal storybook, and it can be easily validated by both parties at any point.

Profit

With both engineering and design with a clear role, both parties can move way faster.

Challenges & risks

1. Integration with Existing Codebase: Integrating a component library into an existing project can be complex, especially if the project has a significant amount of custom-coded components or if it's built on a framework that doesn't align well with the chosen library.

2. Over engineering: Engineers love a challenge, and implementing a design system can seem juicy to a career-hungry engineer looking for a challenge. It can be easy for teams to lose the forest for the trees, and focus on building a technically robust component library - rather than a strong user experience.

3. Tribal Knowledge: In my experience, a component library is usually primarily owned by one or two strong frontend developers. This can become an issue as products scale, as application developers may feel daunted by contributing to a niche codebase. In my view, we should try to avoid being too precious about a component library and view it as an ordinary part of the codebase - and avoid gatekeeping when possible.