Midweight Design Engineer | Clearleft

The New CSS · Matthias Ott – User Experience Designer

CSS is now the most powerful design tool for the Web.

I think this is now true. It’ll be interesting to see how this will affect tools and processes:

What I expect to see overall is that the perception and thus the role of CSS in the design process will change from being mainly a presentational styling tool at the end of the waterfall to a tool that is being used at the heart of making design decisions early on.

Craft vs Industry: Separating Concerns by Thomas Michael Semmler: CSS Developer, Designer & Developer from Vienna, Austria

Call me Cassandra:

The way that industry incorporates design systems is basically a misappropriation, or abuse at worst. It is not just me who is seeing the problem with ongoing industrialization in design. Even Brad Frost, the inventor of atomic design, is expressing similar concerns. In the words of Jeremy Keith:

[…] Design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.

So no. It is not just you. We all feel it. This quote is from 2020, by the way. What was then a prediction has since become a reality.

This grim assessment is well worth a read. It rings very true.

What could have become Design Systemics, in which we applied systems theory, cybernetics, and constructivism to the process and practice of design, is now instead being reduced to component libraries. As a designer, I find this utter nonsense. Everyone who has even just witnessed a design process in action knows that the deliverable is merely a documenting artifact of the process and does not constitute it at all. But for companies, the “output” is all that matters, because it can be measured; it appeals to the industrialized process because it scales. Once a component is designed, it can be reused, configured, and composed to produce “free” iterations without having to consult a designer. The cost was reduced while the output was maximized. Goal achieved!

The cost of convenience — surma.dev

I believe that we haven’t figured out when and how to give a developer access to an abstraction or how to evaluate when an abstraction is worth using. Abstractions are usually designed for a set of specific use-cases. The problems, however, start when a developer wants to do something that the abstraction did not anticipate.

Smart thoughts from Surma on the design of libraries, frameworks, and other abstractions:

Abstractions that take work off of developers are valuable! Of course, they are. The problems only occur when a developer feels chained to the abstractions in a situation where they’d rather do something differently. The important part is to not force patterns onto them.

This really resonated with parts of my recent talk at CSS Day when I was talking about Sass and jQuery:

If you care about DX and the adoption of your abstraction, it is much more beneficial to let developers use as much of their existing skills as possible and introduce new concepts one at a time.

Reflections on Design Systems and Boundaries - Jim Nielsen’s Blog

Jim shares his thoughts on my recent post about declarative design systems. He picks up on the way I described a declarative design systems as “a predefined set of boundary conditions that can be used to generate components”:

I like this definition of a design system: a set of boundaries. It’s about saying “don’t go there” rather than “you can only go here”. This embraces the idea of constraints as the mother of invention: it opens the door to creativity while keeping things bounded.

The Case for Design Engineers - Jim Nielsen’s Blog

This is really interesting. I hadn’t thought too much about the connection between design engineering and declarative design before now, but Jim’s post makes the overlap very clear indeed.