2019-08-27~5 min

Expectations for our new Component Library

In the past we had a difficult time doing collaboration between design and development. This was in part because we were moving extremely fast and in part because we had no proper organization and processes in place. One could say that moving fast causes the lack of organization. Now that frontend engineering changed to be more stable and predictable we also looked at possible improvements for the design/development collaboration. We thought a component library would solve most of our problems.

Faster Development

This is an obvious one. Despite our efforts, it happened more often than we'd like that we implemented generic components multiple times. Sometimes because an existing component was tailored to a specific use-case and implementing a new one was faster, sometimes because the person working on a feature didn't know of the existence of a component. Many of these cases were caught in code reviews, but by far not all of them.

Even if the developer knew about the component, they were often made just generic enough to also accommodate the current use-case. In that situation it makes sense. When focused on implementing a feature, spending time generalizing a component is not a high priority. It takes significant effort thinking about all possible use-cases for it, what it should cover, what it explicitly should not cover, how it will be used and how it should be styled.

Creating a component library means thinking about all of that once and implementing it. We all know that doing a task in one go is a lot faster than splitting it up and doing a bit here, a bit there. This doesn't mean we create the library in a waterfall model, implementing it once and never touch them again. We will adapt and extend it, but doing so takes conscious effort. It won't be done on the whims of any programmer or designer.

We were also doing a lot of custom styling of generic components. A button had a slightly different background color than in all other places, a panel needed different paddings. This slowed us down because engineers always had to check the design, if standard components fit that or needed to be adapted. As you can imagine, developers don't see the tiny differences of designs, but those are often crucial to make the design work. Slight color differences, alignment on a line, such things. We always had to fix something, and sometimes even rework the styling completely.

With the component library we will have one source of truth. After they're done, they are reviewed by our designers and if they give their ok, this is it. If the design differs, we still use those components, without custom styling. This is important, we won't do custom styling of standard component any more. If different styling is needed, it must first be added to the library. This process makes it harder to introduce custom styles for every instance and therefore improves consistency, which is exactly what we want.

Doing that will remove the need for custom CSS and thereby reduce code duplication. This is particularly important since finding duplication and unnecessary code in CSS is a lot harder than in non-declarative code (JavaScript). There's simply more focus on it. Code quality in CSS in general doesn't have the high standing that it has in *real* programming languages.

One point which I haven't touched yet is decision making. Having multiple implementations of the same component means you have to think about which one to use. Does it fulfill the requirements? No? Maybe another one? If none of them do, where should it be added? Is this a use-case only the current feature has, should I implement an entirely new component? These questions slow down. They need a decision. Maybe even another developer has to be consulted, which interrupts them.

With the library this is streamlined. One answer: use the component from there. If it doesn't fulfill the requirements talk to a designer and lead developer. They will then work out if it should be extended or the design adapted.

With these changes, developers can focus more on creating business value and actually solving problems. Adapting the button the thousandth time doesn't have value and is boring. We hire developers to solve complex problems, not change the button CSS over and over again.

To summarize, I expect that the component library will improve development with

  • Improved component reuse
  • Less custom styling
  • Better CSS quality
  • Streamlined decision making
  • Less overhead, more time to create customer value

Faster Design

As a developer I can obviously say a lot more about how it will improve development than I can about design. But talking to our designers revealed to me that for them it solves similar issues.

They had components in their mind and used them, but still had to recreate and adapt them for the each page. Creating them once, putting them in one place and then reusing them on all pages also helps designers and will speed up their work. And amazingly the design tool we use, Figma, even supports components quite similar to what we have as developers. With properties and everything. Designing new pages can then happen so much faster than before.

With the library in Figma designers can also experiment quicker and see how changes in the generic library affect all pages, not just the one currently worked on. They are then also not dependent on developers any more to see how changes will look throughout the application, or multiple applications for that matter.

More Consistent Design

Usually our designers create quite consistent designs, but with designing every screen separately, some ever so slight inconsistencies creep in, particularly when different people work on it. This made it hard of us developers, as described above, and also wasn't particularly good for the design.

Shortly after I joined, we redesigned the whole application. It is a quite big one, so we could not adapt it all at once. Stopping all other development for a few weeks just wasn't feasible. We had to do it iteratively, which meant inconsistencies between different areas. Over time design evolved in the company and it became possible to improve the new design even further. The improvements were in line with the first redesign, only in the details. Not as clear cut, but still another source for inconsistency.

The application only grew in size and features from then, so we still won't be able to rework everything to use the new components at once. Every part we do though will immediately react to changes in the component library. If a design change comes, this part will already react as a whole to those changes. And it will only grow, until the whole application is implemented using the library.

Final Notes

This is only what I expect. We're currently implementing the component library and after the first version is done, we'll start using it in our applications. So I don't know if it will pan out as I want it to, but I think my expectations are reasonable. In any case, creating, implementing and using a component library is a great step forward for the frontend team.