The Care and Feeding of Frontend Design Systems

Are you a CTO who's thinking about implementing a frontend design system for your team or organization? Maybe you are thinking about how to get buy-in from upper management or your development teams. Perhaps you've weighed the time and effort required to actually build a frontend design system from scratch versus customizing a prebuilt system. Finally, you've probably taken a look around at some examples of frontend design systems to get ideas.

Recently, I was part of a project team at an organization that had created an in-house frontend design system. I got to work with and contribute to the system and watch as different parts of the application evolved from an earlier incarnation into a new stage of life.

Overall, I was impressed with how well this worked out for the company's end users and for the development team. I came away with a few ideas about the minimum, high-level elements that are required for other teams to reproduce this success.

Caring for a Design System

A frontend design system needs a good caretaker or caretakers to nurture and guide it. You should not just set up a repository and let everyone start adding to it. A team — or at least two people — needs to have ownership of it and be in charge or field contributions in the form of bug fixes or entirely new components. (I use the term components in the most generic sense, be they components in the latest JavaScript framework, standard web components, or just HTML and CSS.)

I say two people, at minimum, because a design system can easily die if the one person that cares for it leaves or gets reassigned. You need to build continuity of care into the system. It would be ideal for these caretakers to represent design and development interests, as these are the two primary stakeholders in its adoption and success.

These caretakers need to provide the design system with a home where documentation can be developed from the tiniest details — from color specifications and typographic styles up to fully formed reusable components. This documentation should also include processes for contributing to the system and maintaining it — all with an eye toward making sure your team is cohesive and moves as one with respect to the system.

Some regularly scheduled meetings to discuss big picture ideas like new challenges and overall direction can also go a long way toward increasing adoption.

Feeding a Design System

Everyone should be welcome to contribute ideas for additions, changes and bug fixes to the frontend design system. Those contributions should be evaluated by the caretakers for appropriateness so they can either provide feedback or give the green light to proceed. This can help keep the system cohesive and consistent, making it easier to use and maintain for all.

There was only one developer I was aware of that was not a fan of having a frontend design system. When he moved on there was a significant feature he had prototyped without using the design system. There were elements that looked visually like the design system components but behaved in different ways. This inconsistency would have been confusing to end users. We had to rebuild it. Look out for that.

Developers need have the flexibility to work outside the system. Not every feature necessitates a reusable component, but the ones that reappear in multiple places need to be consistent.

Hopefully, sharing this experience will help prepare you to bring a frontend design system into your organization and raise it to be a strong asset for the entire team.