How to build a component library that suits your startup’s needs.
Component libraries make perfect sense as tools for large corporations but may seem redundant for smaller businesses, like startups. In this post, I argue that by following the right principles, aided by the right tools, you can create a UI component library that would boost your startup in ways that go way beyond a consistent UI.
Like any other business decision, building a component library for your startup is a matter of perceived cost-to-benefit ratio. In the case of a component library, a very simplified and abstract formula looks somewhat like this:
For a component library to be worthwhile, it needs to show low costs and probable high returns.
For a startup with just a few projects, limited resources and a small number of employees, building a design system seems too costly. It would require a team to make design decisions for all projects, to maintain an additional repository for the UI library, to configure packaging for the UI components, to build-up a catalog site, to ensure the library gets full adoption, etc.
Your startup quickly grows and evolves. Changes are made frequently to UI as well as to any other facet of your products. It seems almost impossible and highly unproductive to enforce a consistent UI.
Making a UI component library worthwhile
To make a component library worthwhile, each element of the above cost-benefit formula has to make sense. Here, I would argue, the answer lies in 3 principles. A library has to be built gradually, in collaboration, and with its code components as a single source of truth, for it to make sense.
Build gradually
A UI library doesn’t have to be an all-or-nothing decision. Build your library gradually to lower the risk of needless loss of resources and to keep your focus on your main projects. Export components as you go. Don’t make your library a project in-and-of-itself. Whenever a new reusable component is available, simply push it to your library. Don’t build components with no immediate and clear use.
Build collaboratively
Make your UI library a team effort. Reusable UI components should be collaborated on — not dictated a priori. Reusable components will not get the full adoption you’re hoping for if they are forced on your team. A reusable component may need that small tweak to make it suitable for its hosting environment. Withholding your team from modifying reusable components will only drive them to repeatably re-write almost identical components — that’s a certain recipe for bugs, inconsistency in UI and sluggish development.
Make code a single source of truth
The process of building UI components usually starts with non-code products like images, sketch files, etc. —these design artifacts are often treated as the design system’s source of truth instead of the actual code. To keep things as efficient and clear as possible, make sure the code reflects the way things should be. Whenever a developer uses a component, he or she should know for certain that this component is agreed upon and represents the company’s design guidelines.
“We also wanted to minimize sources of truth. Why keep a separate library of components drawn by hand in Sketch once we have them implemented as the real thing used every day by millions of people?
The fewer sources of truth we have for a design system, the more efficient we are.”- Airbnb’s Blog
I would even argue that many of the abstract style-guidelines that describe best practice regarding the correct composition of elements and colors, could be embedded in your code components. For a short POC, read here:
Using the right tool for the job
Bit is a great tool for startups who are looking to build a UI component library. Bit makes it super easy to share components from any project so that you may build your library gradually, without losing focus on your main projects.
Bit isolates components for you — tests and builds them (in isolation) and lets you easily push them to your own collection (library) in bit.dev. No need to configure packages or maintain additional repositories.
Components in bit.dev are rendered-live with examples and can easily be found using Bit’s search capabilities. No need for a gallery website, documentation portals, external component playgrounds, etc.
Components can either be installed using NPM or Yarn or imported to your project, as a source-code, using Bit. Imported components can be updated (from anywhere) and pushed back to their collection in bit.dev. This way, you can build a component library by collaborating.
Conclusion
In conclusion, by using the right methodology, assisted by the right tools, a component library can become a cost-effective way to ensure consistent design, speed-up development time, simplify maintenance and make your company, as well as your apps, much more scalable.
Medium
Top comments (3)
Thank you for the share, didn't knew bit, looks neat 👍
Do you know if they plan to support Web Components too? Or do they already (maybe I mislead the info)?
If not yet, would be cool. As you mentioned, startups quickly grow, evolve and often don't know what their future will be. For that reason, I think that agnostic components are a great match for future proof new design systems.
I couldn't agree with you more. Web Components are the way to go if you're looking to future-proof your design system.
Bit offers support for (vanilla) Web Components, but they're currently still working on support for Stencil and Svelte.
Cool, good to know they are working on supporting Stencil and Svelte 👍
Thx for the feedback