Understanding and supporting the design systems practice

What I read

In this article, the authors investigate the benefits and challenges of design systems, as perceived by both developers and designers. They conclude that the systems are considered valuable in driving consistency and speed, but present challenges related to governance and change management, as well as the need for flexibility.

First, the authors describe what a design system is. They begin with a definition offered by InVision: that a design system is “a collection of reusable components, guided by clear standards, that can be assembled together to build applications.” They provide examples of these systems, focusing on Google and Microsoft as developers of systems that are widely in use. These are often provided in the style of open-source, where companies can leverage the materials as starting points and either use them directly or change and extend them for their specific needs. The authors indicate that there has been very little academic research into how these systems work, and that led to the research questions in this text. The authors will work to identify the types of issues that design system projects encounter and work through, and how leaders of design system projects perceive the concept of design systems.

Then, the authors provide a background of related work. They describe the evolution of design patterns in the context of interaction design, which are typically presented as concepts and examples, but not in formal and off-the-shelf components. These include descriptions, problems, solutions, and examples of the solution; they are useful in communication and investigation, but are not immediately implementable. They juxtapose this to frameworks, which evolved as the direct use development tools (such as Bootstrap) to allow for rapid UI software development.

They then introduce design systems and the users of these systems in more detail, primarily citing practitioners in popular media or from the companies that make the systems. They indicate that they found only two peer-reviewed studies related to design systems. Interaction designers use the systems as “designerly tools” to support “(1) ideating consistent and high-quality design through consideration of the design guidelines and (2) efficiently constructing mockups and working user interfaces with reusable components.” When these systems are used in practice, they require collaboration between designers and developers, and the need for shared understanding, in order to avoid breakdowns (often related to technical constraints that are invisible to designers.) They end their description of background bydiscussing the way these systems have appeared in the open-source community, where systems are discussed, refined, and extended publicly and through community additions.

Next, the authors describe their study approach and results. To address their first research question related to explore the interests and concerns of people involved in these systems, they extracted comments and change requests from the Github repositories of these open-source systems, and then analyzed the content. The project aspects were divided into categories of behavior, visual design, documentation, development aspects, and community involvement. The data was also considered in terms of why the Github issues were provided. These included bugs with the existing components, requests for new components, suggestions for improvements, and questions; the vast majority of the issues were related to the behavior of UI components, and bugs in those components.

To address their second requests question “to understand the values and practices of the core contributors of design systems,” they then performed 40-minute interviews with nine “highly experienced design system practitioners who are leaders of their design system projects.” These were recruited from the same Github archive, focusing on most active contributor of the design system. During the interviews, questions focused on knowledge and experience in contributing to design systems including benefits and challenges.

Design-system leaders emphasized that these systems are about an “all-in-one design and development environment,” in facilitating the crafting of products, as a set of guidelines and rules, and providing a common language for design unification. The benefits of the systems were focused primarily on efficiency and reduced cost of development. Additionally, benefits included consistency and coherence, and an improvement in communication and collaboration between designers and developers. Challenges included balancing a need for standardization and customization, providing ways for the systems to evolve, and an “unfavorable culture or mindset.” The participants proposed strategies for successful design system implementation; these included the presence of a dedicated team, the use of a bottom-up approach to identify necessary components, and the use of proactive communication and documentation around the system.

The authors discuss their findings. A primary result of this work is their new definition of a design system: “an all-in-one design and development environment that includes both UI components and guidelines and serves as a common language for unifying design.” They also identified issues that emerged from the system communities, concerns of the leaders responsible for these systems, and the lack of tools for these systems.

