Maybe not the right choice of words, but Nathan’s article perfectly makes the point. The types of governance he describes are the privilege of massive companies, not the long tail of startup to mid-sized software companies. As I stated in the article, design systems are largely a no-brainer for these types of companies.

Development often becomes much more strongly opposed to change and evolution once design components become code. Efficiencies will exist for designers and developers, but it drastically reduces the incentive for a designer to experiment. Ultimately design as a field does not crave efficiency. As I said in the article, is innately at odds with today’s design systems.

And while I think Nathan’s breakdown is fantastic and does provide a blueprint for navigating these issues, it’s a difficult organizational change to enact. It requires a convergence of savvy and intelligence that most companies will lack. It’s like describing a perfect government to a new country vs. actually providing the long-term support and guidance in making it reality.

Call it losing our baby, but the baby in this case is the true nature of design and how it is lost to the conflicting nature of engineering. The implementation of any design system in code will tip the scales save for the off chance you happen to have a strong team from top to bottom that all share the same vision.