Video Transcript: We’re All Writing Our Own Web Standards Now

This is a transcript of a talk given by Jason Grigsby at An Event Apart on October 13, 2021

Jason Grigsby:

Hi everyone. I want to tell you a little story about something that happened to us recently at Cloud Four. As a bit of background, we’ve been working on design systems for a little while now. In fact, I was a bit surprised when I was preparing this talk when I realized that our first design system was built way back in 2013. I mean, I don’t even think we were calling them design systems back then, and if I didn’t feel old before this talk, I certainly do now. Since then, we’ve worked on 22 different design systems for companies ranging from hospitals and nonprofits to some of the world’s largest retailers. We’ve built design systems for a wide range of different applications ranging from online banking systems to automated workflow tools for commercial photographers. We’ve been at this so long that we built, open sourced, released, and deprecated our own design system tool.

It was called Drizzle. We, we work in Portland. It rains a lot in Portland, or at least it used to. Hence the name. It was pretty cool. You can still find it on GitHub. Just, just don’t use it. We won’t fix any bugs that you find. So while every customer and their design system is unique, we’d come to recognize common patterns in our design system projects. We became reasonably good at estimating because we had so many experiences to draw from. We had a good sense of how long it would take to build components and how long it’d take our clients to integrate them, which is why we were quick to identify that something seemed a bit different on a recent project. Our client was often waiting for us to finish our work. This is not normal. Our week would go something like this.

We’d release a new version of the design system late in the day on Tuesday, and by Thursday morning the client would’ve integrated the new release and have questions for us. There were some nice byproducts of this quick integration. We actually got to see our work live in the app shortly after we finished it, and that made our Friday weekly meetings so much more fun. Seeing the components integrated, it is a bit like unwrapping a gift and because we were all impatient children, including including our client, we rearranged our meeting schedule so that their developers could demo their latest integrations at the beginning of the meeting. So it was fun to see things going so quickly, but it was also a bit nerve-wracking. We were on the critical path and typically clients can’t keep up with us. Now don’t get me wrong, I’m not saying this to brag about how fast we are.

We’re not speed demons or anything. In fact, I think if you, if you think about that famous axiom on projects that says there are three factors, speed, quality, and cost, and you can only pick two, well, in our case, we often pick one. We pride ourselves on the quality of our work. That’s not to say that we’re slow either. I think we work at a pretty good clip for the quality of the work we do do, but we’re just not racing or cutting corners or doing shoddy work just to get things out the door. It’s just that in most projects, our clients have many other things are juggling Our project is just one of the things they have on their plate, whereas they, or whereas we get to focus exclusively on the project and because of this dynamic, it can often be weeks or months after we’ve completed our work before we see the design system integrated and ready to go live.

So what was going on here? Were the client developers just faster than any other client we had worked with? I mean, they’re great, but I don’t think that was likely what was happening. So why was this design system different? We thought it might have something to do with a change we had made over the last year or two to the way we were building design systems. Recently we started building more and more of our design systems with web components. In the past, we always built our design systems using HTML, CSS and a light sprinkling of vanilla JavaScript. We did this because most organizations that we work with had multiple technology stacks. Some teams might be building things using frameworks like View, React, Ember, or Angular. But it was just as likely that there were some service built using PHP or Ruby, a service that might be more important than anyone realized.

Or it could be built on a content management system like WordPress or Adobe Experience Manager. We knew that if our design system was built without frameworks, that it could work in any of these environments and we’d seen other organizations that built their design systems on a specific framework like React. When this happened, any sites that weren’t using React were forced to try to recreate the design system in their own technology stack. These translations are oftentimes pale imitations of the original components. Only a few organizations could afford to build, or potentially rebuild, everything in the framework of choice, thus making the developers who like that particular framework happy. Usually the organizations had some site built on something else and those people were left sort of in the cold trying to figure it out for themselves. In web components, we had found a way to provide more functionality in our design systems without sacrificing the portability that we loved, with vanilla code. Web components can either be translated or directly incorporated into modern JavaScript frameworks. There are paths to bring components into design tools, albeit with varying levels of success. And web components can be used as building blocks and editors of some content management systems. For those who may not be familiar with web components or who need a refresher, web components allow you to create your own custom elements. We can create a C4 element, that C4 button element that looks a particular way and provides whatever functionality makes sense for our use case. Custom elements are prefixed to keep them separate from normal HTML tags. So you’ll typically see all the components in one design system starting with the same letters. In this case, C4 stands for Cloud Four. We can have as much functionality in our custom element as we like. We can add custom properties, classes, whatever will be useful.

