What is the new Emulsify design system?

First of all, understand that the new Emulsify Design System consists of multiple packages. These packages can be used individually to solve specific problems, like theming a Drupal or WordPress website. We’ll cover those kinds of specific uses more in-depth in future articles. In this article, we want to explain the problem that is solved when using these packages together as a cohesive design system

This particular issue is a problem of scale faced by large organizations with multiple properties. To demonstrate this, we created an imaginary university, Western University of Pennsylvania. The university website is built using Drupal 8. Like any large university, they have properties within the organization as well, including the School of Studio Arts. The School of Studio Arts site is also built using Drupal 8. And then finally, there is the School of Law. This project is built using Gatsby (React). We created these properties to show examples of common website needs, but any large university could have hundreds if not thousands of these kinds of properties using multiple languages

Herein lies the problem we’re trying to solve. Large organizations naturally have a few desires across their properties: consistency, reuse, and cost and time savings. Below I’ll explore each of these, and then I’ll end the post with a few engineering details.

Each property may have unique characteristics, but they will also likely want to use some “global” pieces as well. For starters, they will probably want to share fundamental pieces like colors and typography. Many of them may want to also leverage global components (e.g., a header or a footer). But what about accessibility and testing? If best practices are put into place at the university level to safeguard against errors, then it is in the university’s interest to make sure all of its properties can benefit from that as well. 

Take a look back at the Western University projects. Notice the headers and footers are identical for all projects. They also share identical article designs. This points to the reality experienced by large organizations: the need to ensure these elements remain consistent. The only way to do this is to have a single source of truth wherever possible. This leads to the second desire of large organizations: reuse.

To achieve consistency, you have to be able to reuse design and code whenever possible. This accomplishes the goal of having a single source of truth and a single point of failure. If a design has been approved, it should be authoritative and coded only once. It may evolve over time, but those changes will be tracked, versioned, and released accordingly. If there happens to be an error in the code, it only needs to be fixed once in a single location

Again, let’s look at the Western University example. I mentioned the main university and the School of Studio Arts are both Drupal 8 projects. This means they can reuse a large amount of code, including templates (Twig) and styling (we used Sass). We created the following code repositories for these projects:

1. Global Twig
2. Global Styling (Sass)
3. Western University Drupal 8 project
4. Western Arts Drupal 8 project

Because we have separated the first two into separate packages, we can now install and reuse them across as many projects as needed. When developing a property, Emulsify Design System allows you to pull in global dependencies and reuse (and override) to fit the need of a given property

Everything in the School of Arts project that shares markup and/or styles with the university project simply inherits them from the global components. That meant all we needed to do to build the School of Arts project was focus on developing the unique elements necessary for that project. Even on the School of Law website, we were able to reuse the global Sass, so even though we took the time to develop new (React) markup, we still had the consistency of the global styling

Because we packaged the React components just like the Twig components, we are now primed to share these across any new React projects as well. (By the way, since Twig components are packaged, we can also use these on other Twig-supported projects such as WordPress using the Emulsify WordPress Theme). This leads us to the third desire of large organizations: cost and time savings.

This kind of design system can drastically reduce costs over time. First, development time isn’t duplicated. “Build once, use everywhere” is the mantra of component-driven development, and is perhaps more important for thousands of projects than it is for any single project. With this approach, the initial savings comes when engineering new properties. But a side effect of that benefit is that if development isn’t duplicated, errors (and the time to fix them) also aren’t duplicated. This domino effect is felt by many organizations. Not only does it cost time and money, but it also comes with a high level of anxiety. Uncertainty of how many places an error exists across hundreds or thousands of codebases is truly IT nightmare fodder

Also, many organizations have properties with little to no budget. A design system like Emulsify allows the organization to spin up new properties almost instantaneously that automatically inherit the parent project’s code and styling. In our Western University example, we merely have to spin up a new Drupal 8 or React project and we can reuse any shared code or styling immediately

‘Build once, use everywhere’ is the mantra of component-driven development.

Technology

The success of this system is largely due to leveraging the following tools:

1. Storybook: The massively popular component library, Storybook, is an excellent tool for prototyping components for individual projects. We use this across all Emulsify starter kits and themes, including Drupal and WordPress. It supports multiple languages and has an impressive add-ons ecosystem to fit specific project needs (e.g., by default we use the a11y add-on to test the accessibility of all components).
2. Webpack: Webpack is the incredibly popular and powerful build chain behind Storybook. It allows us to leverage packages across multiple properties (see more info on this below).
3. Gatsby Style Guide Generator: We built this style guide generator using the popular static site tool, Gatsby, new for the Emulsify Design System. This is less technical, but it is a crucial piece because it allows you to create authoritative documentation for your design system, including showing the authoritative components from your Storybook implementations. The style guide is highly customizable and can be edited in Markdown/MDX.

Package management

Building projects within Emulsify Design System relies heavily on package management. This is something most engineers are accustomed to, but there may be a mental shift in thinking about components, styles, etc. as packages. Creating packages is the easy part. Beyond that, we have documented the process of hooking those packages up to individual projects using Emulsify. Once you have those code workflows in place, you then just need to make some organizational decisions around versioning and workflows.

Versioning

Like any packaged system, versioning is key to the success of your projects. You will need to version any packages you release and set your properties to use the proper versions. Like any packages, changes to the global components and styles will impact the projects that use them, so you will want to introduce workflows around testing and updates.

Workflows

Using our Western University project above, you will notice that there are two markup sources/codebases: Twig and React. That means if your Twig components are your authoritative components (for new changes, accessibility tests, etc.), you will need to put in place organizational workflows to handle updates across languages. For instance, when a new Twig button component is released, the owner(s) of the React codebase will need to be notified so that they can pull in any relevant benefits of those updates into their own components

This is a high-level view of the engineering details around sharing packages. Any costs associated with the ramp-up and overhead of this approach are drastically outweighed over time by the benefits and savings outlined in the article above. Your challenges now become largely proactive — related to releases and workflows — instead of reactive — related to fractured codebases and practices across a multitude of properties.