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.
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.
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