I’ve built a bunch of different design systems for a bunch of different products and organizations, and this thought keeps popping into my mind: it’s weird how design systems are so rote, yet so difficult.

When I say rote, I’m thinking about how parts of the underlying toolkit have become really easy, how pretty much any designer can work on one, and how the general idea of a design system has become understood such that it’s a reasonable expectation that a team will have one.

Tools like Figma are incentivised to build features that make design system tooling within those tools easier and better than ever. They’re alluring because the results are tangible really fast, which suggests they’ll also be impactful really fast.

Conceptual frameworks like atomic design make building with these tools feel like connecting dots in a known system, rather than building a system from scratch.

Popular frontend frameworks and component libraries make implementation feel half-done already.

All this means it’s easy to get started, make fast progress, then hit brick walls at high speed.

Some of the common brick walls themes I’ve seen and experienced across many different teams:

  • A lack of actual (not assumed) alignment within teams and leadership around what a design system is, what problems it solves, and how it will provide value.
  • Poor scoping and planning as a result of a lack of actual alignment.
  • A lack of stewardship and leadership for the design system.
  • Not using or recognizing the design system as an internal source of truth.
  • The mere existence of a design system warping the design process and the value of design as a discipline.
  • A tendancy to over-optimize for future flexibility, rather than immediate need and impact, which eventually sabotages momentum.
  • A disconnect between the design system and brand strategy & identity.

Design systems represent a huge number of small decisions, both visible and hidden, in both design and engineering, that multiply both perceived and actual effort, cost, and value. In general, we’re very bad at identifying those hidden decisions and the actual effort and cost, and we’re not always aligned around the value we expect to gain. In turn, this makes it difficult to plan how and when to invest in design systems in a way that provides real impact in the right ways.

It’s not so much that design systems are difficult, but rather that alignment and understanding and the resulting decision-making around design systems is difficult.

What exactly is a design system then

When thinking about investing in design systems, we often mistake a “design system” as a monolithic concept that you either have or don’t have, treated as a project rather than an internal product.

A design system is really a high-level concept uniting various things together around shared objectives. But thinking about it as a monolith inevitably obscures how each person has a different sense of what that monolith contains.

Like any big hairy problem, it helps to break it down. Here’s how I think of it:

  • Design system: A complete set of standards and principles to manage design at scale. It can include, but isn’t limited to, the visual design language, typography, colour palettes, components, copywriting guidelines, and other elements that create a cohesive, scalable look and feel for the product.
  • Component library: A collection of UI design elements, such as buttons, form elements, and other reusable components. Component libraries are part of the design system, but aren’t themselves the system.
  • Design tooling: The way the design system, components, and so on are defined and made available in design tools. This tooling encodes many parts of the design system, such as the palette and components, such that designer can apply or pull elements out of the system and use them in design explorations and artifacts.
  • Engineering implementation: The way the design system in all of its parts are defined in code. How exactly this is done can vary wildly.
  • Product implementation: The actual use of the design system “in production” in the product or application itself.

Investing in design systems while running into less brick walls

When thought of as a monolithic concept and with a binary definition of “done” that includes all of the above (remembering that everyone will have a different perspective), it rarely makes sense to invest in design systems—and in my view, it’ll never feel done or done well, because it won’t be clear what value it provides or is intended to provide.

But when thought of as an internal product with very specific intended outcomes, it usually makes sense to invest in, so long as there’s clear definitions and boundaries around what and why.

I haven’t found a magic solution here or a checklist to go through, because design systems are hyper-contextualised to your company, your product, and your team. But generally, think about:

The stage of the company

If you’re a startup in the early stages of discovering what you do really well and for whom, you probably don’t want to be thinking about design systems. As an early stage startup, you probably have a small team working in very rapid iterations and with tight feedback loops between team members.

The further along your company is, the more important it becomes to have a design system of some level. Processes and tooling need to scale with the company, and as an internal product, a design system will pay dividends in collaboration and cohesion. A particularly large company can even make an internal design system into an external product.

The state of the product

Even in a smaller company, once a product has some level of confidence around what problem it’s solving for who, establishing a design system, even early, can be helpful for increasing velocity. A design system helps establish and encode patterns, which removes a swath of decisions that need to be made in day-to-day work and review.

Similarly, if you have an existing product that never had a design system, investing in one can pay off: it’s likely that the product has various duplicated patterns and inconsistencies that make it feel fragmented or inconsistent. The act of translating the product into a design system forces decisions that scale down the number of patterns in the underlying system. And, again, then we can stop thinking about those details and focus on solving user problems and exploring new opportunities.

The state of the brand platform

A product’s underlying design system is intrinsically linked to brand strategy. At some point, every company needs a brand platform, and the product itself plays a role in expressing the brand. When a company starts thinking about brand strategically, investing in design systems can help actually execute on making that brand tangible, creating better differentiation and strong positive signals for prospective customers.

That design systems are so rote makes it easy to get a quick return on investment. That’s great. But the ease of getting started shouldn’t overshadow the need for thoughtfulness around planning and alignment, same as any other product. It’s going to be difficult no matter what. But if done well, design systems pay dividends: better design, engineering, and collaborative processes, a stronger brand platform, and a better product experience.

This article reached #2 on Hacker News on December 13, 2023. View thread ↗