If you've ever had the experience of building a user interface while short on time, budget, or expertise - then you've explored the world of pre-made component libraries. If you haven't - and you've somehow managed to work exclusively at FAANG or Fortune 500 employers that build every last DOM element from the ground up- here's a quick rundown of what you've been missing out on.

Pre-made component libraries are collections of buttons, inputs, and other UI elements that look (kinda) nice and are (kinda) customizable to most web application needs. A few of the most well-known are Material UI, Fluent UI, and Ant UI.

Within these libraries, the core functionality and design principles of each component are already written, and the developer is given opportunities to customize some degree of its implementation details. For example, a pre-made component library's Button component would likely allow the developer to choose the Button's text and on click behavior, but it might be less prepared to allow for clean customizations to its finer aesthetic details - like its box-shadow or hover transition time. For many use cases, the clean customizations of these pre-built components can offer more than enough flexibility for many user interfaces, and their conveniences can often outweigh their limitations.

However, beyond the standard 'clean' customizations, pre-made component libraries also document and support methodologies for near-infinite levels of 'advanced' customizations. If there's a will, there's usually a way to bend almost any pre-made component into a specific design - usually through ugly, hacky CSS overrides. This is the territory in which pre-made component libraries become more hurtful than helpful.

Consider this familiar scenario. A development team tasked with building a new web application decides they will save some time and resources by using the Material UI component library. Things are off to a great start - it offers every imaginable pre-made component, and the documentation is quite nice. Meanwhile, on the other side of the office, the design team has been hard at work determining that the web application's buttons should look exactly like the button on [insert Figma mockup].

The developers eagerly agree to the design spec, recalling that the pre-made Material UI Button component already has most of the heavy lifting completed. Or so they thought - the developers soon discover that the requested customizations to the Material UI Button are not supported cleanly, and require a 3 day CSS hack. Not only is the resulting DOM rendered code messy, but the same button could have been made cleaner and in half of the time had the starting point just been an unstyled HTML button.

Continuing down this path, the entire user interface soon becomes built on a collection of hacky, messy, and bloated HTML and CSS in order to forge the necessary Material UI components to the aesthetics specified by the design team.

Any time this happens - and it does happen often - it's for one reason: the design language of the chosen pre-made component library wasn't considered, and is at odds with the design language chosen by the design team. When the development team in the scenario chose to use Material UI because of its broad selection and awesome documentation, they also unwittingly decided that the design team needed to adopt the corresponding Material Design language. Choosing a component library implicitly chooses a design language.

Design languages are comprehensive guidelines that have opinionated suggestions and restrictions on how any adopting user interface looks and feels. They have opinions on color, typography, spacing, animation, navigation, shadows, and much more. Design languages do not necessarily have concrete values for these design facets, but instead, offer well-thought-out rules and guidelines that designers must adhere to as they create user interfaces. Naturally, these rules and guidelines also play a part in determining what is and isn't cleanly customizable in the correlated pre-made component library.

If a development team has chosen Material UI as its component library, the design team needs to be creating mockups that follow the Material design language - else risk the tumultuous and messy design to the development flow in the example scenario. Theoretically, a development team could choose a pre-made component library and simply relay its corresponding design language documentation to the design team. However, it's worth considering that design languages are essentially golden handcuffs on creativity, and are guaranteed to be a divisive and serious topic. Consequently, selecting a pre-component library must be a joint collaboration between designers and engineers.

‍