When we talk about web components, we’re actually talking about three separate standards, custom elements, which allows us to define new elements, like C4 button, the shadow DOM, which is a way to keep the HTML, CSS and JavaScript for web component encapsulated so other styles and JavaScript on the page won’t conflict with them. This allows us to put a web component into any page and feel reasonably confident that it will work. And the HTML template spec allows us to define markup for later use. So after we had done some experiments with web components and felt confident that they could work for our clients, we started using them in parts of design systems. And for this recent project we set out to create the whole design system in web components.

So the first realization we had about our use of web components was that the design system was much easier for the client to integrate into their backend system. Take for example, the modal component we created. So modals, modals are problematic. They present challenges on small screens for people using assistive devices. We try to avoid them whenever possible, but they were unavoidable here. The application had them in multiple places and it was outside of the scope to replace them all. And the modals in this application required more functionality than any modal we’d ever designed. On large screens, multiple modals can be open at the same time. They’re draggable, they’re stackable. Modals can open other modals. So you have to keep track of modal parents and children. There’s so much baked into these moles in the modal components that we actually built. They’re accessible, they’re responsive, they’re themeable, they’re draggable, they support short and long content. They can be a modal or a sheet. They animate smoothly between modals of different sizes. I started referring to them as the best modals ever created. I didn’t do a comprehensive survey, but I find it hard to believe that there are any that have as many features as this and are also accessible. I mean, they’re super modals. , sorry for the dad joke. It took us weeks of effort to support everything the modals needed to do while ensuring we didn’t sacrifice accessibility.

All of the work that went into the modal is really great, but in order to use a modal, all you had to do was add a single line of code to the HTML. Now, this is definitely a simplified example. Most modals require adding some attributes to trigger different behavior and they need to be integrated with the backend to figure out what to actually display in the modal. So it’s not like there’s nothing for the client developers to do to get them working, but a lot of the heavy lifting we did was hidden behind this one line of code. I mean at one point we counted 10 different sub-components being combined to create the modal, and that’s excluding any components that a developer might use for the content of the modal.

The second epiphany came from my business partner, Tyler Sticka. He shared this example when we used to define an input field and a CSS-based design system, it would start something like this. We’d define the markup for the input and we’d add a class. In CSS, we’d define the styles for that element and finally we’d add some documentation about how to use it properly. We’d add some notes about critical things like how to use it in an accessible way, and then clients would need to do the following to integrate that input, component into their projects. They’d installed the design systems, CSS and JavaScript files. They’d copy and paste the markup from the design system into their code or into their templates and they’d wire it up as needed and then they’d look at that accessibility requirement and they’d figure out what they needed to do.

They’d have to create a label and give the input element a unique ID that the label pointed at. Now I’m talking about clients here, but in general, anytime I talk about clients in this presentation, you can substitute that word for any team that consumes the design system. Those are the clients of the design system team. And in our projects, our clients are usually some combination of the design system team and the teams who are ultimately gonna consume that design system. So inputs start out simple but quickly get more complex. For example, in Champion Power Equipment’s design system, they start with a simple input but then quickly move to an input group pattern, which allows an icon to overlay an input. In that scenario, there’s more work for the design system team to do because they have to create, document and style that new input group feature. But the input group is also more work for the teams consuming the design system. There’s a whole pile of new markup for the team consuming the design system to integrate. In CSS-based design systems, more complex components require more work for both teams.

The big realization we had wasn’t that web components could make integrations easier, but that they sort of force you to support those easier implementations. So let’s take a look at what that input field might look like as a custom element, we’d have a custom element called C4 input. That custom element when it was rendered to the page would output an input field inside of that custom element. The custom element would contain all the CSS and any JavaScript we needed to make the input look the way we wanted. From an integration perspective, things become much simpler for anyone who chooses to use this new input component. Instead of installing the CSS and JavaScript and then copying and pasting markup, they use the new C4 input element. But what do we do about accessibility? How do we give the input element a unique ID so that we can point a label at it?

