Preview: You’re not going to be creating new visual styles for every design anyway, and you probably shouldn’t be if you’re working on a product company. I would go as far as to say that it is not problem solving if it doesn’t have constraints, it’s probably just art.
[Music]
Lea Alcantara: From Bright Umbrella, this is CTRL+CLICK CAST! We inspect the web for you! Today, Sarah Federman joins the show to discuss designing for a modular system. I’m your host, Lea Alcantara, and I’m joined by my fab co-host:
Emily Lewis: Emily Lewis!
Lea Alcantara: This episode is sponsored by Arcustech who hosts this very show. Have Arcustech’s helpful support team manage serves for you so you can focus on designing and developing client sites instead of getting stuck with sysadmin work. As an official Craft CMS hosting partner, they have various plans optimized for Craft, and you can pick between two US locations and the EU, too. Sound good? Take 15% off the first three months of your single or multi-server monthly plan with a discount code CTRLCLICK118. We’ll spell it out in the show notes. It’s valid until the next episode airs so sign up today.
[Music ends]
Emily Lewis: Design systems and modularity are huge trends in both web design and development. Today we’re going to dive into the design-designer perspective with Sarah Federman. Sarah is a design engineer who loves applying systems thinking to solve product problems. Previously, a UI engineer at LinkedIn, she’s currently using her diverse skill set to help create the design system at Adobe dubbed “Spectrum” with a special focus on inclusive design and design operations. In her free time, she’s often making jewelry or drinking whiskey. [Laughs] Welcome to the show, Sarah.
Sarah Federman: Thank you so much for having me.
Lea Alcantara: Absolutely. Can you tell our listeners a bit more about yourself?
Sarah Federman: I think you guys covered a huge chunk of it.
Lea Alcantara: [Laughs]
Sarah Federman: But I’m plugging in from San Francisco today where I am working from home with my lovely cat, and yeah, I don’t know, in my free time I like to make jewelry and sometimes I fence because swords are cool.
Emily Lewis: Oh.
Sarah Federman: [Laughs]
Emily Lewis: [Agrees]
Lea Alcantara: Nice.
Sarah Federman: And that’s about it.
Emily Lewis: How did you get started working on the web?
Sarah Federman: I kind of fell into it actually. I think it’s an age old story of a girl on the internet playing Neopets. [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs] I love it. I love it, yeah.
Sarah Federman: That’s pretty what happened.
Lea Alcantara: That’s amazing.
Sarah Federman: I was a little bit after the MySpace layout era, but that still happened.
Emily Lewis: Was LinkedIn one of your first jobs, or was that something that you kind of built your career up to working for such a large organization?
Sarah Federman: Yeah, so I originally started out thinking that HTML and CSS was more of a graphic design thing.
Emily Lewis: [Agrees]
Sarah Federman: So I went to a community college for graphic design, and that ended up just kind of being more on the visual design side, which obvious, looking back. So I ended up transferring to RIT (Rochester Institute of Technology) for new media design, which is a little bit more of a mix of interactive design, 3D animation and a little bit of code, and I feel in love with the coding part.
Emily Lewis: [Agrees]
Sarah Federman: So I ended up doing that more on the side. So I did an internship at Adobe where I did both web design and development, and then I moved into software engineering on the UI side at LinkedIn once I graduated, and I stayed there for about a year, and then I moved back to Adobe where I do more in the middle. So I’m a design engineer, which means I do a little bit of both.
Emily Lewis: Cool. I like that. I like a little bit of both myself.
Sarah Federman: Awesome.
Lea Alcantara: And I think that’s really kind of the best way to approach the web, isn’t it?
Sarah Federman: Right.
Lea Alcantara: I mean, despite all the debates and everything like that, a little bit of both never harms anyone on the web industry.
Sarah Federman: [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: Right?
Sarah Federman: Yeah. I like it because I get to kind of. I think about it as like I’m engineering the design process as a design engineer and so it’s like kind of a little bit of both.
Emily Lewis: Yeah, and I mean, Lea and I find this now that we work together because she does design and I do development, but her knowing a little bit about what I’m doing and me knowing a little better about what she’s doing means that “handoff” or whatever is just such a more seamless process when it moves from that more visual phase to the coding phase.
Sarah Federman: Absolutely.
Emily Lewis: Right. So let’s dive into today’s topic. Let’s start with an obvious question that seems to get a lot of debate, what is a design system? Is it the same as like a style guide or a pattern library?
Sarah Federman: I think the best approach to kind of define it is just like more of an evolution of a style guide. I mean, the difference between a style guide and a design system is really just what you call it. There’s no real design system or fake design system or like wannabe design system.
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Sarah Federman: And so it’s really just about taking your style guide to the next level and kind of a mindset change. So your style guide is usually kind of components, styles like text and typography and colors and stuff, and then taking those guidelines on how to use it, and really the mindset is about just how it integrates into your process and how it affects the way you work at a company, and I think design system kind of encompasses all of those mindset changes. So the way that I personally define it is just like a tool or a collection of tools for designers and engineers at your company to create more effectively, efficiently and consistently.
Emily Lewis: [Agrees]
Lea Alcantara: It really kind of reminds me of how old school print brand guidelines operated, like theoretically, at least, where they had its own components and then you’re supposed to apply it more consistently throughout whatever print materials, and now it seems like design systems is the digital evolution of that concept, but it’s taken awhile for the web to consider this like pretty established workflow in the print world.
Sarah Federman: Yeah. I think it’s in part because of the way our tools are set up. It’s just the way that we work now in components doesn’t really jive as well with a lot of the existing products out there for design.
Lea Alcantara: [Agrees]
Sarah Federman: And as React became really popular on the development side, we became more component oriented.
Emily Lewis: I feel like we’ve talked on the show a bit about the benefits of modularity, but what are the benefits of a design system, especially one that has that sort of component modular approach?
Sarah Federman: So I think that I guess for me modularity is kind of implied in the definition of a design system.
Emily Lewis: [Agrees]
Sarah Federman: Because when you’re designing with components, in general, that just gives you the opportunity to mix and match and apply different things to different situations. I would say that it’s probably the biggest positive for design system. It’s just to be able to compose things modularly. That’s a big word. [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: Can you like help me envision like an example of a component in a design system and how that would almost make someone’s job more efficient or easier, like put it in a real-life scenario?
Sarah Federman: Yeah. So think of like maybe a form. A form usually consists of like labels, inputs, dropdowns; all of those different parts are components in the system, and when we use those components, we don’t have to think about all of the different states that are included in something like that because it’s already part of the system. So error messages are prescribed. The required and optional annotations, all the different parts of like having to design a form that would really be hard in a normal situation where you’re designing from scratch, we can now take from our system and kind of take the implication that we’ve already set.
Emily Lewis: Is that something that everyone is going to be able to benefit from?
Sarah Federman: Absolutely. It saves so much time on the design side and it lets them iterate quickly, and on the development side, it also saves a bunch of time, and if your library is constructed, well, you don’t have to worry about testing or internationalization as much, all sorts of savings.
Lea Alcantara: [Agrees]
Sarah Federman: Even on the PM side, I mean, it’s so much easier to estimate the tasks for things and you don’t have to account for like endless visual iterations and stuff.
Emily Lewis: Yeah. I mean, I even feel like before when I was just by myself and freelancing, that these kinds of tools are beneficial to even someone who is technically working by themselves, but they’re working on many different projects over time, so all of those projects can borrow from the concept of that freelancer’s design system.
Sarah Federman: Yeah. And the way that we’re starting to do things now where we kind of make everything a variable with the concept of design tokens, which is basically just like creating variables for design values so like your colors and your texts and your type, all that stuff. If you swap out those variables, you can basically create however many iterations of a design system you need.
Emily Lewis: [Agrees]
Sarah Federman: So it’s really helpful for things like freelancers who might want to be seen differently, depending on the client.
Emily Lewis: And then it must be hugely beneficial at a large organization that has a lot of different people, including new people who need to come up to speed on things to have a shared, not just system, but even vocabulary.
Sarah Federman: Yeah. I would say it’s pretty much impossible to design consistently and scale like in Adobe without a design system. It’s just too manual, you can’t do it.
Lea Alcantara: So with all of these, you mentioned that this definitely works even for freelancers for saving time for future projects and obviously there’s the large organization with the benefits, but is it always relevant? Is there ever a situation where do you really need a design system, or is it really just like a methodology?
Sarah Federman: I think it lives on a spectrum, depending on what your needs are, which is the number one thing to be aware of.
Lea Alcantara: Sure.
Timestamp: 00:10:01
Sarah Federman: For a smaller company where all the designers are in one room and you’re doing like weekly critiques and stuff, I don’t think that you need to take it that far. I mean, it might be that a shared Sketch file is just enough for you.
Lea Alcantara: [Agrees]
Sarah Federman: It’s really about like whether you want to take it as far as you can, and it’s actually quite interesting because a lot of the smaller companies we are seeing the most interesting things happen in design systems.
Lea Alcantara: Oh.
Sarah Federman: Because while we’re trying to like take all these components and create all these different scenarios for different tech stacks, they’re innovating on the tooling, which means that they can like really experiment with things that we haven’t even had a chance to get to.
Lea Alcantara: Do you have an example of one of those innovative ways?
Sarah Federman: Yes. So at Adobe, we have about like six or eight tech frameworks that we use at any given time.
Lea Alcantara: Wow.
Sarah Federman: Yeah. We’re developing for React. We’re developing for iOS, Android, all those things, whereas Airbnb, up until recently, was only developing for React, and that was React Native and React Web, and they were able to create tools like React-Sketch App, which previously wouldn’t be available to somebody like Adobe because we’re not just React, you know.
Lea Alcantara: Okay, all right. So I feel like that touches on some misconceptions about design systems and how they could be applied and all that fun stuff. Are there other large misconceptions about design systems you’d like to share?
Sarah Federman: Yeah, I think I guess one of my pet peeves is when people say it blocks your creativity. [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Sarah Federman: Okay. I don’t think it does, but I think that the assertion that it could kind of comes from a misconception of like what product design, in general, is because we’re giving you a bunch of clothes in the closet and the way that you’d put them together is up to you.
Lea Alcantara: Right. That’s a good analogy.
Sarah Federman: We’re not telling you to design your own clothes, and that’s really what I think that people are talking about when they’re talking about creativity in design because you’re not going to be creating new visual styles for every design anyway and you probably shouldn’t be if you’re working on a product company.
Emily Lewis: Yeah. I mean, because especially when we’re talking about products here, you have to be thinking about the user, so you’ve given thought and research into the choices made to support that user base, that it’s accessible, that it’s inclusive, that it’s just usable, and that should be the kind of thing that is embraced versus, well, it’s stifling.
Sarah Federman: Yeah. And we’re making the job easier. [Laughs]
Emily Lewis: Yeah.
Lea Alcantara: [Laughs]
Emily Lewis: And I just want to mention that I had a misconception until Sarah just now sort of touched on it with when I heard the term “design system,” I just think of something very massive, and I appreciated you kind of discussing that scenario where it’s really up to you to define, so a small team who are off geographically close or physically in the same office may only need certain assets, like it’s defining what it is to you.
Sarah Federman: Yeah. And like even at like any company, you probably already have a design system that you just might not be aware of.
Emily Lewis: [Agrees]
Sarah Federman: So like there’s obviously some designer somewhere that’s like collected all these assets that they reuse just because that’s what you do, like you don’t do extra work unless you have to.
Lea Alcantara: Yeah. The comment that I wanted to mention, taking a step back over what Sarah mentioned, was her pet peeve. Because I think a general misconception about what design even means, I think a lot of people still think that it’s just making things look pretty and then so having certain standards means like, “Oh, now, I don’t have the creative potential to make it look pretty or whatever [laughs] when design is both a strategy of function and a process. Like as Emily mentioned, it’s trying to fit the needs of the user and seeing what happens, and also design works best with constraints.
Emily Lewis: Yeah.
Lea Alcantara: And to me, I think that’s what design systems provide.
Emily Lewis: Yeah. I was just about to say I feel like constraints actually encourage creativity. Do you know what I mean, with the solutions you come up with?
Lea Alcantara: [Agrees]
Emily Lewis: And this is development, too. I think this is in a lot of areas of life, professional and personal, but when you have constraints, you’ve still got to solve something. So what you come up with is probably even more creative than if you could have just done whatever.
Sarah Federman: Yeah. I would go as far as to say that it is not problem solving if it doesn’t have constraints. It’s probably just art.
Emily Lewis: [Agrees]
Lea Alcantara: Right. Right.
Emily Lewis: Nice point.
Lea Alcantara: I also wanted to touch on a misconception that you wrote on, the article you wrote on Medium, about design systems, and it was about consistency.
Sarah Federman: [Agrees]
Lea Alcantara: So since we were talking about creativity and then how some people feel like it’s nice to have constraints, and I think part of it is also because people’s understanding or misunderstanding of what consistency means. So Sarah, could you expand a little bit about that?
Sarah Federman: Yeah. So I’ve had a few discussions with people out there that kind of they fixate on the word “consistency” as it meaning that everything is the same everywhere, which is really not how we approach it, and I think it’s our job as the design systems team to communicate that effectively.
Emily Lewis: Right.
Sarah Federman: But the way that we feel about it is like mobile experience is a mobile experience, but generally, the experience that your users go through when they’re completing a task or just navigating your ecosystem is the same across the board. So it’s familiar and it makes sense regardless of the user’s context.
Lea Alcantara: I think that’s a good way to approach it. I think the familiarity – oh my gosh, I can’t speak.
Sarah Federman: [Laughs]
Lea Alcantara: Familiarity. [Laughs]
Emily Lewis: Familiarity.
Lea Alcantara: Which reminds me, to me I feel like I look at design systems like a family, right?
Sarah Federman: [Agrees]
Lea Alcantara: We all come from the same gene pool, but that doesn’t necessarily mean we all look exactly alike or behave exactly alike, but there’s consistency within a family, and that’s kind of like a design system, too.
Sarah Federman: Yeah. We want you to know that you’re on an Adobe product and have an idea of how to navigate it.
Lea Alcantara: Yes.
Sarah Federman: Because it’s an Adobe product.
Emily Lewis: Because it has that familiarity.
Lea Alcantara: Yeah.
Sarah Federman: [Agrees]
Emily Lewis: So you sort of touched on it already that you feel like it’s almost inherent for a design system to be modular. Can we talk a little bit though about this modularity? Why that that’s a beneficial way of sharing these rules? How that makes it easier and more efficient?
Sarah Federman: Yeah. Can you expand a little bit more about what you mean by modular here?
Emily Lewis: Yeah. I guess maybe perhaps people who are familiar with design systems, like a formal design system, may take it for granted that it’s modular, so someone who is new to this idea of looking at their work in a componentized way, looking at it for patterns and such.
Lea Alcantara: Versus age.
Sarah Federman: [Agrees]
Emily Lewis: Yeah. Or versus even a project direction, but looking at things even on a bigger level, if that makes any sense. Does that help?
Sarah Federman: Yeah. That’s interesting because for me, it’s a little bit harder to take that away because as a developer, we’re always thinking about that anyway, even in it’s in page, because like it’s the concept of “do not repeat yourself” drive, which has been around for forever.
Lea Alcantara: [Agrees]
Sarah Federman: So I don’t know if I personally experienced that, but I feel like with the design system and the way that it’s organized that like if you provide sufficient examples as well, it’s really easy to communicate that everything is just a sum of its parts.
Lea Alcantara: [Agrees]
Sarah Federman: And all those parts are divided to by the system.
Emily Lewis: Yeah. I mean, I think I can speak to that kind of not looking at things very modular. I mean, I’ve been doing this long enough that having taught myself, but that really wasn’t how we started building or we as me, and it’s only been I the past probably six or so that I really tried to embrace DRY, that I really tried to componentize what I did.
Lea Alcantara: Right.
Emily Lewis: And because I think how I would describe it before is I would copy everything from a previous project when I would start a new project, and then I would sort of finagle from there, and what I have now evolved to is instead of looking at it, I’m just going to copy from the previous project, we have our own design system. It’s more on the front end versus literal like visual patterns, but the coding patterns.
Sarah Federman: [Agrees]
Emily Lewis: And then, of course, like the variables for styling and such, but that was an evolution, that that was not something that was a natural approach to me. I see now the efficiencies of it, so instead of copying everything from the previous project, I reflect on what I did for that project that could be updated in the modules that were relevant for that project, so that it moves forward. But yeah, I did look at things as not modularly. It wasn’t components. If you will look at a 20-year career in this, that’s still a relatively new idea. [Laughs]
Lea Alcantara: Yeah, absolutely, even like in the CMS world. Right now, a lot of CMSs have the DRY technique where it’s like you’re trying to separate like layouts with all these other micro-components, but it used to just be whole pages.
Emily Lewis: [Agrees]
Lea Alcantara: Like as in you’re just going to duplicate every single page and then change little things here and there and it was quite cumbersome to make what seemed to be minor changes to apply to the rest of the site, and all of these is, let’s say, is that this is still relatively new for people to wrap their minds around. That’s why we have this episode to make sure that people understand and open their minds to like a different type of way of thinking. I mean, for only like, what, a few years ago that people even started seriously taking mobile design seriously, that kind of stuff.
Timestamp: 00:20:20
Emily Lewis: Yeah. And especially for our freelancers out there who I’ve been in that boat before, too, where if you’re not working with a whole lot of other designers or developers, but you’re sort of a team of one building for your clients, I know I got really caught into patterns habits that upon reflection were really not efficient, you know?
Lea Alcantara: Yeah.
Emily Lewis: I could have made more money if I was heading this direction than we are now in terms of how I develop, but it was a comfortable habit.
Lea Alcantara: Right.
Emily Lewis: And there was nothing else pressuring me from the outside to sort of try something different; it was working, and so it’s also okay if that’s where you and you’re just trying to like kind of step outside that a little because maybe you want to make a little bit more money with more efficient use of your time.
Sarah Federman: Right.
Lea Alcantara: But this also emphasizes that right at the beginning of this episode, we were talking about how it’s like a little bit of both is good.
Sarah Federman: Oh, yeah.
Lea Alcantara: Because it is. This entire conversation really highlights the fact that the development reality has kind of pushed the design functionality, right?
Sarah Federman: Interesting.
Emily Lewis: [Agrees]
Lea Alcantara: Because the more ambitious people got with websites and apps and all those kinds of things, it just was hard to update when it seems like you’re designing from scratch. So it kind of like out of necessity, they’re like, “We need to simplify all of this so that both design and development can move forward without everything stopping.”
Sarah Federman: I think that single source of truth (SSOT) kind of concept is really just what I’m personally interested in most.
Lea Alcantara: [Agrees]
Sarah Federman: Because I think it enables a lot on the design side and the development side, and it’s like maybe it does slow you down at the beginning, but once you have a single source of truth, all of your design files are like they’re just easy to iterate on. It’s not about the constraints, it’s about being able to iterate as quickly as possible and just like swapping things out, trying new things. It’s not as constraining to me as it was when I had to DRY everything out each time.
Emily Lewis: Yeah, and just to kind of riff off of that a little bit, I mean, Lea, I feel like starter files is a design system, right?
Lea Alcantara: Yeah. I mean, it’s technically a style guide, but it’s the starting point of a design system really.
Emily Lewis: Yeah. So our listeners know I referred to this before, but my starting framework for all of our code I call starter files, but iterating on them versus like having to start from the scratch each time, like I feel so good about how well tested that approach is, like I’ve tested it so many times. I’ve improved it when I find new things, like so a single module, a system of 30 modules that have had that sort of attention to detail and that sort of supporting like you said, it’s a single system that’s being supported, like I feel so good about using it each time moving forward. It’s just something I know is in just great shape.
Lea Alcantara: And it’s less intimidating to iterate on, right?
Sarah Federman: [Agrees]
Lea Alcantara: As opposed to like, as you mentioned, your old school way of, “Let’s just copy this entire old project and then try to add something new to it,” but then there are just so much to review versus it’s like, “Hey, I found out this new accessible way to improve this form widget. I will just edit this one form widget.” You know? [Laughs]
Emily Lewis: [Agrees]
Sarah Federman: And I think that’s really one of the main benefits, such as using a system like this and just being able to change and update and iterate things effectively across your entire team. It’s such a hard problem without a single source of truth.
Emily Lewis: Well, I think that’s a perfect segue to talk about who on a team should be involved in the creation of a design system. Are visual designers a part of this? Are these UI engineers, front-end developers? And you mentioned project managers at the beginning, is that someone who should be involved?
Sarah Federman: Yeah. So I think that different companies start differently, but you’ll often see that there are even competing standards.
Lea Alcantara: Yeah.
Sarah Federman: Because like both designers and developers want this, and sometimes it actually happens organically on the developer side in like an internal tools theme or on the design side with some person just trying to reuse mocks, and that’s actually a situation that we went through at Adobe, and our solution was just to bring everybody together and getting designers and developers together in the same room means that you’re meeting everybody’s needs, and I think as you grow, it’s actually really, really beneficial to have a PM, like a product manager, because when you’re treating a design system like a product and you have a roadmap and you have all these different goals that you’re keeping track of with a system, that’s the way that it lives on, and it lives within your company with people contributing to it and just all these different factors as you grow and as you move along.
Emily Lewis: [Agrees]
Lea Alcantara: With all those moving parts, really it’s still kind of confusing to me what the first step is then in creating a design system. What would be the first step, Sarah?
Sarah Federman: You know, I think, okay, I’m saying this again, but again, it depends, and so like what is your… [Laughs]
Lea Alcantara: [Laughs]
Sarah Federman: What is your biggest like pain point, and if it’s just everybody creating too much code and you’re getting performance issues from it?
Emily Lewis: [Agrees]
Sarah Federman: Or is it your designs are confusing and your users are having trouble navigating your app, it really should inform the way that you start, or even just who has extra time and bandwidth to start this on your project.
Lea Alcantara: [Agrees]
Sarah Federman: And I don’t know. I think it really just comes down to what you think is a good place, and usually on the design side, I would say it’s just creating a basic Sketch file or XD file or anything where you just have a sticker sheet or you are adopting an existing design system out there and just getting it the way that you like.
Lea Alcantara: So with that in mind, what would be the most important component of a design system? What are the components of a design system?
Sarah Federman: I think that there are table stakes components like buttons and inputs, headers, typography, all these things that are part of your identity are a good place to start, but what happens when you get past that part is you really focus on what is unique about your product and what makes your design system unique. Dan Mall recently talked about this in his Distinct Design Systems article. The interesting part of this system comes when you start getting past the table stakes and you start working on things like, for example, Yelp has their rating system with their stars.
Lea Alcantara: [Agrees]
Sarah Federman: That’s a design system component that’s really unique to them.
Lea Alcantara: Right.
Emily Lewis: You know, I wonder right now, Lea, I’m thinking about one of our clients who they essentially I think when they said they wanted like a web style guide, in a lot of ways they want a design system.
Lea Alcantara: Yeah.
Emily Lewis: And that sort of builds off of what Sarah is saying, like what becomes unique beyond, I guess, those basics that are like required, and I feel like that starts getting into like even branding territory.
Sarah Federman: Absolutely.
Emily Lewis: Or even I guess how you put components together, too. Is that also how it sort of gets more complex, not just having the components, but which ones work well together to be extensible?
Sarah Federman: Yeah. A lot of systems once they get past those table stakes, they get to the point where they talk about compositions of components and how they interact together, and I think that’s also where a lot of the interesting work comes, and like how you transition between screens and how all of your different flows, like what’s your chat system, what’s your commenting system. Those are really interesting parts that really I think play into a company’s brand. It’s just how you present yourself to a user and what that says about you.
Lea Alcantara: So how do you document all of this? Because at the beginning of the show, you mentioned, “Hey, if you’re a small team, maybe you just share a Sketch file, and then you just talk to each other and say what’s going on.” But once that expands, how do you really easily and clearly communicate, “Okay, this is how this widget should be built and how this interacts with the rest of the other components.”
Sarah Federman: Yeah. There are a lot of different approaches. The one that we use is having an internal website.
Lea Alcantara: Okay.
Sarah Federman: And there are tools that you can use to build that, like Pattern Lab or Fractal. We have a custom solution where we just have our components in like a playground so you can actually play with them, and then we give you guidelines on what the different variations of the components are, how to use them, like dos and don’ts, like don’t truncate, et cetera, et cetera, in this situation, and then we also include keyboard considerations for each component.
Lea Alcantara: Awesome.
Sarah Federman: So how is the accessibility going to work for this component, and that’s designed to the system itself, and then we have styles where we have colors, animations and stuff like that.
Emily Lewis: And I feel like that is the perfect kind of documentation that you need when you are working with a lot of people, and I just want to put it out there to anyone who’s a little closer to what Lea and I look like, which is a much smaller team and also with limited resources, so we don’t currently have all the bandwidths to completely document in that kind of very detailed directed way, but that doesn’t mean we aren’t documenting.
Lea Alcantara: Yeah.
Timestamp: 00:30:00
Emily Lewis: So for me, for the starter files components, there are a lot of inline comments in the code. There is a lot of just like, “This is why I went in this direction,” as a reference to myself, but also if Lea goes in, she knows why that’s there, and to not remove it or to make sure that the CMS templates carry it forward, but I also have – it’s not a website, but I’d love it if we have the time to really clearly document all the rules. [Laughs]
Lea Alcantara: [Agrees]
Emily Lewis: But I just used Google Docs. I have a Google Docs that kind of is all of my different reasonings, because for me to support something, I need to remember why I did it in the first place. I don’t just like to, let’s say, assume. So it’s my reasonings of why I did something, what the goals were, what it achieved, it didn’t actually worked out so we’re not going to do it right now, check it again later.
So it’s just my own internal note-taking system of how I’m maintaining the framework and how next time I go into it to build something new, I have this as a reference to like bring my mind back to where it was the last time I was working in it. So I think you can take that idea of documentation, and if you have a client or an employer and you’re working on that sort of big system where you really can invest the time to make those really directed instructions is awesome, but that doesn’t mean like if you can’t do that, that you shouldn’t be documenting on some level, even if just for yourself.
Lea Alcantara: Yeah. I agree. We use Google Docs a lot because we are a smaller team and with specific visual design components, really for us, Emily and I, screenshot bullet points.
Emily Lewis: Yeah.
Lea Alcantara: Done, you know?
Sarah Federman: Yeah. It really comes down to just your users need to know where it is, and that’s pretty much it.
Emily Lewis: [Agrees]
Lea Alcantara: Right.
Sarah Federman: You need to be able to update it. I do try to avoid duplication in general so like I’m using the same thing in different places and one gets updated, and then people don’t know how to use your system anymore.
Emily Lewis: [Agrees]
Lea Alcantara: Right.
Sponsored by
Sarah Federman: And it kind of break the trust of the users, which is exactly what you want to avoid with the system because then they’ll go and do all their own stuff outside of that, which is just exacerbating the problem.
Emily Lewis: Yeah. You have to give them a foundation of consistency if you want them to be consistent in using it.
Sarah Federman: Absolutely.
Lea Alcantara: So I’m curious about that foundation, like is there like, “Here’s the tutorial on specifically how to update this design system item so that there’s no duplication,” like it feels like really obvious that there’s like the basics where the colors are, there’s probably like one section where they’re all outlined so then people could just link to them in different parts of the system, but then it gets complicated when there are other moving parts like when it’s such a big system, how do people know they’re not duplicating?
Sarah Federman: Yeah. So this is something that we’ve thought about a lot at Adobe, and on my team specifically. The situation that we had basically is that we kept changing things and updating things where things weren’t really vetted.
Lea Alcantara: Yeah.
Sarah Federman: So we have so many different use cases, like mobile web, all of these different situations that we were building for, but not entirely vetting, and what we did was we had a ton of components at that point, but nobody really trusted them.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Sarah Federman: And we really needed to get that trust back. So we kind of went back and we took away all of the stuff that wasn’t entirely vetted, like we created a vetting process, but with that, we kind of pissed everybody off.
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Sarah Federman: Because we took away all their toys, right?
Lea Alcantara: Right.
Sarah Federman: So what we did is we created a system to get things into the design system, so new components, and like not entirely vetted components, and then we created an app. This is my project. It’s called Spectrum Precursors, and this allows us and designers to update or upload beta designs of new components and of the way that we’re using components to web application, and then we have the ability to approve or deny those based on how well it fits into the system and all sorts of stuff.
Emily Lewis: Cool.
Lea Alcantara: That reminds of version control, right?
Sarah Federman: [Agrees]
Lea Alcantara: That’s essentially what it is, like where you have a dev branch, and then your lead dev checks your work or actually deals within whatever system, and if it’s great, then we’ll merge it to master, right? [Laughs]
Sarah Federman: Yeah. Versioning is a huge problem for design systems. It’s really hard to know what the version and how to version and how to get people on an upgrade process, so originally we were versioning all of the parts of our system separately, like our React library and our native library, and even our tokens in our website, and it kind of got people into the idea that all these things were separate or not part of the idea of spectrum as a whole.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Sarah Federman: And we really want people to think of all these moving parts as one whole, one identity of spectrum, so we’re starting to move them to this stage where we’re trying to get everything aligned so we can start releasing as one, and then people can upgrade holistically to all of the different parts, and yeah, it’s fun.
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Sarah Federman: [Laughs]
Emily Lewis: We’ve got a number of listener questions and I want to make sure that we get them in during our time this morning. So can we talk a little bit about naming? So how did you approach the naming of the different components of a design system to create like I guess a shared vocabulary that I’m assuming the designers use, but also then when it comes to code, that that gets translated into the naming in the code?
Sarah Federman: Yeah. So our general approach is just to treat our design tokens as a source of truth, so we have an internal tool that we built called Spectrum DNA and that is just a repository of all of this information about our components in our system and the variables that we use, and that’s kind of our main source of truth about naming so all of the development frameworks are expected to follow that.
And we have a designer that’s entirely dedicated to working on that as well as an engineering manager and an engineer, and that’s really just where those conversations happen, so that designer almost functions as a PM at times where he maintains relationships with all these different framework teams and our team and the DNA team, and he really just facilitates conversations about naming to make sure we’re all in the same page.
Emily Lewis: Yeah. I feel like I almost envy people who have larger teams because I feel like naming is one of the most challenging parts, especially being a developer when I’m getting into coding.
Lea Alcantara: [Agrees]
Emily Lewis: And that was a question from our friend, Reuben Johnson, and I just wanted to put something out there for the smaller teams, especially I know Reuben is the single developer on their team, you know what, I still find it so amusing. I only just started doing this, but I finally got sick of the fact that I didn’t seem to have a lot of consistency in my naming, which is just really frustrating to me because it goes against kind of my nature, and so I just started again a Google Doc where I decided what my roles were going to be, and I’m just going to follow them instead of kind of questioning them back and forth.
Lea Alcantara: Right.
Emily Lewis: And I even took it to the level of – oh, I keep forgetting all the acronyms for this stuff, but you know how people put the combinators, whether you’re using a hyphen or an underscore, camel casing or all lower case, like even just setting the rules that take in the time in afternoon to really think it out.
I kind of used my white board to think about how I really wanted it to be instead of at the beginning of a project where now I’m under a deadline and I have to like support that. I just made time for this and then I just documented it, and those are now my rules and I’m just going to follow them, and so you can create your own vocabulary and just stick with it, until there comes a point where it proves you need to change. Otherwise, you can go down a crazy rabbit hole of “is that a box or is that a container, or is that a module?”
Sarah Federman: A module.
Lea Alcantara: Yeah. [Laughs]
Emily Lewis: You know?
Lea Alcantara: A component, yeah.
Emily Lewis: And seriously, on two different days in the same week, I may feel differently and I waste time and it’s just not worth it. So I finally just got to a point of I documented it. I didn’t discuss it with Lea. I didn’t try and hash it out. I was just like what makes sense to me, I’m going to do it, stick with it and move on.
Sarah Federman: Yeah. I think sometimes we tend to get fixated on this idea of naming things when it’s really just a symptom of effective communication.
Emily Lewis: [Agrees]
Sarah Federman: Like if your developers are talking about something and you don’t know what they’re talking about because they’re using a different name, that’s an issue.
Lea Alcantara: [Agrees]
Emily Lewis: [Agrees]
Sarah Federman: But I think that I encourage us to be a little bit more flexible with it because, I mean, you might get something wrong. You might have to change it down the line, and it doesn’t really matter what it’s called as long as people know what you’re talking about.
Emily Lewis: Yeah. And that I think, again, back to the consistency, I feel like if you are, especially in my position as a developer supporting multiple clients over many, many years, consistency in naming means when I go back to that client I haven’t seen in two years, I’m like, “Oh yeah, ugh, duh, that’s what I call that back then” versus “Oh yeah, that’s what we call it because that’s what we’ve always called it.” And it’s just sort of consistent and I know what I’m dealing with.
Sarah Federman: Absolutely.
Lea Alcantara: I’m curious specifically about one specific naming thing, and that’s about colors because there are 50 shades of gray, right? [Laughs]
Sarah Federman: Especially at Adobe.
Lea Alcantara: Yeah. [Laughs]
Sarah Federman: [Laughs]
Emily Lewis: [Laughs]
Timestamp: 00:39:56
Lea Alcantara: And then at some point, there are just only so many ways you could have metaphors for gray or blue or red, and at some point, you just get into numbers, and you just start using nature. It’s like this is cerulean blue, you know? [Laughs]
Sarah Federman: Yeah. We have a really interesting system because Adobe products, I don’t know if you’ve noticed, but they each have a different color theme available to them.
Lea Alcantara: Yeah.
Sarah Federman: So there’s light, dark, extra light, extra dark, and the way that we’ve approached this is, one, by having a very concrete gray system and then our colors are also named, and we annotate those with numbers.
Lea Alcantara: Okay.
Sarah Federman: So Spectrum Gray 500 is a value, but that value depends on which color theme you’re using, so the naming stays consistent.
Emily Lewis: [Agrees]
Sarah Federman: So if I’m using a variable in my application that’s under the spectrum light color theme, I’ll use Spectrum 500, but if I change the color theme at the root level, all of my colors will change according to that, and we do that so we can maintain the contrast ratio between each shade of gray to make sure that everything is accessible and it’s just used consistently across all of your different applications.
Lea Alcantara: Excellent. I mean, I definitely haven’t considered that. I think it’s one of those things where when people are considering design systems and consistency and other ways to make things DRY, even with multiple color schemes, as you pointed out, if the naming and the approach and people understand what that approach means is consistent, there’s still a lot of flexibility available with fiddling around with the design.
Sarah Federman: Yeah, definitely. It’s an interesting opportunity to focus on your accessibility as well. With colors, if you have them all defined in one place, you can start to be more confident about how they contrast with each other, and even the meaning behind those colors and how to use them. So if you have like Red 500, but it also cascades down to a variable that’s like error red, that kind of helps inform your users about how to use those variables and what it really means.
Emily Lewis: So in terms of we talked a bit about naming, does that approach of kind of being flexible about it apply also to creating the visual language of the design system or is that where it does have to be really strict because you’re supporting the product or the brand?
Sarah Federman: I think we tend to err on the side of consistency unless you have a really good reason to go part from it. Like I can imagine the situation when the marketing team comes to us and they’re like, “We need really big headers because we’re sending big messages to our customers.”
Lea Alcantara: [Laughs]
Sarah Federman: And that would be okay. But generally, I think that our heading’s levels and our colors and these things that are tried and tested are really just the best way to go about it, one, because they’re very well supported, and two, they are always accessible, and three, there’s research behind them, like we actually had to use the researchers working on all this stuff.
Emily Lewis: Do you have any thoughts or ideas for someone who doesn’t have all that background research and is setting something up for maybe the first time of how they may begin that process of setting up a visual language?
Sarah Federman: Yeah. So I think it really just comes down to your brand, making sure that you’re accessible from the get-go is really, really, really important, and then like – I don’t know. I would honestly if I were starting tomorrow at a small company, I would consider adopting an open source solution that includes using like Brent Jackson’s Styled System. There are all sorts of solutions out there that can help you maintain this systematic approach from the very beginning and then you’re just filling out the boilerplate and then you can iterate from there, and you can also work an open source project, too.
Lea Alcantara: [Agrees]
Emily Lewis: Lea, I’m curious as someone who has a lot of expertise in branding, what are your thoughts about someone starting up a new visual language for a design system? Where does brand fit in to that?
Lea Alcantara: Well, brand is the big umbrella above all of it because brand is how people interact with every part of a product or system, it’s just the voice. So just approaching it really is trying to figure out what that voice is trying to say in the first place before you even start thinking about the nitty-gritty of all of it, and then also the approach of keeping an open mind, that consistency, is really about familiarity as opposed to everything exactly the same.
And I really think that Sarah’s example of that color component where there’s this huge design system with different products with different color schemes, but things can cascade down so that things can be applied consistently throughout is a mindset I think that people need to start with, and so I really think it’s just figuring out what that voice is, and then how do you want to apply that before you start figuring out color and typography and just that consistency mindset.
Emily Lewis: So taking a little bit of a shift, we got a question from listener, Mike Rogers, and he’s been in the kind of situation where he’s working for like startups who really never even have like a style guide or anything. So how can someone like that sell the benefits of these design systems to stakeholders? How do you get buy in for the energy to build one?
Sarah Federman: Yeah. I think it really, again, it depends on what your needs are. Think about it carefully because you might not even need buy in really if it’s just a couple of people, you just kind of do it.
Emily Lewis: [Agrees]
Sarah Federman: If it’s a situation where you really want dedicated resourcing and executive buy in to make sure that this is like part of your job, that it’s part of your tracked expectations, then yeah, definitely, I would recommend you start by talking about the effect of consistency on your brand and how users can really just have a better time with your product. The thing that I think really set us apart at Adobe when asking for money and resources for this was we went to our VP of Design, Jamie [Myrold], and we asked, “How much time do you think is spent on Redlines, like documenting all the ways that your design needs to be used for a developer, like all your numbers and annotations?”
Emily Lewis: [Agrees]
Sarah Federman: And she said, “Sixty percent of our designer’s time.” And we were like, “Okay, so we can eliminate that,” and then we took all that time, multiplied it by the average designer’s salary at Adobe, and then was like, “This is how money we’ll save.”
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Sarah Federman: And we were like, “Okay, now, have ten people how to count.” [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: All right.
Lea Alcantara: I love it. I love that you translated it into dollars.
Emily Lewis: And I think you could even do that on a small scale.
Lea Alcantara: Oh yeah.
Emily Lewis: I mean, if you took the time, like if I took the time to measure my time and compare it to, what, six years ago or something like that, I’m sure we’re saving so much money in development, which means we’re making more money.
Sarah Federman: And if you’re charging hourly, you could even do it that way.
Lea Alcantara: [Agrees]
Emily Lewis: We had another question from our listener. You sort of touched on this a little bit by describing the internal website that you have for the style guide, but our listener, Susan Snipes asked, “How do you make it easy for the rest of the team to use it?” Is that something also where you have to think about accessibility and the usability of your internal website so that it’s actually functional for your teams?
Sarah Federman: Yeah, there are a lot of factors, and I think this is one of the most interesting problems for us or in me specifically because I like to work on tooling, but we actually have a team of engineers that are actually exploring problems like this. So for ease of use for designers, we have an internal version of XD that we’re working on that it actually imports all of our components into it, and then we can use those components in a panel and actually manipulate them based on the variations that are present in the design system.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Sarah Federman: And that connects back to our design’s one source of truth, so designers can be confident that that’s always up to date. It’s a workflow thing. Precursor is really a big help with that, and like even the small things with precursors, so like we wanted to be able to let people know when there is a new precursor available to them so I set up a Slack notification that once somebody submits a precursor, it goes to our internal channel and we can approve or deny it, and then once it’s approved, it goes to the general design panel on all of Adobe, and they’re like, “This person just submitted this thing and now that’s available to you.”
Lea Alcantara: [Agrees]
Emily Lewis: If I can just take a slight change in direction, you’ve mentioned XD a couple of times. I’m not sure we’ve really had anyone talk about that much on the show. I know you work for Adobe. Was that always your platform? Did you migrate to it? What’s your experience with kind of using it as a tool for prototyping and designing?
Sarah Federman: I’m probably not the best one to talk about this with, but when I was an intern, that was before the existence of XD, and everybody actually used Sketch at Adobe.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees] [Laughs]
Sarah Federman: And they actually called the design group XD. [Laughs] When they created the product called XD, they obviously had to change the name of the design group. So now we’re Adobe Design. But in my experience, I’ve used it several times and the people in my team have told me that they enjoy it because again it’s extremely fast. It’s really, really fast, and you can maintain a billion art boards, and I feel it’s really easy to jump into the same way that Sketch is. You just kind of jump in and it works.
There are a lot of interesting developments happening on the integration side, so they’re working on a platform for that. I don’t think it’s quite where it needs to be, honestly, and there are a lot of tooling opportunities for us to pursue there, and specifically a lot of interesting ways to integrate design systems into the tooling itself, which unfortunately, I cannot talk about it at all.
Lea Alcantara: [Agrees]
Timestamp: 00:50:20
Emily Lewis: [Laughs] Understandable.
Lea Alcantara: Yeah.
Emily Lewis: Yeah. Lea, have you ever messed with it?
Lea Alcantara: I downloaded it the moment they said it was free. [Laughs]
Sarah Federman: [Laughs]
Emily Lewis: [Laughs]
Sarah Federman: Yay!
Lea Alcantara: So like yeah, like free plug to Adobe because I saw like Sarah Parmenter and Amelie Lamont. They’re brand ambassadors for Adobe. They were all like doing a bunch of demos, and it was quite impressive. I haven’t had the chance to dive right into it yet because I’m old school Adobe and that I still open up Photoshop. [Laughs]
Sarah Federman: If it works, it works.
Emily Lewis: [Laughs]
Lea Alcantara: Right. Well, I know, I totally understood, and it’s just one of those things where it really is like a mindset change, but the most I have done so far with XD has been I opened it and like clicked around, but I haven’t started designing anything there per se.
Sarah Federman: [Agrees]
Emily Lewis: [Agrees]
Sarah Federman: For me, I feel more comfortable in using it because I feel like having Sketch, which is a Mac-only solution kind of creates a lot of barriers to entry to people.
Lea Alcantara: [Agrees]
Sarah Federman: Macs are expensive and not available to everybody, and having a free Windows-supported solution is really important to me, and that’s something that students can take advantage of, people in low-income communities can take advantage of, and really just like democratizes the idea that everybody can do any design.
Emily Lewis: Cool.
Lea Alcantara: I love that.
Emily Lewis: And from what I’m hearing, you feel like while it’s maybe not entirely where it could be, especially in terms of supporting a design system, but it is something that’s really easy for multiple people on a team to use and share and work together on.
Sarah Federman: Yeah. We have incredibly, incredibly smart people working on this project, and there are multiple PMs that are just gearing up to put all these awesome things into development, so I’m excited for the future of XD.
Lea Alcantara: Very cool.
Emily Lewis: Mike Rogers was also asking what are the tools you’re using, so beyond XD or is there anything else you’re using in your workflows that sort of share the parts of the design system between teams?
Sarah Federman: Yeah. I would actually say one of the biggest things for me is just Github.
Lea Alcantara: [Agrees]
Sarah Federman: I mean…
Emily Lewis: Version control?
Lea Alcantara: [Agrees]
Sarah Federman: Yeah. Version control as much as we can. Even with our website itself, we actually have our designer. She creates her own PRs with like text edits and even our content strategy team is able to contribute via Github.
Emily Lewis: [Agrees]
Sarah Federman: It’s really just like it kind of makes it available to everybody and we want to do more to make that even more accessible down the line, maybe even like integrate a CMS or something, but version control is just the biggest thing. We also are working on like a new system for delivering assets, so our asset pipeline is a huge project.
Emily Lewis: Right.
Sarah Federman: It’s a long time coming. It’s a big project, and then we have our DNA tokens so that’s our internal tool again, but there are open source solutions like Style Dictionary from Danny Banks at Amazon, and Theo [Design Tokens] from Salesforce. Those are all open source design token solutions. Yeah, I think most of the tools that we have are just things that we kind of created to support our process with things like our release scripts, our internal design tool in XD. I personally think of tooling as a way to support all of the processes that go into the design system at Adobe really.
Emily Lewis: I feel that’s true just like with what Lea and I have described, you find the systems that support the workflow you need and you go with that. It doesn’t have to be anything custom. It doesn’t have to be anything fancy. You can go with prebuilt open source or you create and roll your own thing that works for you.
Sarah Federman: Absolutely.
Lea Alcantara: Well, one thing I wanted to take a step back on is we’re talking about all these changes and how we can update a design system, but we haven’t actually discussed what actually prompts you to update the design system and what prompts somebody to be like, “Okay, we need to change this thing.” Is there a regular schedule, or is it just like, “I noticed this was weird, or I noticed that this doesn’t exist and I’m just going to add it now.”
Sarah Federman: I think we’re still at the stage where we’re building things that we need and fixing things where we have problems.
Lea Alcantara: Okay.
Sarah Federman: Like an example we saw recently was we had made a mistake in the sizing of our texts, so in the WCAG Guidelines, they used DP, I think, and we were using pixels, and they’re not…
Emily Lewis: [Agrees]
Sarah Federman: Or they were using points and we were using pixels, and they’re not actually completely equivalent, so our text was actually too small and not passing accessibility guidelines.
Lea Alcantara: [Agrees]
Sarah Federman: So we went and we changed actually all of it across the board and we were able to do that fairly easily because we were using a systematic approach with our tokens.
Emily Lewis: [Agrees]
Sarah Federman: And then we have a PM that is working on prioritizing all the different things that are partly the teams need so we use that to inform what components we build and how we built that.
Lea Alcantara: [Agrees]
Sarah Federman: Another tool that I actually forgot to mention that is actually pretty important to us is we have about a gazillion variations of things because we have all these different platforms and all these different color themes, and when we have like a button, there are like 1,800 different ways to approach that or like – I don’t know – it’s somewhere in the thousands, and like if you look at the sticker sheet for it, it’s ginormous, like it could slow down your computer just looking at it.
Emily Lewis: [Laughs]
Sarah Federman: But not in XD. [Laughs]
Emily Lewis: [Laughs]
Sarah Federman: And so what we did is we actually decided to take a code approach, so one of our designers created a tool that is an SVG generator so one single source of truth, and then we just looped over all the different variations and color themes to output an SVG sticker sheet.
Lea Alcantara: [Agrees]
Sarah Federman: So we don’t actually have to maintain like a thousand different buttons.
Emily Lewis: Oh, neat.
Lea Alcantara: Hmm, that’s so cool.
Emily Lewis: All right, as we near the end of our chat today, I wanted to ask our listener question. This is also from Reuben, “What were the biggest gotchas you experienced while either developing or maintaining your design system?”
Sarah Federman: Hmm, it’s a big question. I would say from my perspective, our biggest mistake was not involving the developers from the very beginning.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Sarah Federman: Adobe is historically a little bit more siloed than other companies, and we have our separate design org, so our initiative kind of was born there, and we treated our external framework groups like a separate group, and that led to some complications down the road, and I think we also kind of really just became – I don’t know – enlightened to the idea that I think was really championed by the React, or by the Airbnb team that like code as a source of truth will actually help you maintain your system and valve it down the road rather than just kind of working from a design-led only perspective.
Lea Alcantara: [Agrees]
Emily Lewis: [Agrees]
Lea Alcantara: Well, I mean, again, reemphasizing our point from the very beginning of this episode, a little bit of both, design and development, you can’t escape it. If you work on the web, you need to understand both.
Sarah Federman: Absolutely.
Emily Lewis: And I just want to put out to Reuben and other listeners, I feel like I’ve been building starter files for – I don’t know what – four or five years now and sort of maintaining it.
Lea Alcantara: [Agrees]
Emily Lewis: And my biggest gotcha is sort of what I was referencing earlier. I didn’t document this in the beginning. I just built it and it’s that mindset, that former freelancer mindset, “Well, it’s just me. I just need to. I’m the only one looking at this.”
Lea Alcantara: Right.
Emily Lewis: But you just get far away enough from things or projects or decisions and if you don’t have a reference of why you made those decisions or what you want to follow up on later, it just disappears. Especially if you’re running your own business, there are a million other things you’re thinking about. So for me, the gotcha was like, “This year, Year 5 of your design system like I’m going to document this a little bit.” [Laughs]
Sarah Federman: Yeah. It’s really about for us getting the community involved. So we’ve had situations in the past where we changed something and we thought it would be fine, and oh, wow, it broke all these different people’s builds and all these different people’s designs, and we didn’t know because we weren’t actually talking to those people enough.
Emily Lewis: [Agrees]
Lea Alcantara: [Agrees]
Sarah Federman: So maintaining relationships with key partner teams is a really, really huge thing for us, and it might be that there’s a team out there that really wants to adopt spectrum, but hasn’t gotten to it because there’s just one thing that they really need that’s not available.
Emily Lewis: [Agrees]
Sarah Federman: And having those relationships lets us know about those things and lets us build for those things, just like a silo.
Emily Lewis: And I guess if you could extend that line of thinking to maybe not working in a large corporation like Adobe, but working for different clients, you’re going to build the things that your clients need, that they’re looking for, so having that open communication, it applies to all types of web designers and developers.
Sarah Federman: Yeah. We think of our users as clients often just because we’re serving their needs, and they are our key stakeholders really.
Lea Alcantara: Make sense. So before we wrap up, final couple of questions. What resources do you recommend for our listeners interested in creating a design system?
Timestamp: 00:59:53
Sarah Federman: Oh. Well, there are lots. On the thinking side, I think there’s theInVision Design Systems ebook that came out a few months ago, that’s really great.
Emily Lewis: By whom?
Sarah Federman: I don’t know how to pronounce her last name, but she did one through I think it was those A List Apart books. I’m not sure, and then as far as the tooling goes, Abstract is really, really awesome if you’re a designer and you’re interested in getting involved in version control, and then Styled System from Brent Jackson, and Style Dictionary from Danny Banks at Amazon. I can go on.
Lea Alcantara: [Laughs]
Sarah Federman: What else? React Sketch app, HTML Sketch app, too. I don’t know. Just look at some systems, learn from what other people have done. Look at Salesforce Lightning. Look at Shopify Polaris. Look at GE, I guess.
Emily Lewis: [Agrees]
Sarah Federman: There are just so many good examples to learn from, and there are lots of lists available so there’s one called Adele that’s available online. That’s I think put out by Figma. I hope I’m not wrong there, and that’s just a really good place to go in to compare different systems and learn more.
Emily Lewis: Awesome. So any final advice before we wrap up?
Sarah Federman: Don’t worry too much about… [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Sarah Federman: I know like design systems are really intimidating topic because it feels kind of like vague and abstract and very – I don’t know – out there, but really it’s just about serving your user’s needs, making things more efficient and however you go about doing that is the right way for you.
Emily Lewis: [Agrees]
Sarah Federman: There’s no right or wrong way. There are no real or fake systems. It’s all about serving your scale and your needs.
Lea Alcantara: Perfect. So that’s all the time we have for today, but before we finish up, we’ve got our rapid fire ten questions so our listeners can get to know you a bit better.
Sarah Federman: [Laughs]
Lea Alcantara: Are you ready?
Sarah Federman: As much as I can be. [Laughs]
Lea Alcantara: Okay, first question, what’s your go-to karaoke song?
Sarah Federman: Oh, Raise Your Glass by Pink.
Emily Lewis: [Laughs]
Lea Alcantara: Oh, I love it.
Emily Lewis: What advice would you give your younger self?
Sarah Federman: Shut up and listen.
Lea Alcantara: [Laughs]
Sarah Federman: [Laughs]
Sarah Federman: [Laughs]
Lea Alcantara: What’s your favorite PG-rated curse word?
Sarah Federman: Oh, man, I have no idea. I’m so sorry. [Laughs]
Emily Lewis: [Laughs]
Lea Alcantara: Okay. [Laughs]
Emily Lewis: Who is your favorite superhero?
Sarah Federman: Oh, Captain America.
Lea Alcantara: Oh, Chris Evans. What is your favorite time of year?
Sarah Federman: Fall.
Emily Lewis: If you could change one thing about the web, what would it be?
Sarah Federman: Tribal knowledge.
Emily Lewis: [Agrees]
Lea Alcantara: What are three words that describe you?
Sarah Federman: Ah, I don’t know. Passionate, driven, probably sarcastic.
Emily Lewis: [Laughs]
Lea Alcantara: [Laughs]
Emily Lewis: What are three words that describe your work?
Sarah Federman: Oh, systematic, cohesive, I don’t know, cross-disciplinary, but that’s kind of two
Lea Alcantara: [Laughs]
Sarah Federman: Hyphenations are all one word.
Lea Alcantara: Oh, yeah. What’s your favorite meal of the day?
Sarah Federman: Lunch.
Emily Lewis: All right, last question, coffee or tea?
Sarah Federman: Coffee.
Lea Alcantara: Very cool. So that’s all the time we have. Thanks for joining the show.
Sarah Federman: [Laughs] Thanks. Thanks for having me.
Emily Lewis: In case our listeners want to follow up with you, where can they find you online?
[Music starts]
Sarah Federman: Yeah, just reach out to me on Twitter, it’s @sarah_federman. My DMs are open, please reach out. I’m happy to help with anything.
Emily Lewis: Awesome. Thanks again, Sarah. I really enjoyed this conversation. It was great having you on.
Sarah Federman: Thank you so much for having me again, it was awesome.
Lea Alcantara: CTRL+CLICK is produced by Bright Umbrella, a web services agency invested in education and social good. Today’s podcast would not be possible without the support of this episode’s sponsor!
Emily Lewis: Many thanks to our hosting partner: Arcustech who wanted a shout out at the top of the episode.
Lea Alcantara: And thanks to our listeners for tuning in! If you want to know more about CTRL+CLICK, make sure you follow us on Twitter @ctrlclickcast or visit our website ctrlclickcast.com. And if you liked this episode, consider donating to the show — then give us a review on Stitcher or Apple Podcasts or both! Links are in our show notes and on our site!
Emily Lewis: Don’t forget to tune in to our next episode when we have Gabe Levine and Josh Barrett on the show to discuss standard agreements for digital services, which is really just a long way of saying like your contracts and statements of work.
Lea Alcantara: [Laughs] Yeah, yeah.
Emily Lewis: We’re excited about this one. Be sure to check out ctrlclickcast.com/schedule for more upcoming topics.
Lea Alcantara: This is Lea Alcantara …
Emily Lewis: And Emily Lewis …
Lea Alcantara: Signing off for CTRL+CLICK CAST. See you next time!
Emily Lewis: Cheers!
[Music stops]
Timestamp: 01:04:33
