It's weird how design systems are so rote, yet so difficult
Design systems for software UI are widely seen as necessary for consistency and scale, yet many teams find them surprisingly hard to define, build, and adopt effectively. Commenters highlight recurring problems: vague alignment on what a design system is, over-optimizing for future flexibility, treating it as a static artifact rather than an evolving code-backed process, and the organizational politics and governance needed to keep it usable. Some see value when systems are led by experienced, cross-functional teams and applied with “strong opinions, weakly held,” while others argue that for many companies they become bureaucratic, underused overhead that can even constrain good product design.
What a Design System Is (and Isn’t)
- Many distinguish between:
- Design language (visual style, brand, rules)
- Design system (reusable implementation and standards to manage UI at scale)
- Component libraries (UI code)
- Some argue a design system is a process (“designing systematically”) rather than a fixed artifact.
- Others criticize vague, high-level definitions and see it more concretely as rules for appearance, content, and components.
Why Design Systems Are Hard
- Core issue: people and alignment, not tooling. Teams often disagree on what a design system is, what problems it solves, and how it delivers value.
- Classic tradeoff: optimize for flexibility → over-complex, bloated; optimize for speed → regret and rewrites later.
- New products invariably hit cases the system doesn’t cover, creating exceptions and ad‑hoc extensions.
- Governance and maintenance are harder than initial creation; systems are never “done.”
Process, Governance, and Adoption
- Adoption fails when: designs don’t match the system, contributors don’t read or trust docs, or docs go stale.
- Some report “contributing back” models rarely work; a small, senior, cohesive team tends to produce better systems.
- Overly rigid systems can become bureaucratic, stifle creativity, and be used as a blunt tool to reject contextually better designs.
- Others see constraint and uniformity as exactly the point, especially across multiple products.
Design vs Engineering Perspectives
- Both designers and engineers recognize they’re rediscovering similar system-design problems (API design, microservices, grids, branding).
- Tension over whether code or design files are the true “source of truth”; several argue shipped components must be primary.
- Some designers resent systems as symbols of “worse is better” and cost-saving over doing “the right thing.”
Tooling and Implementation Approaches
- Figma is praised for variants/variables but seen as fundamentally traditional.
- Tailwind is lauded by some as “most of the upside with little downside,” but others say it’s just a CSS framework, not a design system.
- Strong recommendations to build on robust accessibility-focused primitives (e.g., Radix/React-Aria equivalents) rather than reinvent basic widgets.
- Integrating systems into legacy products is described as especially painful.
When to Have a Design System
- Some see design systems as essential only for larger orgs or multiple active products; in smaller teams they can be an “org smell.”
- Success seems to require senior talent, cross‑disciplinary ownership (design/engineering/product), accessible defaults, and cultural change.