Let’s look at our code again. It might seem like we should add an ID to the custom C4 input element, but that won’t work. Instead, we need to put the input element, we need to put the ID on the hidden element inside of the C4 input. That’s the actual input that the label needs to point at. But people using this component can’t add the ID or even target an ID if one existed, because the input is hidden. It’s part of the encapsulation of the web component. So we’ll have to add the ID to the component ourselves. So maybe we add a custom ID property to the C4 input element. We call it input id, so we don’t cause any conflict with the standard ID property. And then we add an ID to the input inside of our custom element. We’ll use JavaScript to copy the value of the custom input ID into the ID on the actual input.

So now the label will point at the input and work as expected, but is this actually better? We’re now back to requiring people who integrate our components to have to copy and paste the label syntax correctly. And remember our custom ID property. It feels like we’re not taking full advantage of web components. So if we’re gonna add a custom property anyways, why not add a custom attribute for the label itself instead of the ID? Then we can use that information to create a label element inside of our component. We can auto-generate a unique ID for the input and point that label we created at the input via the unique id. By doing this, we ensure that the label and the input are created correctly and we greatly simplify the integration. We’re back to a single line of code. This sure seems better, but maybe we decide that this approach will take too long. We decide we’re going to do the quick and dirty thing and just add the input ID that we are looking at previously. The reality is, even if we do that, we’re sooner or later gonna bump into some variation of the same problem.

For example, what if someone wants to make our custom input required? How do they do that? It’s encapsulated. Hmm, maybe we’ll add a required attribute and see we’re already starting down that same path again. And the same logic applies as you start looking at other features. Does the input need validation states? Polite masking to make it easier for users to enter phone numbers and other information? Rinse and repeat with every feature. The component grows in size as you realize that the features you previously would’ve left for integrators to figure out really probably belong in the component you’re creating. And that’s how you go from a short simple implementation like this to this long list of input attributes and features from a recent project.

Suddenly the smallest parts of our design system don’t seem as atomic as they once did. Now, to be clear, I’m not saying that that atomic design doesn’t apply. The principles still make sense, but I am saying that those atoms are a bit bigger in a component based design system than they are in a CSS-based one. So maybe they’re still atoms, but we’ve moved from like small atoms like helium to large ones like lithium and cesium. So far I’ve been talking about web components, but I believe this transition applies whether it’s web components or React or view or other modern frameworks. It doesn’t matter what the component technology is. This is just what happens when you move from CSS-based design systems to component based design ones, component-based ones.

But it isn’t only about the components themselves getting larger, the nature of our work is changing as well. In the past, our work looks something like this. The W3C or the WhatWG defined new elements and they wrote them into standards like HTML. At some point, often months or years later, we’d learned about an element like mark, we consult MDN and sometimes the actual standard to figure out how to use the element. Or perhaps more importantly, we’d consulted to figure out when it makes sense to use the element and if it makes sense to use it at all. Maybe it’s been deprecated and in our work we might encounter some oddity in HTML and CSS.

For example, did you know that in HTML, the responsive images attribute is srcset and in CSS it’s image-set. Why is that the case? Um sadly, I know the history because of my time working on responsive images, but it doesn’t do me any good. I still have to go look it up and figure out why it’s srcset and image-set. Mostly we just learn what we need to do our jobs, chuckle about how silly it is that things are inconsistent, and just move on. Or worst case scenario, when we encounter something that’s really strange, like the fact that resolution queries use dppx to mean exactly the same thing as 1X and 2x an image size, even though they’re both in CSS. I mean that makes no sense at all. So then that happens and maybe, maybe we do more than chuckle. Maybe we fire off an angry tweet asking what in the world other people making standards were thinking, but whether we agree with the standards or not, we’re just the game players. We’re not the rule makers. We’re using the building blocks that have been created for us.

But here’s the thing, when we’re working on component based design systems, we’re the ones defining the elements. The players in this picture change. It’s no longer the W3C, WhatWG and MDN. It’s actually the design system team defining custom elements and documenting them. So when someone using our design system is confused about what the fitted attribute does and why it differs from the padding attribute that’s on another component, which seems to do the same thing but is more flexible, we have no one to blame for that confusion, but ourselves. See, for better or worse, we’re all in the web standards business now. And, just just let that sink in for a moment. I mean, that’s not what we, we thought we were signing up for. You know, lately I’ve been wondering if this is some sort of cruel joke.

