Companies should just stop thinking they need their own design system.<p>There's zero value in reinventing how buttons and inputs should look like.<p>I've worked for many companies, big and small, and they all had the arrogance to believe they need their own component libraries, reinventing the wheel out of ego.<p>My advice: you're not that special, just pick a component library and spend your precious time building actual value.
This text was authored by an individual who travels globally, educating people on interface design. Previously, he was a weightlifter and worked as a producer for PBS.<p>I mention this because I find myself in complete disagreement with the article in question. It left me questioning the author's expertise in software, as it overlooks what I consider to be the cornerstone of software development: the iterative process. Contrary to the author's views, I advocate for minimal design upfront and urge rapid engagement with users. This is because requirements frequently evolve, often resulting in a project that differs significantly from its initial conception.
This is personal branding designed to awe and audience with little actionable advice.<p>Like everything in the like, there are some truths: mindset based around path with incremental improvement fares better that holistic-first approaches. The abstract concepts with false depth doesn't help on the key subject.<p>I would paraphrase the entire article by saying that the only way to ship fast and good is to in depth on designed simple reusables, build your product around an integration of those simple reusables, take measure of the complexity of the result, and then go on understanding how to improve while keeping and eye on overall complexity.
This article is stating the obvious about any software abstraction:<p>Don't over generalize up front but look at commonly used patterns and create abstractions from there that fit many use cases.<p>At the same time, there are common patterns that people expect to be there (a button component), and I'm always shocked when design system teams spend tons of money writing their own vs reusing other existing component libraries.<p>On top of this all: component libraries need to take tons of non functional requirements into account nowadays (SSR compatibility, lazy loading data for paginated tables and how components interact with hybrid sever/client data loaders, offline caching of rendered components in service workers, etc), so not having some really good actual software engineers on the "design system team" can end in total disasters.
I see this more and more, overly generic team and function names: design system. System engineer. Words like system and design are meaningless, could mean anything. We're all working in a context, so we're all part of a system, everything is a system. None of us are stacking bricks in a predetermined shape, we are all designing.
Design is really NOT a big deal. It has been overhyped over the last decade.
It is NOT a competitive advantage and if anything it hinders innovation. Please STOP putting such a high importance on design.<p>Much more important aspects of products that have been widely neglected over the past decade:<p><pre><code> - data portability
- privacy
- reliability
- extensibility</code></pre>