Skip to main content

Scaling Design Systems

What does a system of design systems look like in practice?

News Item Featured Image

At BrainGu, we incubate web applications that meet operators’ needs and the secure infrastructure they run on. To mediate design and development, each of our applications has its own design system.

A set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels. - Nielsen Norman

In parallel, we are building a platform to increase the speed at which we incubate apps, and a platform-wide design system is central to that evolution. While many companies have one design system platform-wide, and agencies often deliver a one-shot design system as part of their client handoff, BrainGu is in a unique position in that we need both to accelerate individual app development and scale frontend development across the company so we can incubate more apps and impact more operators. In other words, BrainGu needs a system of design systems.

What does a system of design systems look like in practice?

First, we need the right tools and processes. Enter Storybook and Chromatic. Storybook is a tool to develop, test, and document design systems and component libraries. It allows us to prototype live presentational code, putting it right at the intersection of design and development. Implementing Storybook within each of BrainGu’s applications will give the design and development teams the sandbox they need to prototype components and make changes quickly.

Once a component is prototyped in Storybook, how will developers know when a component is ready for development on the behavioral side?

That’s where Chromatic comes in. Chromatic is built on top of Storybook, and it effectively serves as visual source control for UI components. Whenever code is pushed to a repo with Storybook and Chromatic built-in, Chromatic will run visual tests to see how the design system differs. Any changes are flagged so stakeholders can provide feedback and sign-off before merging those changes. This way, we can minimize back and forth by knowing when a component is ready for further development.

For example, when a new component design needs to be translated into code, a developer will create a new branch in that app, prototype live presentational code in Storybook, push that new branch, and open a PR. That PR will create a Chromatic UI review check so designers and other stakeholders can provide feedback and sign-off. After sign-off, that presentational code will be merged into the main branch for developers to begin building out the behavioral code for that component. Building applications component-by-component using Storybook and Chromatic is how we maintain elegant design systems within each application, ensure visual consistency, and accelerate both designer and developer velocity.

The BrainGu-wide design system, aka mission-components, is intended to be our quiver of components and features that any current and future application can pull from. It will also be the single source-of-truth for Material UI themes. Material UI is the set of components BrainGu has adapted to take care of basic UI elements like buttons, freeing us up to build more complex components. One powerful feature of Material UI is theming which allows us to customize the look and feel of the entire suite of Material UI components. The currency for that theming is the theme file. We can customize everything from color palettes to hover behavior – any CSS selector. By building out the necessary UI states in Storybook, we can quickly prototype new theme files in Storybook, test those changes in Chromatic, and publish them for any BrainGu application to use. This same workflow applies to components and features incubated in a BrainGu application that could be reused across our entire platform. As individual components within an application are developed using Storybook and Chromatic, those components that the team deems to be reusable can be easily extracted into mission-components for any application to use in the future.

This is the flywheel by which BrainGu scales frontend development: develop components as needed within each application’s design system, and when reusable, pull those components into the BrainGu-wide design system, thus making it faster for future apps to get up and running.

A major consumer of this BrainGu-wide design system will be our frontend app generator, mission-nextjs. When we need to incubate a new application, we will use mission-nextjs which will always have the most up-to-date version of mission-components as well as Storybook and Chromatic. Components will be developed in that new app cloned from mission-nextjs, and when new components are deemed reusable, the mission-components team will work with that development team to extract that component into mission-components for future re-use in new applications through mission-nextjs.

While the primary benefactor of this approach is each new application BrainGu incubates, existing apps can also take advantage of mission-components. Any BrainGu app can import mission-components, and if they build out platform-wide reusable components they can work with the mission-components team to lift that component up for future re-use. Individual apps are free to use whichever version of mission-components suits their needs, and like any package, there may be breaking changes. The mission-components team is dedicated to providing long-term support and communicating changes coming to future versions so developers can prepare before upgrading.

And while this effort is itself a prototype, after initial success with using Storybook and Chromatic to create a custom theme file and set up our initial shelf (mission-components) and frontend app template (mission-nextjs), we’re ready to start rolling out Storybook and Chromatic within our future applications to further accelerate the design-to-code process and bring added value to operators.

Related Posts