Also, other teams deal with many, many other complicated concerns that “dumber” UI features from a design system don’t. Design systems deliver only a user interface layer, blissfully unaware of data, security, services, monitoring, performance, and other concerns of a high-end product experience. Product designers and developers don’t expect design systems to do these things. What they do expect is that designing and coding a design system’s UI feature to be as easy — dare I say “quick and dirty?” — as it is on their team.

I feel like this statement isn’t accurate.

There are equally important concerns at the core component level around security, data integrity, monitoring, and performance that can’t be overlooked.

Performance wise, data visualization or other render-heavy components should be benchmarked and analyzed in production or production-like environments to ensure page render time and interactivity aren’t tarnished by event pollution or latency, for example. I’m talking about animations, computations, and rendering of complex data in general.

For security, if anyone’s ever built form components in a design system, I would hope they know that handling any sensitive data means not compromising or exposing that data in any way, is critical. Granted, it should be pretty hard to fudge that up, but the concern doesn’t magically disappear because your component is generic and disconnected from the systems it gets integrated into. At the least, it should be an ethics question early in the process.

Overall, this article has some good points. But just because you’re not building at the product level, doesn’t mean you can be “blissfully unaware” of that integration and compatibility. Working with product engineers to ensure expectations are accurate, edge cases are accounted for, there are no unintended security or performance side effects, and integration is seamless, all should be part of core process when building a design system.