When developing a pattern library or design system that will be used in support of a Drupal project, a key decision must be made regarding where the design system should live. Conceptually, many agree that it should be an external dependency of a Drupal theme in order to promote reuse, but a large number of projects still embed the design system inside of the theme in order to simplify workflow and component integration.
While in the past I’ve occasionally found it difficult to justify developing a design system independently from Drupal, on a recent rebranding project I made the case to configure a workflow using this approach. At the start, our plan was to migrate 3 sites into Drupal 8. By the end of the project we ended up with a partial migration to Drupal 8, with two supporting sites still in WordPress - all under the same brand and using the exact same components. In the middle it became apparent that choosing to use an external design system up front allowed us to make decisions that would have otherwise been impossible, and had a major impact on our ability to still hit our planned launch date as the project evolved.
In reviewing this rebranding effort, we’ll take a closer look at our approach to a shared design system including:
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.
I’d love it it you could fill out the feedback form on the session page.
The new Bounteous site (Drupal 8)
The training section of the Bounteous site (WordPress)
Allows you to use Twig in WordPress
An example of a build that might not benefit from an external design system. This blog post outlines their rationale to move to a more traditional Drupal architecture.
Lullabot Podcast with more detail on the decisions that influenced Lullabot’s approach to a rebuild.