Comparing design systems to find the best qualities

It's not easy to build very good UI components. A global effort to try and find the best qualities of components would be a great opportunity to improve components everywhere.

Aren't design systems ultimately a quest to collect the best UI practices across an organisation? Or across multiple organisations, or for anyone in general. This kind of work brings excellent opportunities to improve quality across some scope, organisationally or more widely. And if we do that, why not try and aim for the widest possible scope and go global? In A Global Design System, Brad Frost suggests this:

let’s redirect that rallying cry outside of any individual organizations’ walls and apply it to the world at large.

I can only agree with that. With so many design systems out there, it makes a lot of sense to look at the commonalities between them.

As Brad mentions, we've been doing this at Open UI. The goal of this group is to make it easier for developers to build and style UI controls on the web, by improving the web technologies and standards that they are built with. So far, this lead to features like popover (in Baseline today) and styleable selects (in active development).

How a global design system might work

Brad suggested in his post that we could work towards “common library containing common UI components”, with code and designs and documentation. In his follow up, Greg Whitworth suggests to create a test suite. I like how concrete these ideas are, and I am sure they will help tonnes of developers make better components. But what if we look at this idea more a more abstract way?

There are clearly teams who just want to use concrete components, as-is. But in my work and conversations, I hear demand for something else: to have a way to validate what is good. A lot of teams want to build their own components and systems. Or they have to, because of their organisation's specific constraints.

Finding qualities

To me, it seems a lot of developers want acceptance criteria and holistic guidance, rather than built components. There's a lot of example components already, why not try and collect what's already built and seek consensus about what qualities components need?

I'm thinking things like:

• this is how an autocomplete-y combobox should convey new results were filtered
• this is the most user friendly keyboard behavior for switching between tabs
• this type of buttons needs an active verb as the name

This is information that is relatively hard to find, especially for more rare components, and especially in a format that developers can trust to base their decision making on.

In my ideal world, a global design system isn't primarily concerned with making a set of components. Instead, it would focus on finding the best qualities of components. What are the qualities they must have, in order to be solid, accessible, internationalisable, privacy-friendly, secure component?

Benefits

With this approach, these qualities can become checks for everyone who wants to make these components themselves. And at the same time, they can be checks for everyone who wants to quality-assure or accessibility-assess websites that use these patterns. (Plus, folks could still build an example library of components that adhere to the qualities; but I think there are always going to be multiple ways).

Defining qualities rather than concrete components also helps with another problem we've seen at Open UI a lot: that there are many ways that lead to Rome. For example, there are many ways to build a tab. With qualities, we would avoid the search for the true one way to do something. Instead, we could deem multiple implementations of tabs “ok”. The Org X tab is cool, the Org Y is wildly different, but it is also cool, the Org Z tab is… hm, not great, because it lacks a, b and c.

Lastly, it would help with the myth of the accessible component. There is only so much we can build in, there will always be acccessibility considerations that depend on usage (see my talk on built-in accessibility). Both how you use of the component and the context you use it in determine whether the experience is accessible or not. There's no “use this component and your thing will be accessible“. Paraphrasing Scott O'Hara: a component is accessible until you use it somewhere.

What global comparisons unlock

Aren't we lucky that we're now in a phase of design systems that there are a lot to compare between? Comparing different design systems can unlock a number of things, but these are some things I find particularly interesting:

• finding components based on real use cases: if we look at components that already exist, we know someone had a use for them
• finding the best names: naming things is hard, and bringing many design systems together bubbles up which names resonate best with people (see the component matrix and component.gallery)
• getting closer to ‘accessible patterns’: there are lots of things that can make a given pattern more or less accessible; if we bring together patterns from many places, we can document more use cases, more ways people (end users) might use this pattern (accessibility is largely about how people use the web), and more aspects their accessibility specialists have talked about

Each of these is, in its own way, a benefit of including diverse perspectives. Which is what the W3C has been doing for almost (this year!) 30 years.

A national global design system

Brian Kardell shared his idea for moving components through stages. In it, he says:

[a component] would undergo wide review and get some kind of 'verification stamps' for each kind (a11y, i18n, etc).

He suggests folks submit components, that then get reviewed, which will lead to a catalog of components that have been checked and for which everyone can publicly see how many of the checks they meet.

I liked a lot about this proposal and feel it will be fruitful to primarily focus on checks. I also noticed some similarities to what we're doing at NL Design System, a project I'm involved in for the Dutch government, so I wanted to end this post with describing a bit about our process.

At NL Design System, different governmental organisations collaborate on defining the best components, patterns and guidelines. The core team, that I'm a part of, facilitates this collaboration. It may end up being a kind of national global design system, a standard for building good digital government services.

Relay Model

So how do we work? Each organisation in our community has their own design system. In principle, they use a shared architecture, build components that meet their own needs and open source them under the same license. Components that seem suitable for standardisation are put on a track that we call “Relay Model” (see also this excellent presentation on the Relay Model (Dutch, English subtitles available) by my colleague Yolijn van der Kolk).

In relay racing competitions, runners take a baton and hand it over to the next person. With our Relay Model for components, different people can take a component to different stages.

(Note: there are patterns and guidelines too, but here I'll focus on components specifically.)

In this process, components (their “blueprint”, eg “Button”) can have one of four statuses:

• “Help Wanted“: there is agreement on the rationale for the component, organisation(s) that need this can build it.
• “Community”: the component exists in one or more organisations, meets a set of acceptance criteria and uses the shared architecture. Each organisation can build it with the bells and whistles they need.
• “Candidate”: the component meets more acceptance criteria, including strict accessibility and usability tests, and is deemed ready to become the standard, we solicit real-life feedback in a request for comments period. It is stripped of elements that are too organisation-specific.
• “Hall of Fame”: the component is stable, not controversial, and has “guarantees” around reusability, accessibility, usability and stability. This is where a “button” becomes “nl-button”.

There's also two more informal statuses: components that are likely to have just the one use case for one organisation, one-offs, are deemed “Snowflake”, and components that are unlikely to result in accessible, user-friendly components are deemed “Discouraged”.

During any time, components can exist in multiple organisations, so City X, Government Agency Y and Province Z could all have a Button that meet their needs. The “Hall of Fame” Button is the common denominator version of it, where we've tried to remove all the org-specific stuff and stick with features that multiple organisations need. User research is an essential part of all this and we encourage organisations to share theirs as open source Markdown.

Benefits we see include:

• legitimacy: based on the needs of specific organisations and their use cases
• credibility: the components aren't the result of one person or team's opinions; a combination of wide feedback, user research and collaboration are essential in the journey; “blessing a component” is a largely shared responsibility
• open approval process: the criteria and process for moving to the next stage are open (see the GitHub project board for Help Wanted), anyone can steward a component to the next stage, then pass on they if they wanted to
• living standard: teams should always be able to innovate. If they need an extra component or variation, they can always make it available as “Community” even when a similar component already exists in the current “Hall of Fame” standard

We're currently stewarding components through the first stages, and don't have a “Hall of Fame” yet. But the process already demonstrates value today, for everyone involved: teams are using one another's components and are benefiting from each other's perspectives, accessibility knowledge and user research.

Summing up

In conclusion: I think there's a lot of value in trying to find which qualities make for very good components, using a standardisation-like process that involves a broad range of stakeholders and avoids blessing-by-a-few. In my ideal world, this can bring us to a place where web developers can get more confidence in how to make their components very good. Recent conversations within Open UI make me hopeful we'll get closer to that.