How to control chaos in software development with a design system and a component library??

Developing software is a time-consuming and detailed task, where design and development always go hand in hand for the best results.

Large teams tend to be less effective with low returns. There are more misunderstandings; existing user interface patterns are often left undocumented or forgotten when team members change. Over time, a huge number of disposable components will be created, and eventually, no one will know where, what and how something should be used.?

Patterns that were supposed to stay the same have grown apart in appearance and functionality. Every component and pattern that is new and unique increases the difficulty of involving new developers and is not sustainable in a long-term project. The design system's component library should only contain "clean" presentation components. Here are the most important features of reusable components:?

• only deal with the presentation layer;?
• respond only to inputs;?
• do not contain application-specific business logic;?
• are agnostic to how they get their data.?

A component library should not contain application-specific components that include business logic; otherwise, all applications using the system should have the same business logic constraints. In addition, the library should exclude one-off components, even if you hope they will one day become part of the design system - nimble teams manage precisely as much code as they need.?

In a previous blog post, you can read in more detail about what value a design system creates in a software development project.?

Chaos management

Usually, making extensive changes in the middle of a long-term project usually tends to be quite time-consuming and painful financially and otherwise.

That is why our recommendation is always to consider the available information as much as possible in the project's initial phase. On the other hand, it is understandable that in an agile team everything (including goals and information) is constantly in motion.?According to how these changes are managed during the project; front-end developers usually pick one of the following:?

1. use external component libraries;?
2. build their library of components;?
3. a combination of the previous ones, i.e., building on top of an existing library?

Pros and cons of using external component libraries?

Getting started with existing systems is relatively quick. You only have to deal with the development of functionality and the big picture. Therefore, external component libraries are ideal for prototyping, ideation?and MVPs .?

Since your team only has a limited amount of resources - mental capacity and time - using third-party component libraries contributes significantly to solving real problems and assembling the big picture. The team can focus on functionality and does not have to contribute as much to interactions and visuals of the product.?

With third-party libraries, you have to take into account their quirks and features quite early on, especially if you don't have experience with a specific library. Overwriting the visual side may prove to be challenging, and the overwritten patterns may break in the future, especially so, if?tailoring the component to your needs has been extensive and very custom.

In addition, over time, the component may no longer meet the functional requirements, and a choice must be made between three directions:?

1. push forward (not very sustainable);?
2. replace with another component (can be quite extensive);?
3. rewrite it (halfway through the project can be very extensive, historical decisions will be lost, and retrofitting may prove painful).?

Pros and cons of building it yourself

Building a design system and an accompanying component library from scratch is more expensive and extensive than modifying a partially finished system. However, a huge advantage of building it yourself is complete control over the visuals and functionality, especially because the product and its requirements often change over time.?

Developers using a component library (especially junior developers) do not have to worry about implementing different UI functionalities but can focus on business problems and component integration. As a result, it is easier to involve developers of different levels.?

Building a component library is quite different from day-to-day development activities because it tries to solve the developer's problems as well as the user's. Practice shows that building libraries isn't suitable for all developers, especially considering how much UI work is involved.

For example, if your design system and components lack logic or are difficult to use, external development teams will give up using them quickly.?

Unfortunately, they often end up building an identical system themselves, and several competing versions of the same thing emerge in a few years. What is certain is that the more experienced specialists build the library, the more useful the tool becomes for development teams. As with any development project, it is important to follow good development principles, keep the scope and think about the future.?

How to build it yourself but sustainably

If you decide to build a component library yourself, the first task is to create an inventory of the most frequently used components. For apps and websites that aren't built on top of components from the ground up, someone has to manually go through everything and keep their eyes out for repeating patterns and components. For example, Nathan Curtis and Brad Frost have written about methods for inventorying patterns and components.

Components and design systems quickly become obsolete and lose meaning if treated as a side project. Our experience shows that "shared responsibility" in the case of a component library generally means that no one is responsible.

That is why the component library must be thought of as a separate product with its own team. There are as many different opinions as there are developers,?it is not reasonable to implement everyone's wishes (one-off functionalities, application-specific features), and the design system team must be the filter that makes the final decisions.

Maintaining?scope is also crucial to creating a long-lasting component library. There have been cases where components have grown into "giant monsters" over the years due to a constant barrage of small changes. Ensuring that nothing breaks, additional development and using them turns out to be quite a headache, due to there being too many competing goals.

At this point, the paradox of the ship of Theseus comes to mind: "if all the parts are replaced over time, is it still the same ship or something new?" In other words, you need to notice when the original idea of a component changes and when it should be split up into different functionalities/components.?

It is always wise to describe general patterns, recipes and guidelines alongside the component library. Audi and Atlassian design systems are good examples of this. The independence of developers and a smoother workflow in the project will help in preventing recurring problems and staying nimble.?

Keep in mind that a single source of truth is also a single point of failure. Since the truth lies in only one source, every change and addition must be thoughtfully and systematically added, not to mention adequately tested and versioned.?

All components should first be broken down (already in the design phase) into their smallest reusable parts. This helps with composing larger and more complex components from smaller parts and "simple" components while validating their implementation and making them available in case a third party needs to build a snowflake component.?

Describe the situations supported by the system and confirmed by the team and discard the unsupported ones for less noise. At the same time, always try to build components that are durable enough so that "broken" states do not occur. The best use cases help you visualize all the different states of the components.

The tools we use

Storybook is a UI component development environment in which components can be developed and presented outside the main application. This way, you can work context-free with one module at a time and without a complex development stack.?In addition, Storybook is very good for documenting and testing components in isolation, plus it integrates with all of the popular JavaScript frameworks.?

In principle,?Bit is very similar to Storybook. In addition to the development environment, it also offers the rest of the infrastructure as a service, which you would otherwise have to set up yourself as needed (package manager, public and private environments for viewing documentation and components, versioning, etc).?

Depending on the project, we use one or the other. It must be considered that although Bit is a bigger package, as is typical of turnkey services, it also contains paid functionalities. Using Bit, we have to give up some control, as the service provider has already made some decisions for you. At the same time for Storybook, setting up the infrastructure and best practices is going to take up more time.?

Summary

Building a design system and component library is challenging and not a one-and-done job. Applications, best practices, knowledge and opinions evolve and change over time. There are many options to slow down the chaos and "software rot" that comes with it. One of the most basic and simple victories is the proper management and development of your design system and component library.