I would like to take a stand against “design systems” as standalone work;  meetings to “officialize” components and designers building three tier token systems that most likely will just get ignored by other team members.

I believe that for some teams, the design systems pendulum has swung too far. We have people spending days and days on a type of work that doesn’t really help a company forward, when they should be solving real product problems instead. 

Design systems were invented to solve the problem of having to debate the minutae of basic design components like buttons and inputs. However, some practictioners have now made it their job to endlessly debate those components, and waste company time on trivialities.

Maybe it’s some of the people I follow online; maybe I am overstating the problem; feel free to give me feedback on the post. But this is something that’s been in the back of my mind. I wonder if others have similar thoughts.

Don’t get me wrong: surely, within a bigger company, there is a role for design systems designers. Multiple people at larger companies like Github, Adobe and Figma needs to deal with the intricacies of the many components and variations to make sure the software as a whole is the best it can be.

For those companies, the surface area of their software is vast and complex and there are effiency gains in thinking in systems.

It makes total sense to think about design patterns, to document the logic behind components and to communicate about them. 

Where I think the pendulum has swung too far is that for some companies, there is an intricate belief that truly need a design system when in fact they are way too small to actually need one.

Those companies would overall be better served by taking a more flexible approach to the work itself.

This is coming from a designer who has worked on several large scale design systems over the years, powering software for millions of users.

I see a pattern in design system case studies, where a design challenge is immediately seen as a design systems challenge.

For example in this recent case study I read, the designers worked on a bunch of desktop components. When the question came how to work for mobile, and later for a touchscreen point of sale system, that question was seem as a design system question.

This, when in fact they should maybe have just designed specifically for that use case, learned lessons, and perhaps extract them into small systems. Not the other way around.

The reality is that combining too many systems overcomplicates them. Some things should just be left as standalone systems. Shopify learned this lesson years ago when famously, someone had to order a couch for the office and chose a design system colour. The design system became this rigid object in the company that everything had to accord to.

“But does it fit the system?” was being asked all the time. That question slowed down projects immensely, shifted responsibility to the design system, when the designers should have just… designed. 

Imagine a company with 4 web apps, 1 mobile app, 1 plugin and 1 touchscreen POS style app. The risk is that the design systems team spends an inordinate amount of time on making sure they have a perfect ”system”, that works for all use cases.

In practice, in Figma, this sometimes means building huge libraries, with sizing tokens that work for all use cases, different type scales within the same file (for desktop, mobile and large touch surfaces), dealing with external plugins like Token Studio to deal with the added complexity, in turn making everything even more complex.

In programming, duplication is sometimes much better than abstraction, and you can apply a very similar thought to design systems. Maybe it’s better to duplicate the brand colours into different libraries, instead of trying to create multi-tiered libraries with too many abstraction levels.

What bothers me too is the “meta work” that these types of decisions also create.

In some companies that means long meetings about components to arrive at the conclusions of most of the giants anyway, reimplementing the same thing over and over again. The very problem that the design system intended to solve (why reimplement a button… again?) becomes its own piece of work that is then infinitely repeated as new designers enter the company with their own form of not-invented-here syndrome.

Furthermore expanding the problem, the examples referenced are often from companies working at a much larger scale. When their work is copied, the smaller company is left with a solution that was designed to work at a much bigger scale.

I get it, sometimes at work you need to look busy and show results, but some designers should ask themselves if they are not simply pushing pixels for the sake of avoiding the real work.

I find that a part of designer’s work rarely gets checked by stakeholders, and some designers get by for months, making a good amount of money pushing mostly useless pixels, listening to Spotify instead of to users. 

What I see designers building then is this complex house of cards that topples over when the real world hits. When the app has to be implemented, the dev barely knows how to navigate Figma and they get this 7000 token-monstrosity instead of the +-100 design tokens they need to implement the project.

In the name of consistency and systems, some designers forfeit simplicity and clear communication. They are throwing a bible of docs over the wall — oh, here’s our Zeroheight website of 70 pages! — and wonder why the other party “doesn’t get it”. At the same time, they wonder why their managers “won’t spend more budget on the design systems team”.

The truth is that there is a very thin line between design system work that adds holistic value and design system work that is essentially just busywork.

This is a hard subject to discuss, and I am sure I will get a lot of flak for posting this, but someone needs to say it: the vast majority of design systems work is busywork.

My advice:

• For managers: be careful that what your team is doing is not just reinventing the wheel with another name.
• For designers: do some soul-searching and think about what would be useful to drive your product forward. Don’t endlessly iterate on the design system, work on the actual user experience instead. Talk to your devs and build relationships, don’t create a complex house of cards and endless docs nobody will read.
• For devs: see through the web of abstractions if delivered a complex system and try to implement the simplest system possible. Your codebase has different abstraction patterns than a design app anyway.