Where to put one-off components?

A while back, Harry Roberts introduced the concept of shame.css:

a stylesheet dedicated to housing your nasty, hacky, quick-fix CSS

The idea is to isolate all the stuff that doesn’t belong in your beautiful, well-architected CSS architecture, in order to revisit it when the team has time to refactor code and create more sturdy solutions.

Application-specific components

At the heart of a design system is a set of reusable UI components that individual applications pull into their projects (which can happen a number of different ways, as Marcelo Somers discusses here.) These components help ensure UI consistency and cohesion across products while helping teams launch higher-quality work faster than ever.

BUT! It’s quite likely that individual applications contain components that fit the very real needs of a specific application (think calculators, holiday-season parallax hero units, context-specific interactive maps, and so on), but may not be able to be immediately (or ever) abstracted into a generic, reusable component that’s included in the design system. Ethan Marcotte had a great recent article on that topic.

It’s important to be thoughtful and deliberate about how to handle changes to the system over time. Formalizing a process for making changes to system is important. and dealing with one-off components should be a part of that process.

“Shame.css”, but for components

With some of my clients, I’ve proposed the idea of a “Shame.css” but for application-specific components living inside a outside the system. 

“Shame” is too strong & negative a word, but maybe it’s something like /one-offs, /app-specific, /departures, /non-design-system-components, or some other clever label. The idea is to standardize where all product teams put their application-specific components. It could look something like this:

src/
├── components/
│   ├── design-system/
│   ├── application-specific/

This setup provides quite a few benefits:

  • It makes it easy for the design system team to periodically audit these one-off components to ensure individual applications are properly using the design system, and to look for trends across applications to inform the system’s roadmap.
  • This setup makes lifting app-specific components out of individual apps and into the design system a lot easier.
  • It makes replacing app-specific components with design system components a lot easier.
  • It helps the design system team gauge how robust/comprehensive the design system should be. If each product’s application-specific folder has dozens of presentational components, perhaps that’s an indicator that the system needs to provide more solutions.
  • This structure gives individual teams to get specific things done without the design system’s roadmap serving as a bottleneck.

It’s not likely every application will ultimately have an empty “one-offs” folder, but as the system matures the number of custom components should trend downwards. By standardizing the way custom components are handled, even deviations still work with the grain of the system.