The Priority of Constituencies Needs a Rewrite

Deep in the W3C HTML Design Principles spec, there’s a crucial detail that we at Cloud Four use as our north star in the course of our work. We’ve written about this before, specifically how it pertains to design systems. It’s called the Priority of Constituencies, and it’s described as follows:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.

I asked my friends on LinkedIn if they had ever heard of it. It’s a small sample set (I’m no influencer, I guess!), but a significant majority had not.

This is a shame! We should be shouting this from the rooftops. This little gem from the spec is super powerful. Then why is this not something everyone talks about? This should be our primary talking point when engaging with clients about design. They should walk away talking about the priority of constituencies and using it to help make decisions.

But they don’t. And I think it’s because this is written in the language of specifications, not humans. I’ll admit it hurts my brain a little to read all the way through it. So, I wanted to break this down into a more readable approach:

When you aren’t sure what to do, always prioritize end users first. Once the user’s needs are met, consider the authors next. When the author’s needs are met, you can consider developer needs.

Only after all those are considered should you worry about specification writers. Never prioritize theoretical purity unless all the other needs are met.

It’s always best to improve things for everyone if possible.

I might be putting a little bit more oomph behind the original words, but I think it’s warranted.

Also, because this is part of a W3C specification, it gives you backing when faced with resistance and you need to assert these priorities. If someone asked you to use a deprecated HTML tag, you’d balk, right? Send them a link to the spec with your explanation. Who can argue with the W3C?