Microsoft designer Josh Cusick joined us on the Design Systems Podcast to discuss his experience working with design systems, and his thoughts on the future of the industry.
Chris: As a designer, what does a design system look like for designers?
Josh Cusick: Yeah, a design system really is a single source of truth. I mean, I think you probably hear that a lot on this podcast, but my job, at least how I see my job at Microsoft is to empower designers and engineers to be able to communicate with each other seamlessly and make the designs as usable as possible, but also as close to code as possible.
Chris: Awesome. And so what do you mean by that when you talk about design getting close to code? What comes to mind when you think about this process? Because how I've always envisioned design systems in Figma is you have this collection of patterns that you reuse to make comps. And I think that that's not totally accurate. Tell me a little about what you mean by getting close to code.
Josh Cusick: Yes. So we have to look at it from a number of different perspectives, right? So when we look at it, we call it the Teams Component Libraries or TCL. We've got kits for every platform at Microsoft. The one that I work on and built is the desktop kit. Right? And so when I'm talking about aligning to code, I'm talking about how do we, for example, take a button and allow designers, regardless of your understanding of code to be able to use that button and toggle properties on and off and change and tweak and modify that button without breaking it. And also when they hand off their comps with that button that I have designed and made available to them, how do engineers that are then coding the actual prototype and they're importing the react button, how do they know what properties to pass and to set in that button? And so it's like straddling both of those two points of view.
Chris: Yeah. So actually in your design tools, you're thinking about things like prop types and the different types of variables and all the different things that would go into the rule set that ultimately is built by developers and fundamentally creates a set of constraints for those developers to work with.
Josh Cusick: Yeah. It's an interesting situation at Microsoft. And then I hear a lot of teams when they talk about building design systems, they oftentimes will have their kits and their designs and their comps already spun up and already built. And then they end up coding all of these components out.
Chris: So how are design systems constructed at Microsoft? How is it that your design system that you work on every day, how does that fit into the greater ecosystem there?
Josh Cusick: So when I'm thinking about actually building these components that are already in code, because unfortunately that's where we are at when and I started. We didn't have all of these components actually built in our Figma files, especially with variants as well. So really what I did was I looked at the component APIs or button props or button properties and mapped those to what I actually built. And there are some trade offs and some nuances.
Chris: Right. And presumably there's things you can do in design tools that you can't do in code.
Josh Cusick: Right.
Chris: And there's stuff you can do in code that you can't do in design.
Josh Cusick: Exactly.
Chris: And so these gaps that are in the system for you, when you think about identifying those gaps, how do you bridge those and how does that look? Because again, alignment of this large scale set of designs to code, the gaps there are numerous, but ideally pretty small.
Josh Cusick: Yeah. It's a matter of a couple different things that we've done. One of the things I try to do is align the documentation but not be aligned to the actual documentation. So for example, looking at a button, our button component, but make it, so the actual designer that has no experience with code whatsoever understands the function of the properties or the variance is what Figma refers to it as. So I just try to make it as intuitive possible and I make some concessions. Like for example, I don't use in the properties panel or the variance panel in Figma. I don't use Pascal Casing for properties. I'll just use Sentence Casing and some of the language is changed a little bit.
Chris: Yeah. I think that's great. Looking a little deeper into naming. Right? So when you think about how you align what is being designed to what is being in code, how do you marry up the names of things? Right? Because we all know that naming's hard, right?
Josh Cusick: Yeah.
Chris: The problem space of naming is varied and extensive. When you think about how you create that mapping between a component or a variant in Figma and that same thing in the land of code, what does that conversation look like? How do you bridge that space with language?
Josh Cusick: Yeah. So that's a really good question. So in my previous company, I was focused on more closely following them. So block element modifiers, it's very common CSS naming convention for my layers specifically. And that was because the actual components weren't always coded while at Microsoft, the components are already built. And so for the name of the component, I'm snapping to what we have in code, unless I'm building a new component, then it's a whole nother conversation. And then for the name it's always using Pascal Casing, which it's just easier to scan.
Chris: In that way you're able to tie a lot of the convention that you're using inside of design to the exact same convention that exists in code. And so that creates a much less ambiguous way of translating what comes to an engineering Figma.
Josh Cusick: Yeah. And then for the layers, I'm more focused on making it intuitive for designers while also following a BEMs naming convention. So they understand when they click on a layer and they see icon string stack, they understand that it's an icon in a string. Right? And if there's multiple strings, I have a description at the end of that. So that helps me to know exactly what to call something when I'm building it, which saves me time. And it also lets designers establish a expectation for what to look for when they're toggling down inside of layers in a component.
Chris: So all of this sounds a lot different than maybe the conventional thought process around design, that idea that like, "Hey folks in Figma are just drawing boxes on a coordinate plane and inserting a couple of layers around." Right? I know that that's an oversimplification of the role there, but how does this differ from the traditional idea of the creation of comps and the production process and design?
Josh Cusick: Yeah, it's a really good question. So you and I we're talking about this earlier before the recording started and my team, we're looking at a lot of things like standardizing patterns and standardizing models. So there's not a lot of... There is exploration for our feature teams, but that's within the parameters of what framework sets, if that makes sense.
Chris: Yeah. No, that's great. So when you think about the patterns that are being set in a design file, what form does that take? Because I've always thought about design in a very traditional sense of like, this is a screen flow or this is an app flow, or this is something that I'm comping out. This is about telling a story. And I know that that's changing to be a lot more about how do I express intent and then how do I create boundaries and rule systems around that intent? How is that embraced in this idea of this new concept of design system?
Josh Cusick: Yeah. So not only is my team done a lot of work inside of Figma to make as many components, customized components and configurable components available to the users, to our designers so that they can configure them and change them and all that type of stuff. But we're also working to provide high level guidance from a framework perspective on how to use specific components, such as notifications and loading components. There's two pretty big projects that my team is working on right now that I'm helping to lead, which is the Notifications Framework and the Loading Framework. The Notifications Framework has been quite fun and it's been a way to basically look at all the ways that we're communicating with the users right now inside of Microsoft teams. And that's things like banners and toasts and all types of stuff, and to really rethink and reimagine how we're communicating the user really go in and be really intentional about how we use specific components and all offer alternative components for our users, meaning our engineers and our designers to use in specific scenarios.
Josh Cusick: One of the models that I've helped to introduce for that Notifications Framework is this model called Intent. It's really just semantics. So we've got this semantic leveling of components where it's one through four, one being the most severe. So if a banner it's a level one, it's just really urgent. It's level two, it's less severe. It's a warning. And level three is a positive or successful type of notification. And then a level four is just something that's really neutral, purely informational. And then the other thing as well is, I've helped to extend existing components and flex them and stretch them a little bit more. So we had this component called a Confirmation, which is a toast component. And so we've extended that, renamed it to a toast and just made it fit that model as well. So we've got, not only do we have these banners that are following this intent model, but we also have toasts and then other components as well. So really helps us to be intentional about what types of components we use and then how we style those components and how those components behave.
Chris: Tell me a little bit more about the intent system. What does that actually mean and how is that applied inside of that semantic framework?
Josh Cusick: Yeah, the intent system basically helps to give a more concrete and clear way to users. Meaning our engineers and our designers to select the type of component it and then to select the style of the component and the messaging of the component. So it's very clear, if this is a level one in intent, it means this component needs to have red styling. If it's a banner it's red, if it's a toast, it has like a red icon on it. And then there's specific messaging and actions that can be applied to that. Where as if it's a level four, this is something that's just purely neutral and it's informational. So it doesn't need to convey any sense of urgency. We're just trying to communicate something to the user.
Chris: Got you. So that way you're able to assess the importance. It gives people guidance on the intent of the design.
Josh Cusick: Yeah.
Chris: Rather than just like an open-ended, here's some options.
Josh Cusick: Right. Yeah. So, I'm seeing this with the skeleton component that I help design and shift for the fluent web design system and specking it out, designing it, writing guidance for it and chipping, there's things that I wasn't able to anticipate as far as needed guidance for it. And so one of the things we've gone back now and done is writing more guidance on that skeleton component and then looped in, or grouped in other components in there as well. So like a spinner and some other stuff, and then name that loading framework. So now I've got this framework that I'm working on that is helping to provide high value and high level guidance on similar to the Notifications Framework on what components to use and when, and all that type of stuff to really help designers and engineers select the right loading component to use and why.
Chris: So now you're taking that same practice idea of a semantic framework and an expression of intent that was used with notifications. You're applying it elsewhere too, in this case loading systems. But it sounds to me like one of the things that's happening within the design side of teams is that there's a lot of almost competing ideas about the direction here. And what you're trying to do is you're trying to create a codified set of rules or at least best practices that people can follow.
Josh Cusick: Yeah.
Chris: That allow for easy decision making around what to use, when, and where.
Josh Cusick: Yeah. And I think what's really cool is the design maturity level at Microsoft, envision talks about ranking design maturity. They've got this design maturity model. It's been really, really cool and really satisfying to work for a company that a high level of design maturity, a high level of hunger and willingness to expand the way that we do design. And we think about designing components and a really deep hunger for guidances that we work on.
Chris: So I am really curious about this, give me a sense of before and after. It wasn't always this way and it certainly wasn't this way when you joined. And so try to think about the before and after this where, now this sounds like Utopia, right? You have a design landscape where there's a lot of adoption. People are super bought in, it aligns well to code, there's expressions of intent and semantic that cross over to code and even more so, it sounds like you've created a good structure for that system that allows people to contribute to it and modify it. But what did it look like before and lead me down the journey of getting there.
Josh Cusick: Yeah. So with every design system, it has its beginning and goes through its growth stages. And as it grows, it matures, there's different things that are identified as needs and you weigh those as the system grows. So when I first started, the team that I am on, the framework team, my manager Kay and my peer Daisy, they had worked on a lot of components specifically for the team's desktop and web applications, but also for the fluent design system for the web part of fluent. And so, when I came in, I took on some of that work, but then I also started to take on some other projects as well. So, free them up a little bit to focus on that. And so I was able to work on things like, building and scaling out the Figma kit for us and just helping to contribute to the ongoing efforts of the team. So yeah, it's been pretty cool to see the team grow from two to three to now there's six of us on this team. And as we grow and as we get more resources, we're able to work on more and more projects and allocate resources towards things that end up benefiting really the whole organization and then different things that we work on, especially for the fluent design system, we're able to help designers and engineers and PMs all across Microsoft design.
Chris: Right. And so what does that look like for the next iteration then?
Josh Cusick: Yeah, the two main areas that I'm focusing on right now is working on that high level framework guidance for things like Loading Framework and Notifications Framework. All this guidance, the goal was to move it into an internal doc site. We built that doc site during a hackathon week and ended up getting a lot done, which was pretty cool. And just that site we'll be able to provide some more visibility into the do's and don'ts and best practices of using specific components and different frameworks that I'm working on and my team is working on. And then I'm also in the process of handing off the work that I did inside of Figma. So the Figma UI kit for the team's component libraries off to some of the new designers that joined our team.
Chris: Awesome. So, with all these new folks, like how do you bring somebody that's new onto this system and potentially more importantly, how do you keep them from breaking things?
Josh Cusick: So a couple things. So like I mentioned earlier, having a doc site that we're working on, it's already spun up and I need to work on adding more guidance to that site. So things like, what types of dependencies do you use for the Figma UI kit that I built. We built a plugin to make the job easier, the theme components, and to switch properties on and off. And then you'll do some basic onboarding guidance and understanding how to contribute to the team's component library, Figma kit as well. So these are all things that I'm working on to make it easier for folks to implement and work with a system.
Chris: Yeah. So talk to me a little bit about the plugin, because I think this is an interesting piece here, right? Because you guys have actually created something that is essentially a unique plugin that you use to connect what you're doing to other parts of your ecosystem.
Josh Cusick: Yeah. The plugin was pretty fun to build. I worked with the UX engineer at Microsoft and it's built in React and TypeScript and it's just using Figma's API to basically theme components and then also surface nested components inside larger components. So like for example, if I had a title bar and I had a group of three buttons and then an avatar and some other stuff. I'm able to see all of those at once in a single UI, that little box that shows up for the plugin and then do different things like group them together and apply a single property on or off, or ungroup them and pretty cool stuff like that.
Josh Cusick: It also helps us to theme as well. So we had about 25 designers and we built the plugin that we're really solely working in dark mode or dark theme and to mitigate the time and effort it would've taken to build out or duplicate all the existing light theme components into dark mode we built this plugin. So yeah, it's been pretty fun. We've got some plans for it and I'm excited to see what happens in the future.
Chris: It's awesome to see the extension of what you're doing in design system, actually influencing a design tool. I think that that's been one of the really challenging parts in this, cross-disciplinary function that exists between design and development is there's a lot of tooling and plugins for each different discipline and getting those pieces to talk to each other and allow you to accomplish the same things is actually challenging, right? Because as a designer, you have your set of considerations and as a developer, you have a separate set of considerations. And so thinking about the ways of creating those common rule sets seems to be the way forward there.
Josh Cusick: Yeah, exactly.
Chris: So tell me a little bit about the site you created and what's going on with the design systems for Figma.
Josh Cusick: Yeah. Design systems for figma.com started off as a personal project. When I started at Microsoft, one of the needs was to basically centralize all of our components inside of a single kit. We had just migrated for the most part when I started from Sketch to Figma, which was really cool. And in the midst of migrating, we were refactoring some of the things that we were doing. And I was left up to the task to make some of those decisions. And before I was going to go in and start creating all these components and moving things around and organizing, I didn't really want to arbitrarily make those decisions because it was going to impact about a hundred designers. So one of the things that I did was I looked at all of these different design system kits that were in Figma.
Josh Cusick: And I wanted to understand what these different kits were doing and why they were making some of the decisions so that I could take some of the good decisions that they made, an effective decision that they made and implement those decisions at Microsoft. And so in the process of reaching out to these different designers at all these companies, I didn't get a lot of resources as far as when as I asking different companies or different designers like, "Hey, do you have these design kits open? Are they available?" Other than pointing me to kits that I already had, I didn't really get much help, but what I did get was request to open source my work. So I had my work really stored centrally in a file or project file in Figma, in teams inside of Microsoft and different people inside of Microsoft were interested in seeing that work.
So ultimately I created the design systems for figma.com side as a way to put together all those resources, and as that at grew, one of the other things that identified was an opportunity to create a blog. So design systems for figma.com/blog, you're able to read from other design system experts and learn about what they're doing at different companies like Google and Spotify and Netflix, and that type of thing. Just to create a community around design systems and create a central resource for folks to read about what other folks are doing in the design systems community.
Chris: Yeah. It's an awesome resource. And I'm very excited to see this community maturing across lots of different channels and lots of different, little ecosystems getting created. It's really awesome that you've built that.
Josh Cusick: Thanks. Yeah.
Chris: So thinking about these communities, what's the best way for people to engage around this sort of stuff, right? Is there a place that people can go? Where do you go when you need help? When you have questions that you need to get answered?
Josh Cusick: Yeah. So about a couple of months ago, the framework and design systems teams started an open garage office hours for folks in the side of Microsoft. Microsoft design, mainly teams design, teams desktop, and web to come and show their mocks and show their designs and ask questions about how to use components, when to use components and that type of thing. It's a lot of fun and it's a cool experience to be able to create this community for feedback. It's a safe environment for folks to present some ideas that they have and to get feedback from the design systems team. And the cool thing about the design systems and frameworks teams are that we're on a global level of what projects are going on in multiple teams. And so oftentimes we're able to play matchmaking. And so if a designer is wanting to implement a new feature or work on a component that another team might already be working on, we're able to point them to that other team and help them collaborate, which I think is a lot of fun.
Chris: That's all for today. This has been another episode of the Design System Podcast. Thanks for listening. Our producers are Ryan Peterson and Shayna Hodkin. Our musical composer is West Willis. Our editor is Zach Marcus. If you have any questions or a topic you'd like to know more about, find us on Twitter @TheDSPod. We'd love to hear from you with show ideas, recommendations, questions, or comment. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.
