The Misconception of "Design System Designers" and Its Impact
Written on
Understanding the Role in Design Systems
The concept of a "design system designer" is fundamentally flawed. Rather than creating titles that obscure true skills and mindset, we should focus on the actual competencies necessary for effective design.
Photo by Yan Krukov on Pexels.
Reflecting on my tenure as a Product Owner for a design system that ultimately failed, I identified several key issues that contributed to its downfall, primarily centered around strategy and execution.
Section 1.1 Importance of Management Alignment
One major factor was the lack of alignment among management. When establishing an internal design system, it is crucial to have a clear Plan of Enforcement. What level of user adoption is necessary to effectively implement the system and eliminate redundant UI component development? Unfortunately, management across various departments did not define this critical mass, nor did they strategize on achieving widespread adoption. Some leaders even suggested that using the design system should be optional, despite its purpose for a single website maintained by multiple teams.
Section 1.2 Contribution Process Communication
Another significant issue was the ineffective communication regarding the contribution process. An internal design system should not be regarded as just another product; it functions more like an open-source project. Consequently, a design system team differs from a traditional product team and is certainly not merely a "component factory." A team focused solely on producing components for others to consume is destined to fail. The primary responsibilities of such a team should include governance and guidance—overseeing progress and directing development. While we made efforts to document existing components and outline the contribution process, we fell short in effectively communicating this, resulting in fewer contributions than anticipated.
Section 1.3 Recursive Component Issues
The issue of recursive components often arises: "Wait, we have seven similar components? Let's create the One Component to Rule Them All!" This scenario can lead to the creation of yet more components that are nearly identical. This tendency highlights a common human vanity—choosing to create something new rather than refining existing solutions.
Section 1.4 Collaboration Over Isolation
The design system team faced challenges as many designers opted to work independently rather than collaboratively, despite having access to a large community of designers. This was largely due to a lack of experience and insufficient guidance from leadership. It’s counterproductive for a small group to handle all tasks simply because they are part of the design system team. The focus should shift towards guiding and supporting other designers, fostering collaboration, and building the system collectively.
Chapter 2 The Repeating Mistakes
After two years of placing the failed design system into maintenance mode, there was an initiative to create a new system that would serve multiple sites across various countries. However, I have observed the same errors resurfacing. The promise of collaboration seems to be sacrificed once again, this time more openly.
Some key figures now view the design system as their personal project, despite its intended role as the central repository for common UI components throughout the company—encompassing genuine frontend components and not merely "Figma components."
Section 2.1 UI Kits vs. Design Systems
It's critical to understand that a UI kit is not equivalent to a design system. While designers primarily utilize UI kits, developers must also engage with the design system effectively.
Bootcamp.uxdesign.cc
Section 2.2 Lack of Contributions and Misconceptions
After two years, there have been no contributions from product teams integrated into the system. Some submissions were outright rejected, while others were entirely rewritten by the design system team, leaving many stuck in limbo for extended periods. When questioned about this, the response was that “the design system team lacks designers.” While this is true, largely due to budget constraints and turnover, it shouldn’t impede the progress of an internal system, especially considering the wealth of designers within the company who could contribute.
The rationale provided was perplexing: “They are not design system designers.”
Section 2.3 Rethinking Design System Roles
The term “design system designer” is perplexing. It’s akin to labeling yourself as an “online news media outlet developer” or a “mass market e-commerce product owner.” In reality, you are a developer engaged with online news outlets or a product owner in e-commerce.
The term can come across as condescending, yet I find it one of the most nonsensical titles in our industry. Instead of fabricating roles, we should focus on the skills and mindset necessary for this craft.
Section 2.4 Emphasizing Systems Thinking
At the core of successful design system development is systems thinking, which can be learned by anyone. Previous experience in a design system team is not a prerequisite for contributing effectively.
Tools for Systems Thinkers: The 6 Fundamental Concepts of Systems Thinking
This series on systems thinking provides essential insights and tools to cultivate a systems mindset...
The primary goal of a dedicated design system team should be to promote systems thinking and systemic design, educating designers, developers, and managers on the advantages of this structural approach to product development.
Lastly, successful design systems must be built on a foundation of contributions and collaboration. Ignoring this principle almost guarantees the system's eventual failure.