An analysis of the open-source community conversation and issue development indicated that emphasis was placed on the behavior of the components rather than on their visual design, and that there were very few conversations related to documentation. An analysis of the interviews with project leaders showed that the benefits of a system are in all around “in creating an all-in-one, centralized environment for user interaction design and development.” Challenges related to customization showed that product needs highlighted unique system elements, and these were not always addressable through existing systems. Governance of these systems required socialization and documentation, and ensuring that knowledge about and of the systems was shared internally. The authors describe that design systems need to address the balance of “stable design knowledge within the organization and the ever-changing needs of users and products.” There are a lack of tools in support of managing all of these challenges, particularly focused on how to handle understanding, prioritizing, and implementing changes to systems based on unique product needs.

What I learned and what I think

This is literally the only paper I’ve found on this topic, beyond the one opinion piece in interactions. This was published in 2022 (and the data was gathered in 2019), which makes it out of date by design system standards, and it appears neither author pursued this topic further in their research; but all of the issues remain true, and perhaps have gotten even worse.

It’s interesting to me to see how often non-tech and non-design concerns pop up in the creation of products. It’s all about socialization, managing change, making sure people feel tucked in, minimizing conflict, finding places for compromise, and understanding different perspectives and different skillsets. These are all skills that, as gross generalizations, designers and developers don’t want anything to do with. They are opposite to headphones-on culture, and in my experience, both groups view these as a waste of time, because they aren’t doing their craft. The whole “stand up” culture emerged from the need to force creative team members to actually talk to each other, but recognizing that all of the groups hate meetings to the extent that they won’t even attend longer ones.

It’s also overwhelmingly consistent that design systems, and so much of industry, is focused on speed, efficiency, faster execution. It’s so irrational. Quarterly profit reporting doesn’t actually rationalize it, because leaders define their quarterly product goals before working to hit them; they can define anything they want, and New Features doesn’t have to be included at all. In bespoke software, new features may drive sales cycles, so maybe that’s one exception where a need for speed sort of “makes sense,” (where products are compared based on a feature checklist), but that’s such a small segment of product (is it?), and in those cases, they mostly just grab Material and use it off the shelf. And “product parity” as a goal is entirely artificial, again, outside of commodity feature compared to feature sales. There’s exactly zero real reason for Airbnb and VRBO to fight for feature comparability. It’s just not a real thing.

So the whole premise here, or at least a big part of it, is that we need to optimize for speed. That logically leads to efficiency which comes from standardization; it leads to the removal of friction which comes from predictability; it leads inevitably to streamlining. It’s not unique for me to say, because it’s all over the interwebs now, but we’re in the middle of the industrial revolution of software, and not in the good way; we’re at assembly-line.

But if I play out the metaphor/comparison, that’s only bad if you’re trumpeting bespokeness. If you can have any color you want, as long as it’s black, and that’s valuable to you because you want everyone to have a car/Saas product and want to make as much money as you can, then we need technicians, not designers or thoughtful engineers. We know from precedent that technicians in the US can make relatively good money (compared to service oriented jobs), need to be unionized, probably need some sort of credentialing, and work best in situations where their job activities are well delineated. We also know that the jobs can be dehumanizing and boring, can breed resentment between “management” and “rank and file,” and are always at a risk of commoditization due to technology improvements.

It’s weird; we saw the industry go through an innovation to formalization to vocation to (omg AI!) commodity in about 25 years. Maybe that’s not weird. I think Henry Ford made his first car in 1890ish, started Ford in 1900ish, introduced assembly in 1910ish, and maybe said or didn’t say the If It’s Black line in 1920ish. So that’s 30 years.

I can’t believe it’s a 1:1 analogy, but if it is, and we remove the depression and wars (can you really do that?), we got competition, infrastructure, superficial styling, public contributions (highways), safety through policy, and no real large-scale innovation, but lots of incremental innovation, until this self-driving car garbage.

So, back to the paper. I’m not sure on method, because I know designers don’t understand or use github, and most of the designers that I know who are running design systems are really craft oriented, so maybe don’t even understand the underlying technology. I wonder what a better method would be to broad-scale text analysis (comparable to their issue analysis); scraping Figma discussion boards or forums? Same issue, probably—I don’t know if design leaders are engaged in those discussions, or just consume them, or neither.