After years of getting yelled at by web developers and people working on web standards thought, oh, you don’t like our standards, huh? Well here, why don’t you go create your own the elements and cut to a few years later and design team is struggling to manage competing needs from multiple teams and fighting with their teammates on what to name a new attribute. And meanwhile, the web standards folks are often enjoying a drink and just laughing and how they tricked everyone into doing their jobs for them. I mean, I know that that’s not actually what happened. I know that a lot of the people work on web standards and they’re hard workers trying to make the web a better place and trying to empower people like us to create better experiences. Still, it really tickles me to think that they might have got one over the rest of us. I guess this is a great example of being careful what you wish for, eh?

So, what is this new work we’re talking about when we talk about creating new elements and defining how they work? What we’re really talking about is HTML API design. Defining APIs has traditionally been the realm of developers or standard setters. So why should designers care about it now? Well, there are several reasons. First, I think the way we think about the things we design and design systems needs to change a little. We tend to think about how we’re designing components that users will interact with and we focus on user needs. And the focus on user needs should remain in our top priority. But we need to remember that the first users of our design system are the teams that will use the design system. We should care about their user experience as well.

And we have a self-interest in making sure their experience is exceptional. Because if the components are hard to use or poorly documented or create friction in their process, those developers may decide to go outside the design system. They may grab something from a third party like material design, or maybe they decide they can build something better themselves. Either way, it undermines the adoption of our design system components and adoption really matters. In fact, Sparkbox, an agency located in Dayton, Ohio, they conduct this annual design system survey. And in the recently released survey, people said that the top priority for the the design systems was promoting adoption. And the third biggest challenge they listed was adoption. So adoption is a big deal. Getting people to buy into your design system is important and the HTML APIs that developers will interact with are a large part of the experience for the teams that adopt your design system.

We ignore them at our own peril. Nathan Curtis wrote an excellent article about how multidisciplinary teams can and should work together to craft APIs for their components. In this article, he points out that having consistent language between design tools and code can speed communication between the different disciplines and reduce the chances for misunderstandings. He said that they’ve had quite a bit of success aligning design and code in three areas. The anatomy: by which he means the hierarchy of elements being the same in both code and design. Properties: their options have a properties and their options having the same names and characteristics. For example, if a property was only supposed to have a handful of options that you choose from allowing either design tool or code to treat that property as a free form input will be problematic. And the third area they’ve had success with is aligning on layout, meaning consistency of spacing, breakpoints, et cetera.

This alignment and the participation of designers in the definition of APIs will become increasingly important as more and more design tools allow teams to import code components into design tools directly. You can give UXPin merge a URL for your Storybook instance, and it will import components into its design tool. So if your developers have given a component some odd property name that doesn’t make sense to you and you were able to ignore it in the past, well now you’ll be using that property name every day in UXPin. Finally, designers should be concerned about the full behavior of component, which means understanding the API and the variants created by the API. Those variants should be designed with intention instead of created de facto by someone trying to meet a coding deadline. And in an ideal world, the component should be easy enough to use the designers themselves might open up an HTML document, add some components and build small designs or prototypes.

So if we’re all writing web standards now, what can we learn from the way web standards organizations have been doing it? I mean, they’re the experts after all. Fortunately, the W3C has published many items describing how the organization works and how they define APIs. The most relevant of these documents is the Web Platform Design Principles. In this document, it describes best practices for API design across languages. The relevant recommendations are:

Prefer simple solutions because simple solutions are generally better and easier to develop and test. They suggest making sure that you know your user needs are well defined so you can avoid scope creep and if something gets too complex, look to break it into smaller pieces.

Name things thoughtfully. The W3C has an entire section on naming principles, so we will return to this in a moment.

