How my teams work together
If you're here, you're probably looking to learn more about how I run the accessibility, performance, and design systems teams. I could spend a long time talking about process creation and stakeholders, but I think a better way is to just use an example!
Let's say we have a button, the most basic component of the web. It says "Save for later."
In my experience, quality is decided at several different checkpoints and by different people. To be clear, this is a good thing! We don't want our users to have a great accessible experience but wait 10 minutes for a save operation, because they're just going to leave for a different reason.
The button
Here's the button. Try it with a mouse, a keyboard, or a screen reader.
What each team did for this button
- Defined once: the color, size, spacing, and focus style come from the design system, so this is the same button used everywhere else.
- Understood by everyone: it's a real
buttonelement, so a keyboard can reach it and a screen reader announces it as a button. What happens when you press it is announced as a status message. - Fast enough to feel instant: it responds right away with "Saving…", even when the save itself takes a moment.
- Reliable: if the save fails, it says what happened and what to try next. Use the checkbox to see it.
Defined once
The button exists as a single component, so the right decisions get made once and inherited everywhere: color, size, spacing, focus style. This is the design systems work, creating reusable and structured tooling, while staying flexible enough to cover most of what our consumers need.
Our design systems engineers work directly with designers, performance engineers, and accessibility professionals as they develop. This helps us ensure that our system is actually working as a system, and not just a component library. If there isn't parity across the design and development language for properties or sub-components, concepts get lost in translation easily. We want to create good experiences while building and while consuming the system, for all users.
If a component in our system gets too granular, it becomes too narrow to be useful. If we required that our button be red, there would only be so many places we could use it. That said, we also don't want consumers to be able to add an icon to a button and not provide an accessible name. We have to make sure that we are building a stable and flexible system here.
Understood by everyone
Our button uses a button element, so a keyboard can reach it and a screen reader announces what it is. Pressing it performs the save action as expected, and any success or error messaging is announced by screen readers. It's big enough to hit reliably, and its color contrast meets text and UI requirements. If this is a base button component we're talking about, we've also thought about properties to make it a toggle button, adding loading indicators, and how to manage the accessibility of icon-only buttons.
Questions like those last few are where having an accessibility team really comes in handy. Our acccessibility engineers are able to collaborate with the design system developers, for example when a component is being scoped out. Then developers can better assess feasibility of the requirements they need to meet, and we know we will get an accessible product at the end of the process.
While a lot of what I've cited here is about meeting established guidelines, having our button meet a guideline and having it work well for an individual are not always identical outcomes. My accessibility team and I care more about the second, because though guidelines may be well-intentioned, knowing how to apply them to improve a user experience is the real accessibility work.
Fast enough to feel instant
Pressing our button should feel immediate, which depends on what the button costs to load, what script it runs, and whether the page jumps around when it responds. It also depends upon our partners in other areas of the application, and our relationships with them to help address issues with APIs or data access.
As soon as we know what we're building, we want to talk about how we make it both fast and reliable for our users. This is where performance engineers can help not only identify tooling and best practices, but also set up metrics tracking for specific use cases or create new utilities where they might be needed. This enables us to build features and fix bugs faster with the confidence that the output will provide a good experience.
In front-end performance work, our goal is to make the interaction feel as immediate as possible for our user. That might mean the save function itself is slow, but we show a loading indicator. In other functions, we might have the page update optimistically to show loading content sections, for example. Feeling fast keeps users around when actually being fast can't happen.
We also want our work to be reliable. If the button's save operation hits an error, we need to make sure the user knows what happened. They'll also want to know if they can fix it, or if they need to reach out for help, and to who. And what happens if the button can't load? At the root of all of this is ensuring we don't write code that will break easily. Testing strategies and tooling can help us here, and that requires its own planning.
Combining disciplines
Even though we have experts to test each of these checkpoints, teaching others how to approach work in the ways we approach it is a major factor in my teams' success. We pair with developers and designers, create resources and documentation, and share best practices and issues often enough that the folks we work with are consistently learning alongside us. That goes for my team members, too. Design systems developers, performance engineers, and accessibility specialists are all working together and learning from each other consistently. Without that system of support, silos form and it's easy to have collaboration stall out.
Back to the button
At the end of this journey, we release our "Save for later" button and someone presses it.
It's (almost) the same button they've pressed everywhere else on the site, because it's defined once. If they're using a keyboard or a screen reader, it works seamlessly and doesn't produce any surprises. It quickly updates to show progress on the save interaction, and when it fails, users get clear messaging about what happened and what they could do about it. If we missed any of those checkpoints, one of our users would eventually be left in the lurch.
When all of it works, the person pressing the button doesn't think twice about it. That's the goal. We want the user experience to feel like it was exactly the seamless, quick, simple process they expected. Even better, if possible!