The Design System Priority of Constituencies

Of all the things that the W3C has published, my favorite is the priority of constituencies. That’s quite a statement given the W3C published the standards that form the foundation of the web and, by extension, my career. But the priority of constituencies has always deeply resonated with me.

I think I have Jeremy Keith to thank for introducing me to it. It is one of his favorites as well. The priority of constituencies is part of the W3C’s HTML Design Principles. It states:

If a trade-off needs to be made, always put user needs above all…

User needs come before the needs of web page authors, which come before than the needs of user agent implementors, which come before than the needs of specification writers, which come before theoretical purity.

I recently recorded a talk on design systems for An Event Apart (AEA). Every time I read the priority of constituencies aloud, I got goosebumps. It grounds me in what matters most. When we’re tackling some challenging task or battling browser bugs, we’re working in the service of others and this principle reminds me of that.

I was pleased to learn this principle resonates with others at Cloud Four as well. It has become a guiding principle for us. In fact, before the pandemic, we were in the early stages of commissioning a mural for our office featuring the priority of constituencies.

Unfortunately, this mural will never become a reality. We’ve decided to go remote first and will likely close our office when our lease is up.

Much of my AEA talk focused on what we can learn from standards-setting organizations when defining our own component APIs for design systems. That meant I spent a lot of time thinking about design systems while looking at the W3C’s Design Principles document which contains my favorite principle.

At some point, I wondered if we could map actors in the priority of constituencies to the actors in a design system. It turns out they map nicely. Let’s look at them one by one.

Users remain the same. Authors refers to web authors—the people who create web pages. In the case of a design system, those are the component consumers—the people who use the components to create pages and interfaces.

Then we have user agent implementors. A user agent is a web browser. The implementors are the people who make the web browser. They are the ones who have to take the specifications that the W3C has created and make them work in code.

In a design system world, the equivalent role would be the component developers. They are the ones who make the component APIs a reality.

The specification writers? Well that’s the design system team. They are the people who define the use cases, design, and APIs for the components.

And theoretical purity. It remains unobtainable theoretical purity.

Looking at this, it becomes clear how a design system team works in service of so many others. And to my way of thinking, that’s an indication of how noble design system work is. Design system work is devoted to the making the lives of so many other people—both your colleagues and end users—easier.

So let’s update the original principle based on these translations. I present to you, the design system priority of constituencies:

That, my friends, is a mighty and lofty principle for all of us to aspire to.