Consistency. This is an important one for design system APIs. Not only should your components be consistent with each other, they should follow the prior art established by groups like the W3C. The W3C actually points out just in even the definition of API components or HTML APIs, that there’s often a tension between internal and external consistency. They recommend erring on the side of what people who are going to use your API are most familiar with. Next, they recommend considering privacy and security. This has less to do with how an API should be defined and more about whether or not you should develop a feature in the first place. It’s worth asking yourself these questions. I think too often in technology we do things because we can, not because we should. And finally, they have a specific recommendation for HTML, which is to reuse attribute names for similar functionality. I think this is a really good idea to keep in mind. In fact, it probably makes sense to look through the list of existing attributes for elements that you’re including in your component that’ll give you an idea of what people might want to do with that component. It doesn’t mean that you can or, or frankly should implement every one of these attributes, but it can help make sure you’re not missing anything. Plus the list of existing attributes can give you some inspiration for naming your custom attributes and frankly, naming things is hard. That’s why the W3C has a whole section on naming principles. They start by saying that you should use common words. They remind us that most web developers aren’t native English speakers. Using clear common terms will help everyone understand what a component does. Next they say to use ASCII names, and I’ll admit this wasn’t something that I thought about before, but it makes sense to ensure our custom elements remain in the universal character space instead of some hard to type unicode.

Next future-proof your names as much as possible. Don’t tie them to a specific brand, version, or technology. Make them generic. We’ve long advised people outside of naming to use words like narrow, wide, short, and tall instead of specific form factors like mobile, tablet, and desktop. So thinking about how to make things generic is really important. The W3C consistently advocates for consistency. I think it shows up in every section of their API guidelines, especially when it comes to naming. Finally, they recommend consulting widely on the names in your APIs to research what others have done for similar features, to give feedback early, to use names that are consistent with other web features and to use inclusive language like block list and allow list instead of blacklist and whitelist. There’s some hard won lessons to be learned from standards that didn’t consult widely. Some of you may be familiar with AppCache.

I don’t know the full story of AppCache, but it seemed to suffer from an affliction where it was developed by standards bodies, but wasn’t really, sort of, passed by developers at minimum. They didn’t actually have people test it before it became out in the wild for people to use in their browsers. And when people started building sites using it, it became clear that it was actually pretty easy to use it incorrectly, which normally isn’t that big a deal, but in this case, you could actually get your site into a state where a user had visited your site, it cached the version of your site that they visited at that moment in time and they would never get a new version. It was basically broken for that person forever. And so AppCache was eventually deprecated in favor of service workers. And when they rolled out service workers, there was a lot of time spent checking in with developers to see whether it would actually work the way that they thought.

So you can contrast something like the original version of AppCache with what happened with responsive images. In that case, it was a community of people like me who had never participated in the standards process, but who had a problem and decided to figure out how to solve it. We formed a community group and worked closely with standards organizations to define the picture element and all the responsive images APIs. In fact, this works so well that the Responsive Images Community Group, the RICG, transformed into the WICG, the Web Incubator Community Group, where people working on standards, working in standards, work closely with people in the web community who see a problem and wanna work on a web standard space solution. In our ideal world, when we’re working on a design system, people throughout an organization contribute to that design system as I encounter problems that we haven’t anticipated.

And I think the people working on design systems could benefit from seeing how the WICG nurtures community contributions because it’s a big thing for them to make sure that people who haven’t spent a lot of time thinking about issues at the same level that the standards have can actually contribute and get their ideas into standards. When it comes to naming and defining new API, we found that it’s best to communicate broadly your general plan as early as possible to give feedback from a variety of perspectives. On a recent project, Paul added a blocking attribute to our supermodel. He described what it would do and asked if anyone had a better name than blocking. The thread had multiple comments from both our team and the client, from both designers and developers. And the conversation that ensued made it clear that there was an additional use case that we were unaware of, that at least one of the customer or the client’s designers had encountered.

That use case changed our perspective. We decided that we needed two attributes instead of one to support both of those use cases. But because we caught it early, during the definition phase, before coding had gone too far, we were able to adjust the API to fit the use case and still stay on track for our deadline. Nathan Curtis recommends that APIs should always have a draft that can be easily found and edited by anyone. There should be a place where anyone could get to, which means that it’s more likely to be in, say in a Google doc or a Wiki than in Storybook, which lives in a Git repository. The API draft should start from a template that’s predefined. The draft should be critiqued by a group. He suggests, recommends setting up time for people to talk with voices instead of doing it over Slack. If it’s a small API, it won’t be very long call, but sometimes it could take up to an hour to review more complex components and the API should be available for asynchronous review so people who can’t make it to the meeting could participate as well. And even after you’ve delivered your design system, you can continue to solicit feedback. Fabric is a design system by Alation. There’s this nice feature whereat the bottom of their design system pages, they ask peopleif there are improvements that they would like to see. And this is a little off topic, but as long as I’m showing you their design system, I wanna share this other cool feature they do on pages where they teach core design principles. They have little quizzes at the bottom to help people see if they’ve understood the core concepts.

