Design Systems Suck

A look at my love-hate relationship with today's design systems ecosystem

d2 hero illustration


I’ve been working with web styleguides and now design systems for years. I created MDS for Mavenlink, and EDS for Ethos, and many other professional experiences building web styleguide before. I once created the most popular Sass Buttons library on the internet with my friend Alex Wolfe. I’ve used Bootstrap, Foundation, Material, etc., and I’m fairly aware of how things are working in this ecosystem. Well, I think it’s all a bit broken…

Issues in the UI Component World

After feeling quite pleased with myself for creating a design system out of thin air quickly at my last role at Ethos, I started to introspect. What the hell had I just done! I created a design system full of UI component primitives completely coupled to React! Yet again! What was going to happen when I went to my next job–was I really going to create a whole ‘nuther set of component primitives from scratch because they used Vue, or Svelte, or some other framework? Was my HTML, CSS, and design sensibilities just so good that it was worth creating a custom framework yet again?

I justified all this with the idea of how a company with a vision must have it’s own identity and brand, and that having custom branded components is just the best way to go.

I do still feel that way to a certain degree. While I appreciate the amazing achievements of something like Bootstrap and can appreciate the fact that you get a lot of bug fixing for free when you use a framework like that, I would generally not want to be at the mercy of their aesthetics and choices. I’ve played the whole CSS overrides game and it’s not a pleasant experience and degrades performance since you essentially need to write extra CSS to fight Bootstrap (or really any other framework that’s not somehow super configurable).

What are the biggest issues with Design Systems and UI Components today?

To my mind:

  • component systems are generally tied to a JavaScript framework and cannot be used in other frameworks
  • design system tooling: Storybook is great for authoring but limited for custom publishing needs. react-styleguidist is tied to React! I want a way to be able to author and publish without having my design system look like Storybook or react-styleguidist. I’ve bent react-styleguidist to will in two design systems so it gets my vote for publishing between the two, but it’s still a bit of a fight.
  • Syncing: design system implementations go out of date or do not reflect the Design and UX department’s intent.

The Syncing issue is quite hard. I saw a beta app that I can no longer find that was purporting to generate React components from your Figma components (or was it Sketch symbols?) and I signed up for when it was released but never got a chance to try it. But, even though it’s great that you could generate a React component from your design files, there are a couple of problems. First, it’s still tied to React which makes me sad. Second, have you ever fought generated code? It sucks. Invariably, you have to hand edit the generated code. In this case, that might defeat the whole purpose I dunno.

Agnostic primitives

Starting with the issue of UI frameworks being tied to a JavaScript framework I have some ideas. But first let me give an concrete example of a framework that seems great but is tied to a framework so that I make my point crystal clear. Chakra-UI is quite nicely done (although I haven’t used it myself) with what seems to be a clean API and nice aesthetics. However, to no fault of the author but more our current cultural approach to UI components and the dev ecosystem, it is absolutely tied to React. So, I cannot use this wonderful framework in my next Vue or Svelte project.

Of course the flip side is you do get a lot in terms of the “batteries included” aspects of using something like Chakra. I didn’t mean to pick on Chakra btw, Material-UI and many others do this too.


Yes, I’m old school and I’d like to leverage good old HTML and CSS with only small sprinkles of JavaScript for my component primitives. Some libraries like GitHub’s Primer CSS and Materialize appear to feature CSS only design systems. Even Bootstrap favors HTML and CSS over JavaScript. Bulma appears to be another similar approach. There’s even a sort of toy framework called w3css which is at least interesting to examine. If you don’t mind embracing what we used to call “classitis” or “CSS utilities”, you might look at Tailwind. I have not looked deeply into how it works, but it appears that Tailwind leverages PostCSS and will look for an optional tailwind.config.js file that, essentially, defines a theme configuration to your liking that will result in its utility classes matching your preferences as such.

But, what I would really love to see is something similar in spirit to Addy Osmani’s TodoMVC which started as an example to show how MVC works in one framework (I forget what the first one was maybe JavaScript or Backbone), but then was translated into damn near every framework out there. React, Angular, Ember, and other variations are all available in the examples/ directory.

Why not do that for our UI component primitives?

For example, let’s say I have a structure for a button component that lives in <root>/components/button/* and looks something like this:

├── buttons.css
├── buttons.html
├── react
│   ├── buttons.jsx
│   └── buttons.module.css
├── svelte
│   └── buttons.svelte
├── vue
│   └── buttons.vue
└── web-components
    ├── buttons.css
    ├── buttons.html
    └── buttons.js

The top-level buttons.css and buttons.html files would be considered the core and pristine versions of the button primitive. Once these core definitions are defined to satisfaction, examples in various frameworks could be added. Obviously, this is just a sketch and the directory structures could be optimized to however the ecosystems deems best. But the idea is that you’d have core HTML and CSS driving your presentational primitives, and any “framework specific examples” would be a secondary result.

One pain point above is that if/when we change the core buttons.html and buttons.css files, we’d need to somehow sync all the framework example components based on them. I do not yet know the solution to this problem.

Conclusion and Concessions

My idea only solves one of my complaints from earlier–the framework agnostic problem. How we port these into a design system and publish them to match our brand and also stay in sync with our Design team remains to be seen. I think that’s really a tooling problem and my hope is that this would be handled by a tool that also fixes my other complaint of custom publishing. I suppose I’d like to see the best of Storybook and react-styleguidist combined into a single powerful and flexible tool. But, perhaps that’s a pipe dream I dunno.

If we can at least author agnostic components that aren’t tied to a framework, that would certainly feel like progress to me. I may just start to experiment with this myself. I’ll need to have “mini-build projects” for each framework example to pull this off. But, I think similar to TodoMVC, it’s quite possible. Perhaps if my experiments show promise (and I stay motived haha), I could create an RFC and see if I could compel the community to get involved. We’ll see ;-)