Ryan Singer

August 15, 2022

22. Design systems, modularity and interdependence

This post on LinkedIn got me thinking:

If organisations want to move away from B-grade app experiences, they need to recognise Dev and Design are two distinctly different skill sets. Both require an amount of time to master. 

Therefore pointing a Dev to design system won’t result in consumer grade app experiences, more likely nice components, used terribly.

There are lots of angles to this, but the first thing that popped into my head about developers and design systems was Clay Christensen's framework of "modularity vs. interdependence." A design system is a modular architecture: it is made up fixed units with pre-defined boundaries that fit together in known ways. "Off-the-shelf" is a good synonym. Interdependent architectures are where all the pieces are custom made and fitted to each other for a unique problem.

Both have their place, and they have different properties. Modular systems are cheap to use and they scale well (through repetition/copying the same thing over and over). The trade-off is they have a performance ceiling. When a predefined component doesn't reach the performance criteria, then you need something custom. That means drawing a line around the part of the solution where you need to do something custom, and applying extra time money and skill to do it. That's the cost of achieving performance that you can't get off the shelf.

This raises really fun and juicy questions from the strategy perspective, because we've reframed the debate from "design system good or bad" to *where* and *when* in our system does the design system give good-enough performance, and where do we have special needs that call for reinvention. Those translate to demand-side questions about *what* matters to customers and *when* in their use of the product, as well as supply-side questions, about how many designers we have and where we can apply their scarce capacity to create custom solutions.

This is a nice lens for appreciating the rise of Tailwind, for example. Tailwind can be polarizing. Some designers and programmers with ultra-high taste look down on it, while orders of magnitude more people reach for it because of its modular properties. So you see the massive scale. What's nice about Tailwind is, via @apply and custom class definitions, it's natural to create islands of interdependent, custom designs in the sea of modular elements.