So that’s what the W3C recommends for defining HTML APIs. I also looked around to see what others have written about this, and there’s plenty that’s written about how to define network APIs, what you should do if you’re building a REST API, GraphQL API, other types of network APIs, but there’s not a lot written about HTML APIs and it’s probably because until recently this was the exclusive domain of web standards. I did find an excellent article by Eduardo Ferrara that I highly recommend. He suggests asking yourself five questions. So I’m gonna share these five questions and intersperse them with some additions on my own. The first question is, which variations should be offered and where do you want to maintain consistency? This helps you figure out where you need APIs. Next, which style should be customizable? Eduardo suggests defining CSS variables that people can use to change the styles because they’re encapsulated inside of web components so people using the components won’t be able to style them directly. One of the questions he asks is whether a style should be a global or a component level variable. And this is something that my colleague Danielle wrote an excellent article about. In Danielle’s article, she was focused on design tokens. But the questions she suggests asking yourself as you try to decide what level of design token should live at, whether it should be global application specific or component specific. Those same questions are applicable to component styles and variables in an HTML API context as well.

In addition to variables consider where it might make sense to support overriding styles via the CSS part pseudo element now part of something I believe it’s only used for web components. It’s designed to allow someone defining a component to expose particular elements for styling. All you have to do is add the part element to, part attribute to an element that you want to allow someone to style. In this case, we’ll add the part attribute to the label element inside of the C4 component. For simplicity’s sake will give the part element or part attribute a value of label. With the part attribute in place, we can now style the element from outside the component using CSS pseudo element, it supports whatever styles the element allows and works with both pseudo elements in most pseudo classes. Setting smart style defaults and then opening up modification via part is a great way to empower people to modify the appearance of the, of part of the component without allowing them to override the entire component.

Another question to ask is how the component might evolve in the future and to plan for those variations. For example, if you had a dialogue that you’re using to surface warnings, if you use a true or false attribute, a boolean attribute called warning, then you’ll have to add additional attributes to support other types of dialogues. Instead if you created a type attribute with a value of warning, it’ll be easier to add different types of dialogues in the future. This example brings up a related principle, which is to make impossible states impossible. For example, imagine that we didn’t have a type attribute, but instead had three attributes for warning, error and success. And based on the attribute, the message is styled differently. Now this will work, but what happens when somebody adds two of the attributes at the same time? What should a component do when they have both success and warning set?

See, this shouldn’t be possible. You can’t have success and warning at the same time. You can’t pick a color from that. So this is another reason for using a type attribute that only accepts one value. By doing so, you make impossible states impossible. Another question to ask is which parts of the component can be isolated? Because if they can be isolated, it might make sense to make them into smaller components that can be reused in other contexts. And not everything in your component needs to be defined ahead of time. Web components allow content to be inserted into predefined slots. Typically, the component doesn’t care what goes into the slot. So you can give people using your component a lot of flexibility by defining where they can insert content and then let them do what they need to do. In the same vein as making impossible states impossible, I believe we should make inaccessible states impossible whenever we can.

By default, all of our components should be accessible. This should be a foundation in our work. In this example from a recent project, we built a dropdown menu for our client that is accessible. We made sure it contained ARIA roles where it makes sense. We tested using screen readers to make sure the experience was as good as possible. And this dropdown component has a trigger element that opens and closes the dropdown. We wanted to make sure the trigger element was either a button or one of the components we created that would be suitable to trigger the dropdown. If it was any other component or any other type of element, it probably wouldn’t be accessible. So if someone tries to use the dropdown with a div, it won’t work. We make sure the component actually just fails and we put an error in the console to let the developer know that they need to either use a button or one of the components we’ve identified as accessible alternatives. Just keep in mind that just because you’ve built in accessible components or you’ve built accessible components doesn’t mean that the end result is accessible. You can take a page full of accessible components and stitch ’em together into a way that actually doesn’t make it accessible. So you still have to test the final page. But if you bake accessibility in components, you’ll create a solid foundation for other people to work from. And you can also solve really tricky accessibility issues once and everyone in your organization will benefit.

