Chapter 1: A Call to Designers

Dear UX and UI designers,

I write this with genuine concern. There is an overwhelming amount of advice circulating on how to create, name, or even dismiss a design system, all penned by various designers. While some of these pieces offer valuable insights, many are shallow and, at times, misleading.

Why is this so? Because numerous designers appear to lack a fundamental understanding of what a design system truly entails.

TL;DR: "Not all designers!" Yes, you are correct. However, far too many designers do not grasp the essence of a design system yet continue to dispense advice, which often lacks depth.

Before you react defensively, let me clarify why this topic is so important to me.

What Is a Design System?

A design system encompasses a collection of standards that streamline design processes at scale, minimizing redundancy while fostering a common visual language and consistency across various platforms.

– Nielsen Norman Group

Most digital designers adhere to the principles laid out by Nielsen Norman Group, which even provides a foundational guide on design systems. Yet, many who offer guidance on this topic seem to overlook a crucial aspect: The Component Library.

The component library consists of a comprehensive collection of "predefined, reusable UI elements," acting as a single resource for designers and developers to understand and implement specific UI components. It includes not only the component's name, description, attributes, and states but also code snippets and frameworks for frontend and backend implementation where applicable.

In addition to the component library, Nielsen Norman Group highlights another essential element: The Style Guide.

Style guides contain specific implementation instructions, visual cues, and design principles for creating interfaces or other design outputs. Sometimes, they are integrated into the component library to provide contextual guidance.

Nielsen Norman Group also introduces a third component of the "design system repository," known as the pattern library, but that falls outside the scope of this discussion.

The key point here is that the component library and style guide are distinct entities. As design expert Shane P Williams aptly puts it, "A design system is not truly realized without the code to support it."

Yet, many designers fail to recognize that a style guide without a proper component library does not constitute a design system; it's merely a style guide.

Think of it this way: claiming to have built a computer without a motherboard, hard drive, or operating system effectively means you've only created a monitor. While monitors are valuable, they do not comprise a complete computing system—this is my central argument.

When you encounter designers advising against creating a design system with claims such as "your developers will not replicate the system in their code," speak up! If there is no library of shared frontend components, with the design reflected in the code, then it cannot be considered a design system.

Or when someone suggests, "I've seen many design systems that only exist in Figma," remember that Figma is merely a design tool that hosts the design. Similarly, GitHub serves as a platform for hosting code. Therefore, a design system cannot be confined to Figma; it requires code to be functional.

I understand why these misconceptions arise. Designers often create "components" within Figma and other tools that generate basic CSS. However, these are merely design components—not frontend components that can be utilized across various applications.

The primary objective of a design system is reusability. Without actual frontend components, sharing them among teams and applications becomes impossible. Consequently, components would need to be recreated every time a team requires them, a common scenario in organizations lacking a robust design system.

With all this in mind, I urge you to do your due diligence. Understand what a design system really involves before offering guidance to your peers. Avoid phrases like "handing your design system off to your development team." You cannot "hand off" a design system to developers; without their involvement, a design system does not exist.

Grasping this concept is essential. Otherwise, the advice you provide may be misguided, or worse, detrimental. If you identify as a digital designer, at the very least, familiarize yourself with the basics.

After all, how can you effectively design a product if you lack comprehension of its fundamental structure?

To conclude on a positive note, I recommend exploring two insightful stories about design systems, authored by Shane P Williams and Linke, respectively:

The first video, "My Take Home Assignment | Senior UX/Product Designer," offers personal insights and experiences that underline the importance of a solid design foundation.

The second video, "How I did my take-home design exercise as a UX product designer," provides a practical perspective on navigating the complexities of design systems.

Read more: