Design systems: What could go wrong? What hidden challenges arise in the creation of design systems?

Before starting work on design systems and establishing them for future governance, we need to understand best practices and how exactly we should build them in a way that aligns with the initial intention. Additionally, we must predict its future success – not to mention that we should invest in its adoption and overall buy-in.

We need to define who the customer of the design system will be and approach it as if it is a digital product itself, with all things attached – activation, retention, advocacy from users, and performance metrics for the business.

To make all this happen, we need to understand what should be done and, conversely, what shouldn’t, and what could go wrong. This is what we will focus on in this article. It’s crucial because, if built incorrectly, the design system or its components could immediately end up in the “graveyard” (as Dan Mall ironically calls it), or they may survive for a while but ultimately fail the test of time.

We build design systems to ensure CONSISTENCY, SCALABILITY, and SPEED… let’s elegantly call it CSS (as it’s more memorable).

As a warm-up, this article will focus on these C-S-S pillars and identify potential pitfalls we might encounter. I'm planning to write more articles on this topic, delving deeper into specifics such as naming complexities, using design systems as a collaboration tool (adding another C to make it C-S-S-C), and creating design systems for multibrand scenarios.

Consistency

As a side note: When discussing design systems, cohesiveness often comes up as a notion. So why isn't it the first C in our design systems CSS instead of consistency? It's a nuanced distinction. Consistency forms the foundation by ensuring uniformity in element application. It's the core function of the design system, while cohesiveness is an attribute of a well-executed one.

Alla Kholmatova, in her book "Design Systems," distinguishes between perceptive and functional UI patterns. Similarly, consistency represents the function of the design system, while cohesiveness relates to perception – how elements unite visually and conceptually. Ideally, when discussing consistency, we should consider cohesiveness as well. These concepts are interrelated yet distinct, not derivatives of each other.

All of this helps us to understand the first issue. So, what could go wrong? You might build a system of components that appears consistent, but lacks cohesiveness. Without this unity, your design will eventually look and feel fragmented, leading to unintentional divergence.

This issue can arise within a single platform and become even more problematic across different platforms. For orgs with dedicated teams working on web, iOS, and Android versions, it's crucial to establish a connection with the design system. Identify core components that maintain consistency across platforms while allowing flexibility for platform-specific adaptations (instances). In essence, strive for flexibility while preserving a unified look and feel.

Nathan Curtis also notes that forcing consistency through mandates can backfire if it’s too rigid, as it suppresses flexibility and can cause teams to feel disconnected from the system.

Scalability

Scalability extends beyond managing an increasing number of components; it's about future-proofing the system. What can go wrong?You might inadvertently create a system that resists updates and expansion without compromising existing structure. This can lead to an accumulation of deprecated components as you struggle to introduce new, improved versions.

Be as modular as possible. Start with pre-particles before approaching atoms. When building components, begin with modules that will serve as your "knobs" to update components. Don't publish these service elements in the library for developers, as they primarily relate and belong to you as a designer and component-builder. They'll use a published component that wraps the one you'll keep for future adjustments.

The same applies to primitives. Always keep this foundational level hidden and avoid naming these core attributes semantically (be straightforward here). For developers and other design system users, only publish semantic variables that reference your primary variables (those that hidden and always can be modified only by you as a curator of the design system).

And yes, never delete deprecated components, as they may still present and in use across digital products. Instead, dedicate a folder for them in your Figma file and name it accordingly.

So, to future proof scalable – cascade with purpose, use modular design principles to ensure that even as the system evolves, core components remain intact.

Speed

Speed is another key performance indicator of a design system. It measures how quickly new products or features can be brought to market within the product suite.

What could go wrong? A design system can become overcomplicated, especially when dealing with Figma's limitations. The "variants explosion" and 2GB-per-tab issue are prime examples. These problems arise when a design system attempts to account for every possible component variation, resulting in a bloated, hard-to-maintain system.

Over-engineering in the design phase can slow down both the design and development process, defeating the original goal of speeding things up. So maintain balance. You don't need to create a component for everything that's not reusable. Keep most elements component-specific or platform-specific, but ensure that core components remain intact and are used across every component or pattern in the design system.

On a practical level, consider splitting your libraries so they can hold specific entities and remain interconnected while you work on flows, pages and/or patterns.

The same goes for the speed of delivery of the design system itself. What could go wrong? You can always go with pre-built solutions or boilerplates, but you potentially get a less flexible and untailored (and potentially unscalable) system in the future.

Don’t rush into creating design systems – they don’t materialize overnight. Often, the design language emerges as a by-product of working on a specific product; later, you can scale it to the suite of products or even brands in a multi-brand design system. Dan Mall notes that one of the main goals of a design system is “extending creative direction.” This means you can’t simply predict or build it out of the blue. First, you need to articulate and document this design language. Only then can you elaborate on it.

So, balance the need for rapid delivery with long-term sustainability.