Sarah Federman talks with Joel Hooks about accessible design systems
Design systems are your component library, documentation, tools, et cetera. And then there are the operations of it. So like an agile team uses agile methodology, a design system is about making your teams work better.
After Bootstrap, we all ended up building our own Bootstraps. We all like to think that we're special and the problems we're solving are specific to our company, but the reality is the way that your system is built is probably not that special. It's the way that your system is used that's special.
Everybody should be able to access your products, and you can't just make a bunch of accessible components, you have to give your users guidelines on how to use them. Sarah says that accessibility should be considered in every step of development.
"Accessible Design Systems With Sarah Federman" Transcript
Joel Hooks: Hey Sarah.
Sarah Federman: Hello.
Joel Hooks: How are you doing this afternoon? It's not afternoon. That's part of what I want to talk about, actually. You are not in the U.S. You are in Australia.
Sarah Federman: It is morning. It is past the point at which I should have had my coffee, but yet I have not.
Joel Hooks: Oh, podcasting pre-coffee, that's a brave move. I don't know that I could do that. So I'm really excited to talk to you about design systems and design tokens and you know the work you're doing in that area.
Joel Hooks: But I wanted to actually stop first and talk to you about this idea, because you moved around the globe basically and you packed up and moved to Australia. I was wondering what that experience has been like for you so far.
Sarah Federman: It's been a bit of an adventure. It's hard to say that it's like anything pretty crazy just because Sydney is very much a first-world city and I have almost everything I need here except for Amazon Prime, which is truly heartbreaking. But yeah, it's great. The people are nice here. They're kind of like New Yorkers, if New Yorkers were very nice. They're always willing to help you out and not be rude about it. It's great.
Joel Hooks: So just logistically speaking, I would be terrified to make that move and how do you get your stuff? How long does it take to settle in and are you settled in?
Sarah Federman: Thankfully Atlassian was really supportive and they got me a shipping container and took care of a lot of things like visas and whatnot. But my shipping container did actually just get here and I just had the movers come and pick up the empty boxes yesterday. So I would not say that I am settled in, but I am on the path to being settled in, thankfully.
Joel Hooks: Kind of one step at a time. So you moved to Australia to work on design systems with Atlassian and they have, I think, one of the more interesting design systems that I've looked at personally. How did you get into working with design systems in the first place?
Sarah Federman: Ooh, I think it's one of those things that kind of just happened just because it really aligned well with my skillset. I went to school for what's called new media design at RIT and that was a mix of UI, UX, animation, and a little bit of coding. I decided that I really liked the coding stuff. So I decided to go full time front-end development, ended up at LinkedIn, found I didn't really like working on core products.
Sarah Federman: So I ended up getting pulled onto a project where we did a full rewrite of the SAS code base at LinkedIn, which was fun. We got to bimify it and do all sorts of things that made me happy. I found out that doing more of that is a lot of design systems and I like that. And it aligns with my hybrid designer developer skillset. So I ended up landing at Adobe where I worked on their design system for a few years and now I am here.
Joel Hooks: Wait, so you said bemify. What does that mean? What does it mean to bimify a code base?
Sarah Federman: So we had a lot, a lot, a lot of CSS at LinkedIn. I think it was almost at four megabytes at one point which is just bonkers.
Joel Hooks: That's a lot of text.
Sarah Federman: And a lot of that came from the fact that we were just overwriting our styles and we had just so much specificity classes. So all of our CSS was just trying to overwrite each other and BEM let us take a lot of the specificity out of it. So it was one level of specificity, therefore we wouldn't have to override things as much. And that was really good as a starting place just to get the size of our CSS down and start to systemize things. And then they've been working, after I left, on taking that and evolving it into what is now known as CSS blocks, which is really exciting.
Joel Hooks: Nice. I want to rewind a little bit and ask you to define a design system. I'm curious, I see the word around and I wonder. It kind of cropped up over the last few years and I think everybody's kind of seeking to have some sort of design system. I'm wondering what a design system is, like fundamentally, what a design system is.
Sarah Federman: Ooh, this is a little bit of a-
Joel Hooks: Is it a loaded question?
Sarah Federman: Yeah.
Joel Hooks: What is a design system to you is fine too. We don't have to define it for the ages.
Sarah Federman: Yeah, yeah. I wrote a long article a while back called Distilling How We Think About Design Systems and it's been several years, but in that article, I basically laid out the fact that some design system teams define a design system as all of the outputs, like our component library, our documentation, and the sketch tools and whatnot, plus the whole operation of it. So how people learn about the system, how you support them, how it's integrated into products, the workflows, the governance, et cetera. So some people think of that whole thing as the design system.
Sarah Federman: Personally, I tend to err on the side of there's a design system and that is our component library, our documentation, our tools, et cetera. And then we have operations of it. So like an agile team uses agile methodology, a design system is about making your teams work better and that's pretty much what I do day to day.
Joel Hooks: So kind of like it's standard operating procedures in some way, but there's the visual aspect of it and the documentation is a huge component, I would say.
Sarah Federman: Yeah, definitely. I would say that it's a bunch of outputs and if you're including the operations in the system, it's also the methodology.
Joel Hooks: Is having no design system at all, is that a design system? Is it just a bad one?
Sarah Federman: I'm not sure you can have no design system and also have a design system. That doesn't quite make sense to me.
Joel Hooks: Maybe, I mean, there's people that are like, Oh you don't use a framework or have feelings about using extensive frameworks. But then I always feel like you're building a framework if you're not using one. I wonder if you don't have a design system but you have some sort of design in your product or whatever it is, the work you're doing in terms of web development, like there is a system, there's always a system. It's just kind of good or bad in some way.
Sarah Federman: Yeah, that's definitely a good analogy, the way that if you're not using a framework, you're still building a framework. You're just not doing it properly or you're not documenting it or supporting it. That's really what you're referring to when you have a design and there is a system there. It may not be a complete system and it may not be documented and it may not be supported, but it's there.
Sarah Federman: I would say that once you get to the point where it's obvious that is there and it's becoming a pain point, that is the point at which you might want to formalize it and start thinking about how you want to support and grow and evolve it.
Joel Hooks: That kind of makes me think, where do people start? How do you know when to start and where to start and when in either a product or a software project's journey is it appropriate to start thinking about these things?
Sarah Federman: Ooh, I am not maybe the best person to ask because I've always been working at Scale because that's what's been most interesting to me. But I would say that at the point where you spend more time talking to the people, if you're all in the same room and you've got one product and you have an understanding of the system that you're using, regardless of whether it's formalized, you don't need one.
Sarah Federman: It might be interesting to think about it in terms of if you're a startup and the one thing that you really need above all is speed to determine your product market fit, a design system might hold you back or it might allow you to evolve very quickly and try new things, which could be really good for your use cases.
Joel Hooks: Atlassian's design system is Atlas, is that correct?
Sarah Federman: It's Atlaskit.
Joel Hooks: Atlaskit, okay.
Sarah Federman: Well, so this is one of the things that we haven't really gotten, we're still figuring out. We have the ADG, which is the Atlassian design guidelines and we have Atlas Kit, which is our react library. It includes more than what the design guidelines include at the moment.
Joel Hooks: Yeah. When you go to atlaskit.atlassian.com, it shows all of that with the components. Like you said, the components and the actual SDK side of it is really important with the design system. Atlaskit is one of the more complete ones. And then Adobe, just really Spectrum. So that's new too, the Spectrum design system from Adobe. Is that what you were working on when you're at Adobe?
Sarah Federman: Yeah. So Adobe is a little bit different in that they don't have, how do I say this? So their design system is built on the design org. So the implementations of it are not necessarily complete because they start on the design side. So what they did is they released the documentation, which doesn't include the actual libraries right now, which I'm hopeful that they will release soon.
Joel Hooks: Atlaskit is something we could pick up and use where Spectrum isn't quite there yet, in terms of the components. We can still use it and there's ideas here and they're sharing information.
Sarah Federman: Adobe is at a scale that not a lot of companies are at. So they have so many different frameworks across all their products and so many different platforms that it's really not possible for them to have one official framework. Whereas we can have our official react implementation, it's hard for them to point to one library and say this is our design system.
Joel Hooks: So I think something that's interesting to me is, and we talked about when should you start or accelerating your startup and that sort of thing, and I'm wondering why not just pick up something like Atlaskit or work around something that exists? Because I look at Atlaskit and what I see, I'm a small business owner, and this would cost millions and millions of dollars to produce. And here it is, I can just use it and kind of jump ahead. And I was wondering what the drawbacks are to that or what kind of advantages that you might see in just picking up something that exists off the shelf?
Sarah Federman: It's interesting because that's kind of what we used to do with Bootstrap and then we all ended up building our own bootstraps. And it's interesting to think about because we all like to kind of think that we're special and the problems we're solving are really just specific to our company. But the reality is the way that your system is built is not probably that special. It's the way that it's used that's special, like the operations of it, like we talked about before.
Sarah Federman: And theoretically it would be really nice if we were all able to just pick something up off the shelf and start building on it. But I think the reason that that hasn't happened yet is because of the reason why we did it in the first place because we wanted to embed all of these opinions and decisions and things into our systems. So we don't have, at the moment, a really good white label design system out there that doesn't have any sort of built-in design logic that you wouldn't have to override so many times that it just becomes hard to maintain.
Sarah Federman: So I'm hopeful that either us or somebody else, like I know Ryan Florence is working on his Reach UI project, they release something white label that's easy to build on top of because so much of the design systems that we have, like Atlaskit included, has a lot of opinions and stuff built into it, which is great for us and for our vendors. But I probably wouldn't say that it's something that anybody should pick up and use.
Joel Hooks: I look at it a lot of times as inspiration. Because I'm trying to think about what should our design system look like. We use Bootstrap. Was Bootstrap a design system? Is it? It still exists, it's not like it's gone anywhere.
Sarah Federman: It depends on if you include the operation side. I would say that it's a part of a design system, I guess.
Joel Hooks: And you know, we use Bootstrap and picking that up initially was great, but then you also get kind of locked into that, right? So when you adopt a design system or you adopt a framework on the JavaScript side of things, it's a lot of buy-in and can be difficult to untangle later.
Sarah Federman: Yeah. And I would love to see something like a very un-opinionated Bootstrap that takes a lot of that stuff out and is systemized, but that doesn't exist yet.
Joel Hooks: So one of the things I love, and you mentioned Ryan Florence's work with Reach, and what I love about Reach is that he attacked the hardest components that we have to build and then really focused on the truly important things that are difficult and often neglected like accessibility as the first priority of the system. And I was wondering, why is accessibility and that sort of thing important to a design system?
Sarah Federman: Because it's the right thing to do.
Joel Hooks: That's true.
Sarah Federman: Everybody should be able to access your products. And it's interesting to think about in terms of design system just because they happen to be a single point of failure. But even with that, they're not a single point of success.
Sarah Federman: So we can build buttons that are accessible everywhere and if they're not accessible everywhere, they're broken everywhere, which is bad. But even if you make a bunch of really accessible components, you can't just tell your users, "Oh, our design system is accessible, you use it, and now your apps are accessible." You have to give them guidelines about how to use them.
Sarah Federman: And even within the React components, there are things that need to respond to other things. So Aria IDs that need to ... Like aria-hidden has to match the right ID. If it changes, expanded needs to change. So we can do things within our components to make them accessible. But nothing is fully accessible until it's really interacting with the rest of the things on the page in the way that the user expects.
Sarah Federman: There's other things to accessibility, like source order and color contrast and all these things that we can't control. So we can take it to a point, but there's still so much that we have to do to educate people on how to make their applications accessible. So I really hope that we're not over-relying on our systems.
Joel Hooks: Yeah. It's kind of like giving a really good checklist but then just only doing the things on the checklist and not thinking about the holistic problem that we're actually dealing with. And you know, Ryan and Atlaskit and these other tools are providing a baseline. But that doesn't mean we get to stop and we get to stop thinking about it. It's not done. It's just we have a foundation to work on top of. Is that fair?
Sarah Federman: Yeah, definitely. Yeah, and we did actually introduce a checklist at Adobe that I was really happy with as far as the design goes, like a checklist for developing components, which was nice. So we would never release anything that wasn't accessible.
Sarah Federman: And then I'm hoping that we can take that a little bit further on the user side and start to introduce guidelines on what kind of accessibility things need to be considered. I guess like an example might be if there's a form and then there's an error message, you'd probably need an aria-labeledby that has the ID that's connected to the other form elements. That's something that we can't really build in but needs to be provided by the user.
Joel Hooks: It's like testing and development standards at that point. These are things we need to test and these are things we need to make sure that are, in our definition of done, is a product development.
Sarah Federman: Yeah, and even just like in the way that we build our components, we need to be able to provide solutions for things like passing down ARIA properties into sub-components without spreading them across everything, which is actually a harder API problem than you'd think.
Joel Hooks: At what point should people start considering accessibility in their development process?
Sarah Federman: When they wake up in the morning and when they go to sleep at night. Literally at every step, I'm hoping that we can think about how we're making things accessible to our users.
Sarah Federman: I would say that before the development process, it should be in the company conversations when we're designing products. It should be in the design conversations. It should be in the PM's definitions of success, et cetera, et cetera, all the way down, all the way up.
Joel Hooks: I think in the U.S. there was a Supreme Court decision recently in this regard saying that blind folks do indeed have the right to access the Internet, which is a fact. And now there's this legal motivation that's going to kind of spread, I feel. Does that provide extra motivation? I don't think that should be our sole way of motivating people. But it's interesting to me that it's been legislated at this point. And I'm wondering what the fallout from that might be?
Sarah Federman: Yeah, I am not a lawyer and this is not legal advice.
Joel Hooks: Sure. Me neither.
Sarah Federman: What I heard from a conversation that I had with somebody recently was that this is always been the case. What happened in this particular case is, I think it was Domino's was being sued because their website wasn't accessible and they took it all the way up. They kept appealing it even though it's way cheaper to just fix your site. They wanted somebody to rule that it wasn't legally required to make your website accessible.
Sarah Federman: And part of this is just because the ADA, the compliance rules, don't specifically include web because they were written quite a long time ago. They were written vaguely in order to accommodate the evolution of technology and whatnot. And so since it's not distinctly written out, they wanted it to be ruled that it wasn't required.
Sarah Federman: What happened is they tried to bring it all the way up to the Supreme Court and the Supreme Court was like, "No, we already know that this required. We're not going to hear your case." So the fact that it got thrown out is what people are really excited about because it's really just a validation of what we already knew, but on a really grand scale.
Sarah Federman: So I'm not sure that it really changes anything so much as brings it to a national stage, which was really good visibility. It makes people more aware of their responsibilities, whether or not it's enforced.
Joel Hooks: Yeah, I think that's it. That's definitely a different story. Thank you for the clarification because it's like something that I caught in a headline and that was interesting. But that's a good way to put it. And to me, so I was a forensic animator and I worked for law firms and often we would be against the large corporations. They had these infinite deep pockets and will say no, no, no and spend a hundred times, a thousand times, more money fighting something than it would cost just to fix it. And that's always amazing, just as an attitude, to me that you would do that. But I guess when you have lawyers on retainer, you have to pretend.
Sarah Federman: Yeah. I mean if there's a moral stance that you want to take, it's just they took the wrong moral stance. But yeah, we were all holding our breath just because we knew that this could overturn a lot of really good things that we've built for the accessibility community because running up the Supreme Court in the U.S. is not really stacked in a way that allows for progressive, accessible legislation.
Joel Hooks: What's a design token?
Sarah Federman: Oh, I would say that a designed token is just a variable that defines key design data. That could be a lot of things. And usually it's a design token when it's cross-platform. So the way that a lot of people use design tokens is to define things like global values of color and spacing and typography. And then they might export those to other platforms like CSS or JavaScript or Android and all of these different products can consume the single source of truth and get some consistency and the ability to change those things down the line.
Joel Hooks: So we have a package that we share across all of our projects that has the common colors that we use and our break points for responsive work. And so those would be tokens.
Sarah Federman: Mm-hmm (affirmative).
Joel Hooks: Okay. I want to close out just by asking you, when do design systems go off the rails? And what have you seen as like common pitfalls that people face? I know you work on these bigger systems at Scale, but what kind of advice would you give in terms of what to look out for and know that things are maybe going a little sideways?
Sarah Federman: Ooh, so many things. I think most of the time things go sideways, we see it in our tools, but it's actually a symptom of the way that we're interacting with the system and the way we're interacting with our community. So an example might be things have gotten really out of hand and hard to maintain and you're breaking people's products and people are mad at you because of it.
Sarah Federman: I would say that a lot of the times it's because we've made things too flexible without thinking about who we were building for. Because that's just really a symptom of the fact that we're not really communicating with our customers as much as we need to. So sometimes it's easier to build in every option than to talk to our users and find out what the actual use cases they need are and then plan for that and then decide whether that should be a new variant or it should be a new component and then get that in the system and evolve it. And it's hard. Like that's the job. It's really hard.
Sarah Federman: So if we're all trying to support somebody who really needs to get a deadline out, we might just build it in regardless of whether it's like the right thing for our system overall. And those kind of small decisions can add up and lead to a lot of different problems down the line. They're hard to test, hard to maintain, easy to break.
Joel Hooks: I feel like systems in general, like frameworks or design systems or whatever, they share that trait as projects grow and the exceptions kind of affect the rules, I guess.
Sarah Federman: Yeah. I think the hardest thing for me in design systems is just maintaining that balance between how flexible you want to be and how constrained do you want to be. It's all just connected to the way that people see you and your system. If you're too constrained, they're not going to like you because it's hard for them to do things they need to do to ship their products. If you're not constrained enough, you might break things without meaning to or you might defeat the point of your system, which is to make your designs more consistent and the products better to use.
Joel Hooks: Yeah, well said. Sarah, thank you so much for taking time out of your morning to chat with me. I really appreciate it. I learned a lot and I look forward to seeing what you do next.
Sarah Federman: Awesome. Thank you for having me.
Joel Hooks: Cheers.
Sarah Federman: Cheers.