I suspect some of you’re feeling what I felt when I first started looking at component-based design systems. This feels like more work. It is more work. It’s undeniable. We’re going from something like this in a CSS-based design system to something with this level of complexity. And frankly, as Nathan Curtis points out, design system UI will always take more time and be more expensive than UI for specific sites or areas within a site. That’s because design systems require higher quality and require more engagement. A design system has to meet or exceed the standards of every adopting team. Otherwise, the developers on the team will think they can build something better and they’ll ditch the design system. And the people working in design systems have to take into consideration how feature will work across multiple teams, which means they have to engage with all of those teams in order to solicit input before they can release a feature.

So the design system work is always going to be more work, but component based design systems are worth the extra effort. The teams that adopt design systems going from needing to do all this integration work to adding a custom element and letting the component handle it, the adopting teams can get incredibly complex functionality like this model without having to build it themselves. And once a model is built and codified in the design system, everyone in the organization benefits from all the time and effort invested in it. You just need to make sure you adjust your project schedules accordingly. I know we’re gonna be talking to clients about how to build, how building component based design systems will speed up their integration and it’ll make their developers work faster and be able to do more specific things in the individual teams, but that they might have to wait a little bit longer to get the components and the scope is going to be larger than it was for CSS-based design systems. That just seems to be inevitable with components.

To close, I want to talk about what may be my favorite thing that the W3C has ever published. Earlier we looked at the web platform design principles. The very first principle is put user needs first. The section goes on to say, if a trade off needs to be made, always put user needs above all. Similarly, when designing an API, be sure to understand and document the user needs that the API attempts to address. The internet is for end users. Any change made to the web platform has the potential to affect vast numbers of people and may have a profound impact on any person’s life. And then comes my favorite part, the priority of constituencies. User needs come before the needs of webpage authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.

Even now, this resonates with me. I get goosebumps reading it. I I doubt that it’ll show up on the camera, but the hairs on my arm are standing up. I think what I like most is it grounds me in what matters most. Particularly when we’re tackling complex challenges or battling browser bugs, as web authors we’re, we’re working in the service of others. The extra time we spend to make sure our user experience is intuitive and fast, that extra time’s gonna be vastly outnumbered by the time saved by thousands of people interact that with our work. We take on that pain so users can have an easier time. I used to think I was the only one for whom this section had special meaning. I mean, the first domain I bought was userfirstweb and that was long before I read this principle. So, kind of a bias I’ve, I’ve long thought of my job as advocating for users above all else, but I was pleased to learn that it, it resonates with others at Cloud Four as well.

It’s become a bit of a guiding principle for us. In fact, before the pandemic, we were in the early stages of having a mural pointed, painted in our office, featuring the priority of constituencies so that it could be present and at the forefront of our minds. Sadly this is just a mockup of what the mural might have looked like. We’ve gone remote first and we’ll never go back. We’re likely gonna close the office when our lease is up and so we’ll never have the mural. But the priority of constituencies, it still inspires us and I think it can guide design system teams too. So let’s try mapping the priority of constituencies to design systems. So users, they’ll remain the same. Authors refers to web authors, the people who create webpages. In the case of design systems, those are the component consumers, the people building things with the components.

Next we have user agent implementors. A user agent is a web browser. The implementors are the people who make the web browser. They’re 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’re the ones who make the component APIs a reality. The specification writers, well that’s the design system team. The people who define use cases, design the components and create the APIs for the components. And theoretical purity, it remains unobtainable, theoretical purity. Looking at this, it becomes clear how a design system team is a team that is in service of so many others. To my way of thinking, that means that design system work is incredibly noble work. When your work is devoted to making the lives of many other people, both your colleagues and end users, easier, the work you do has tremendous impact. So let’s update that original principle, based on these translations. I present to you the design system priority of constituencies. User needs come before the needs of component consumers, which come before the needs of component developers, which come before the needs of the design system team, which comes before theoretical purity. That, my friends, is a mighty and lofty principle to aspire to. Thank you.