Decoupling isn’t just for your data — decoupling your design through the use of a shared design system can provide flexibility and re-use that could otherwise be impossible. This session will explore the advantages and disadvantages of developing a design system that is an external dependency of a project — both from the context of a traditional CMS architecture and a decoupled Drupal architecture.

From the traditional CMS architecture perspective we’ll examine a rebranding project that shares a design system between a Drupal site and multiple WordPress sites. In reviewing this rebranding effort, we’ll take a closer look at an approach to a shared design system including:

• The structure of our design system repository

• Requiring the design system in your Drupal project as a composer dependency

• Workflow and managing releases

• Using Twig components in WordPress with the Timber Plugin

• Challenges and areas for future improvement

From the decoupled Drupal perspective we’ll examine a progressively decoupled Drupal and React project. Through this project we’ll explore approaches to using a shared design system on decoupled Drupal projects, including:

• The structure of a design system used by both Drupal and React.

• Sharing styles between Drupal using CSS Modules.

• The role of a shared design system in projects that use multiple templating engines.

By the end of this session you will have a better understanding of when using an external design system could benefit your project, along with a clearer understanding of how this approach could be implemented — both in projects using Twig and a projects using a mix of templating engines.