Thoughts on a Global Design System

Practical steps to make it a reality

After sipping a drink filled with caffeine and cracking my knuckles I'm prepared to author my first blog post on this dusty site in over four years. A lot has happened in that time but before I turn this introduction into one that resembles the ramblings of a recipe site; I'll smoothly transition from my lack of writing to the purpose of this post. As the title alludes, I will be outlining my thoughts on the feasibility of a Global Design System which was reinvigorated by Brad Frost in his post A global design system. If you haven't read this post I recommend it.

As I was reading Brad's post it reminded me of a key goal when we initially proposed Open UI. Heck, here is a design in the early pitch deck:

Graphic that shows all of the specifications that developers and designers use and how Open UI will bring them together and then back.

Granted, Brad's version of it is far prettier than mine but it articulates the same problem overall:

Graphic that shows a circle with Global Design System and then its use within a lot of other design systems represented by other circles

The Open UI Community group resolved that the group should work on a Global Design System via a new dedicated work-stream. This blog post aims to tackle some key questions as to try our best to ensure we do not waste anyone's time by becoming another example of XKCD 927 where we produce another standard.

I agree with others that the best way to do this is to provide the web community with something that is tangible which requires us to go beyond documents. Granted, the documents that outline the parts, accessibility, internationalization, behaviors, base styles, and variations are important; but we want that work to be realized through utilization.

Aligning on definitions and Open UI scope

Before I jump into how I think Open UI can help facilitate a Global Design System I think it's important to outline what constitutes a design system and what Open UI's scope may take.

What is a design system?

I've seen a lot of blog posts that articulate what a design system is and they can vary wildly but I find Figma's to be the most succint and encapsulates what I've seen in the wild.

At its core, a design system is a set of building blocks and standards that help keep the look and feel of products and experiences consistent. Think of it as a blueprint, offering a unified language and structured framework that guides teams through the complex process of creating digital products.

What building blocks should Open UI produce

The following graphic by Rohan Kamath in his post Atomic Design methodology for building design systems, does a great job showing the broad spectrum that a design system can define and potentially produce for utilization.

A design system can cover defining sub-atomic items (eg: spacing, colors, typography), molecules (eg: an email component that includes both the label and input and relative styles) to complete pages (layout of the page, component placement, styles, etc).

Graphic that shows sub-atomic, atomic, molecules, organisms to pages.

HTML primarily focuses on sub-atomic and atoms. I think that Open UI should define from sub-atomic to molecules.

What's the value of this?

It's worth noting that Open UI has been doing some of this with the improvements to the <select> element and the popover primitive (MDN docs - use it today!). Many of the discussions on these items were about expected end-user experience, styles and accessibility requirements.

However, the Global Design System blueprints that will be authored should be able to be authored in any language, with a browser implementation being one implementation rather than the only implementation. It is important to note that there will be some items that land in this work-stream that may never find its way into HTML, and that's ok. A good example of this was the discussion we had around the potential of a skeleton element. We ultimately aligned that while this was very common across the industry the variations are broad and that has implications on the what accessibility changes are applied; and so baking this into the web platform wasn't the right path forward.

This work-stream within Open UI will provide a blue-print that defines the following:

  • Accessibility
  • Internationalization
  • Privacy
  • Security
  • User experience for different input modalities
  • Default base styling
  • Default events
  • Variations

Additional Value

Another value that this work-stream can provide is by increasing adoption of primitives, elements and other solutions produced by the current Open UI work-stream. Additionally, as components and controls are created we can make proposals for new primitives and elements based on utilization to create a fly-wheel between the two works-streams.

Possible solutions to move this forward

I believe there are two different approaches to enable a Global Design System and they are not mutually exclusive:

  • Testing solution: Will enable any component library determine adherence to the blueprint's defined by Open UI (similar to web platform tests). This will allow component libraries to be implemented in other languages but leverage the research and resolutions provided by Open UI in a tangible way.
  • Component Library: Produce a component library that adheres to Open UI blueprints that can be consumed by web developers and even other component libraries

I have had discussions with a few people regarding both of the options above and I think it makes the most sense to tackle the Component Library first. The reason for this is that I think it's the most pragmatic in the short term. There are some large component library authors interested in up-streaming their solution to become the foundation for this component library.

No matter what solution we go after, I don't think that the Open UI work-stream will or should strive for solving 100% of use-cases for a control or component; but we should aim for solving 80% of them. As Brian Kardell put it recently (I'm paraphrasing), "It will be hard to create one tab component to meet every usecase."

In order to move forward with a component library I've put together the following list of principles:

Component library principles

  1. Ships as web components. This does not preclude Open UI from including a library that help facilitate abstractions, utility methods or polyfills
  2. Meets W3C Intellectual Rights
  3. Run as an Open Source solution. This does NOT mean that there will not be consensus driven resolutions as key topics will be brought to the Open UI CG telecon for resolution but many of the capabilities should be able to land within a PR with asynchronous review.
  4. Align implementations with Open UI global design system blueprints
  5. Adopts Open UI primitives as they become available for increased adoption and feedback
  6. Has decent adoption and web developer/designer community support (monetary funding is a positive but not required)

Testing Framework Principles

  1. Needs to be framework agnostic
  2. Everything in component library principles section

Next steps

  1. Land on foundation for a component library in a new repository within the Open UI Github organization
  2. Define working model for this work-stream that increases engagement/contributions from developers, designers and spec editors
  3. Outline success metrics and begin working towards alpha version with a clear roadmap

Let's get started

I'm excited to get this going as I think this approach will enable us to increase velocity through incubation and I can't wait to work with you all on this project. As things progress I'll keep updates coming here which hopefully won't be in another four years. Alright, that's enough typing; I need some more caffeine. Talk to you all later.

If you have read this far, please feel free to let me know your thoughts on Twitter (sorry I can't seem to call it X yet) or on our Global Design System channel in the Open UI Discord server.

Special thanks to Brad Frost for review of this post