(Reading time: about 6 minutes)

In Sparkbox’s 2018 Design Systems Survey, more than 80 percent of respondents said design systems can help designers and engineers improve productivity, ensure UI/UX consistency, and improve code reuse.


How many UI components does a mature component library have? Ant Design’s Sketch component library has 33 components and Shopify Polaris has 28. Is the more the better, the more the better? 🐂


“There are too few components to be interesting.”

“The more component libraries the better! Keep the PRODUCT UI unified and increase team efficiency!”

At first, that’s what we thought. A large and complete component library is definitely the best.

https://design.canonical.com/2016/07/getting-vanilla-ready-for-v1-the-roadmap/

Ideally, our collaboration would look like this:

  1. A has encountered A new interaction problem.
  2. To solve the problem, A made the component and gave it A name.
  3. This component is A good solution to A’s new problems.
  4. After a while…
  5. B encounters the same interaction problem.
  6. B can use existing components directly, without having to design from scratch.

Now we have several components in the component library. When it comes to new user scenarios, we don’t have to worry about starting from scratch and not knowing where to start. We can choose an existing solution in the component library. But what do we do when a new requirement can’t be met with an existing component?

We may address new requirements by improving existing components. Such as:

  1. C encounters an interaction problem.
  2. This problem is very similar to that of A, but it also has new challenges.
  3. C believes that if some modifications can be made to this component, both old and new requirements can be met.
  4. C Proposes improvements to existing components.

We may also add a new component. Such as:

  1. D has an interaction problem.
  2. This problem is somewhat similar to that of A, but there are new challenges as well.
  3. D thinks it’s better to build another component, even if you can make it work with existing components.
  4. D proposes adding a new component.

Sometimes, faced with new requirements, we neither modify nor add components, but treat this issue as an exception to the component library. Such as:

  1. E encountered an interaction problem.
  2. This problem is somewhat similar to that of A, but there are new challenges as well.
  3. E believes that it is best to treat this problem as a special case, although it can be done with existing components.
  4. E Proposes a new design that is not made into a reusable component and is not included in the component repository.

If all goes well, the component library will accumulate more and more components. The richer the component library, the more interaction problems can be covered. But is a large and comprehensive component library the answer?

Many people’s intuition is that as long as there are enough components in the component library, all development problems can be solved by components. From then on, building products was as simple as building blocks. Not only can a single team quickly and efficiently build new products with consistent experiences, but the entire r&d system is also scalable and able to continually respond to new needs and challenges.

But I’m afraid it’s not that simple. Remember that eight-color ballpoint pen from grade school? Does it really work better than a regular ballpoint pen? Because of the multiple refills, the pen is thicker than a regular ballpoint pen, which is not suitable for long-term use. Because of the complex structure design of the pen holder, it is easier to break the system part. If you normally only need one color refill, the other 7 refill types are a drag.


On the surface, more ink leads to more users. Some like black, some like blue, some usually need to use red, and some long tail users like green, orange, purple. In practice, users who need to use eight colors at once every day are almost nonexistent. The monochrome ballpoint pen has the largest user base. And with each additional color, the user base gets smaller.

Large and complete component libraries have the same problem. The more components, the smaller the target audience. If an application developer uses only 10 percent of the component library on a regular basis, the remaining 90 percent of the component library is dead weight. He doesn’t want to waste time looking at the other 90% of the code and documentation, figuring out how all the components relate to each other, and exposing his app to bugs hidden in the other 90%.

We can think of these as the hidden costs of component libraries. How to reduce hidden costs? There are three options:

  1. Slim down the bloated component library by keeping only common components and removing the non-common ones.
  2. Developers maximize the use of component libraries and find ways to use each component in their projects. 😂
  3. Use some unknown technique to let people know how to use the component library without looking at the code or the documentation, and make sure that every version of the component library is bug free. 🤣

The third kind of plan is not I mortal can achieve, and the second kind of plan is afraid to cut one’s feet to suit one’s shoes. Only the first option is viable. As an ancient saying goes, how can you kill a chicken with a sword? Only by providing the right component library can the team truly improve its efficiency.


“Fit” is more important than “awesome”. Each team is unique, with unique products and business scenarios. Blind pursuit of “large and comprehensive” is not desirable. But between big and complete and small and beautiful, which point and what is appropriate? I’m afraid this article won’t give you a definitive answer, but we can start with at least three points.

First, designing components is an abstract process. Repetition is cheaper than false abstraction. Abstracted components should be answers to common questions, not answers to every question. If you find that components are getting more complex and difficult to maintain, then abstraction is probably wrong. If a component library needs to serve multiple products simultaneously, it should be a core component library, containing only generic, basic components (such as form elements). At the same time, each product can have its own component library, or satellite component library.

Duplication is far cheaper than the wrong abstraction.





–
The Wrong Abstraction, Sandi Metz

Second, component libraries are not only about components, but also about how people collaborate. Because common components need to be used by many people, we may decide how to design and develop them together as a committee. The committee is made up of component designers, developers, and users. The more committees there are, the less effective they are. The less effective the committee is, the more it should concentrate on simple, unimportant decisions. Conversely, if the committee is small and efficient, it can focus on more important decisions. To improve decision-making efficiency, consider splitting the large committee into several smaller ones.

Authority is best applied on the simplest and least important decisions.


Not the most important.





–
Minimal API Surface Area – Learning patterns instead of frameworks, Sebastian Markbåge

Finally, component libraries don’t work on the surface. After all, product development doesn’t happen overnight, and component libraries help the development team maintain the product on an ongoing basis. In component library development, we need to measure the hidden cost:

  1. Usage of component libraries per project. If usage is low, the component library may be too bloated.
  2. How quickly the component library maintenance team responds to new requirements. If the component library has been split into a core and satellite component library, slowness is not a big problem for the core component library; However, for satellite component library, low development efficiency and slow response speed (such as merge PR) is a concern.
  3. Component code quality and documentation quality. While high quality takes time to polish, when it comes to component libraries, quality is king. In particular, we need to focus on the quality of core component libraries and common components. In this way, the efficiency of the team can be truly improved.

Welcome to my column:

Design Institute

If you find my article helpful, please tip or give a thumbs-up. 👍

Your encouragement is my motivation to move forward, thank you for your support!

To learn more

Jamie Fang: Why would a product development team build its own component library?
Jamie Fang: How do big companies design systems? A collection of 25 Sketch component library source files to download
Jamie Fang: How does version control tool Abstract improve design team collaboration?