Why Design Systems?

Let me tell you about four ways that design systems can help you scale, align, and enhance your digital ecosystem

In recent years, design systems have become a seriously hot topic in the technology industry. Pioneered by the likes of Airbnb, IBM, and Google, we’ve seen how the systemization of user experience can bring teams together and support product development at scale.

All too often, I find that the definition of a design system is reduced to something like:

“Design systems are a shared collection of patterns and components, the lego blocks of user interfaces”

While patterns are undoubtedly fundamental to design systems, I feel this definition has become too narrow. To me, design systems ultimately represent a North Star for user experience, a single source of truth that connects and aligns teams. They represent a business's appetite to foster collaboration and alignment of people, tools, and experience.

I often get asked the question, do you think a design system would help my teams to [insert burning fire] ?

Possibly. That’s the short answer.

You might need to align the business on a particular style of writing to harmonize the tone and voice of communications, or perhaps you need to strengthen the connections between brand and product teams. There is no one-size-fits-all solution to design systems and depending on the needs of your organization, the shape and size of the system can be adjusted.

So if your challenge centers around user experience and involves scale, alignment, or collaboration of people and tools, a design system might be just what you need.

Let me tell you about the four superpowers of a design system.

1. They harmonize user experience

Design systems are incredibly effective at smoothing out the peaks and troughs of a digital landscape to establish an end-to-end user experience that is coherent and harmonious. They are able to align even the most siloed of teams on a common language to create something that feels connected and familiar to users.

Without a system in place, two teams can engage in similar design challenges that result in wildly differing experiences. This fragmentation is sure to frustrate and confuse any user engaging with both experiences.

This reminds me of something a colleague of mine once said, “We don’t need the world to see our organizational set up through our ecosystem”.

Design systems drive harmony by allowing us to codify an experience language. Like any language, it has:

• Letters in the form of foundational concepts like color, spacing, and typography.

• Grammar in the form of guiding principles and usage guidelines.

• Words in the form of components.

• Phrases in the form of patterns.

These world-building rules and resources help us make sense of the user experience we’re creating and be objective when it comes to reviewing new solutions or extensions to the language.

We can look at a new solution and ask:

• Is this solution going to feel familiar?

• Does the solution make use of existing words and phrases or are we creating something brand new?

2. They drive efficiency and scale, for everyone

To complement the experience language, design systems teams often develop a suite of tools that allow their various consumer groups to engage with the language.

• A toolkit for designers that provides access to color palettes, typography stacks, and visual specs for system patterns.

• A React UI library for engineers, complete with live storybook examples.

• A writing support application, adjusted to meet house writing style.

The obvious benefit here is that adopting teams aren’t starting from ground zero. Instead of redefining basic user interface elements (e.g. links and buttons) with every solution they create, they can build from a collection of prefabricated building blocks.

As the language expands, these building blocks become larger and more comprehensive. This compounds the efficiency win as teams move to leverage common page-level experiences that support entire use cases.

For engineers, efficiency is driven by a “build once and evolve” approach. It's a common engineering concept that means instead of repeating our investment every time we need to use a button, we leverage our centrally managed button. Over time and as we reinvest in the central solution it matures and becomes more robust. Engineers benefit from a double whammy as centralized solutions also keep tech debt low and reduce QA costs.

One of the risks for larger ecosystems is the tendency for areas to go stale as investment is reduced. Code bases that are connected to centrally distributed code packages can also remain fresher for longer.

Imagine one of our consuming teams needs to make an enhancement to our button component. Once updated, the centrally held repository can ship the enhancement to every team consuming the package. Now everyone has the latest buttons.

3. They create a common language for cross-discipline teams

With a diverse team that can talk to design, content, engineering, and product, a design system can transcend disciplines with a language that brings everyone together. That language is accessed and interpreted through the discipline-specific tools and resources we provide.

• A designer grabs a form control component from the design kit and shares the design with their engineering team.

• An engineer can inspect the design and identify the correct component to implement from the UI library.

• QA can identify from the usage guidelines website that the form control is marked as cross-browser tested.

Creating a common language needs the right people.

You can’t build houses with bricks along, you need mortar to ooze between the joints and glue everything together.

In organizations, we typically hire specialists; front-end engineers, UX designers, content writers. These are people who perform a particular function really well and have extensive knowledge within a discipline. Let’s think of these people as the bricks.

Just like with houses and bricks, we can’t build teams with specialists alone. We need a binding agent — a way of gluing together specialists so they can create strong bonds and work effectively together.

Fortunately, mortar people exist. As the metaphor suggests, they are the glue that holds the bricks together. These people have broad knowledge and expertise across a range of topics, particularly across multiple disciplines. In my experience, design systems can be a rather good home for mortar people.

4. They drive change and enable horizontal capabilities

As design systems mature, they begin to support a greater surface area of an experience and by their nature transcend across the various disciplines. With strong adoption and engagement, a system can enable a unique birds-eye view of the end-to-end ecosystem and offer two-way communication with consumers. This holistic perspective allows a design system team to drive change across consuming teams.

From this vantage point, it’s easier to pinpoint areas of weakness in the ecosystem and adjust course through guidelines, automation, and tools to further support teams.

Consider accessibility. Creating an end-to-end accessible experience is challenging, no matter how small or large the footprint.

Perhaps knowledge and expertise on inclusive design are dispersed unevenly among consuming teams. Or maybe QA for accessibility may not be available in certain areas of the business. The business’s position on support for accessibility may also be unclear.

A design system can offer clarity on direction and then support teams in engaging with the strategy.

• Documentation to align teams on the businesses position around accessibility as it pertains to the experience language

• Automation of basic accessibility concepts like color contrast and text legibility through the foundations of the language

• Accessibility-ready components that guide engineering consumers and designers to consider screen reader labels or page-level landmarks