## Introduction

Design systems are architected to help modern, digitally mature businesses operate better, optimise components, and create tools for building products — a practice that is quickly becoming a key industry standard for success. 
Where a design system utilised within a business says a lot about the way it’s used. If it lives under your product engineering team, it’s likely a developer experience tool, making it easier for them to build and deploy UI and creative components usually via Storybook. If it’s utilised under UX/UI or marketing team, it's often a creative productivity tool, ensuring consistent brand expression across teams. When its focus on one of these teams is more predominately, it usually hurts another in return for the other, and it’s safe to say the system has failed to reach its full potential for creating unity.

The above is often where organisations miss their opportunity when creating their own design system. The most important output of the system is rarely around the design and components themselves — rather it’s around bridging the gap by creating value in utilising the design system as a communication tool for business alignment.

## The design system

As we build out scalable applications, we often face challenges in maintaining the growing complexity of component structures. Implementing an archetypal design pattern such as Atomic Design is crucial for the readability, scalability and flexibility of your application. The Atomic design pattern has proved to be remarkably suited for the componentised nature of React.

Atomic design, developed by Brad Frost and Dave Olsen, is a methodology for crafting design systems with three fundamental building blocks, which, when combined, promote consistency, modularity, and scalability. These principles are a natural fit for building a design system as it offers unity between the design and engineering team, allowing then to map out components which have a dynamic lifecycle inside of an abstract ecosystem. 
Atomic Development

The three distinct levels of atomic design — atoms > molecules > organisms map incredibly well to React’s component-based architecture.

- Atoms - basic building blocks of matter, such as a button, input or a form label. They’re not useful on their own.
- Molecules - grouping atoms together, such as combining a button, input and form label to build functionality.
- Organisms - combining molecules together to form organisms that make up a distinct section of an interface (i.e. navigation bar)

## Helping teams communicate

As design systems in large organisations reach a certain point, the challenge is no longer about maintaining your design pattern or creating reusable components — rather it's about consistent communication. Communicating between teams, especially design and engineering, requires shared vocabulary and expressions of intent.

In fact the three top issues that companies face with sustaining healthy growth with their design system are contribution, adoption, and governance. This is where thorough documentation and guidelines allow for robust adaptation. There’s plenty of tools that help automate documentation so you can pull systems from native platforms such as Figma and Storybook.

Team-agnostic documentation helps to organise components based on models familiar to the entire organisation, starting from broad principles down to detailed specifications. It simply gets departments on the same page with more time focused on co-creation.

## Shared mission

Adopting a design system takes commitment and intent, as it’s an investment of resources for major areas in the organisation to continuously evolve and maintain. This sort of commitment shouldn’t be taken without first taking a step back and thinking about how this will greatly impact the business going forward.

Rules will need to be created around contributions and decision-making, but who will be responsible? A committee-based governance, where decisions are centralised within a small group that represents multiple key functions, to ensure that the system works as intended across the organisation. Generally, this team usually consists of team leads from design and engineering.

What makes system creation work is a governance model based on how stakeholders collaborate to prioritise work and make key decisions so they can scale their business operations to meet the organisations goals.

## Shared goals

Setting a design system’s goals for guaranteed success can be tricky for teams to decide on. Many think that system goals should be aligned with product goals; however, there’s also a case for defining success from an organisational standpoint. Consider key performance indicators (KPIs) like time saved for designers and engineers, system adoption rates, user satisfaction, and the volume of resolutions solved across departments; these can help identify how your business has adjusted to best leverage your design system and the operational efficiencies it has driven for your business.

## Conclusion

Investing in a design system isn’t just about design or product — it’s an opportunity to transform business practises across your organisation. Not treating it as such increases the risk of losing business alignment, design purpose, and even opportunities to build communication and engagement across teams. If you want to see your company’s goals succeed, planning for organisation-wide alignment, improved communication, and shared goals is key, so creating a design system could be detrimental to your organisations success.

Design systems: why they are good for business