Design Systems: An Interview with Rob Berrones

What's up everyone, I am Ritzy and I am here with Rob Baronez. Uh, just a little introduction how we know each other. Rob and I used to work together at a company and we have gone through the wringer. We have— we pretty much had built the entire organization there, um, along with a few others. And, uh, Rob has been very, very helpful to me in my journey in terms of knowledge. Rob has gone through, uh, leading a introducing design systems, which is what we're going to talk about today, but also some other things in education. I'm not going to hype you too much, Rob. I'll let you, let you hype yourself when you get to the introduction. But I just want to just verify how much you've helped and how much knowledge you've helped bestow upon me. We've had discussions about all kinds of topics UX-related, and I thought Rob was just a, you know, just such a good knowledgeable person around UX. So I, you know, wanted to invite him to talk and hopefully talk, you know, more often even. So, but today we're talking about design systems overall. I recently did a video that talked about some of the design system tools I've tried out, and I thought it'd be great to, to bring a pro and talk some more about it. So that being said, Rob, please introduce yourself. Tell us what you got around some design system info.

Thanks, Lindsay. I appreciate it. My name is Rob Baronis, and I've been doing Front end and user experience for 20 years or so now. I started off my career as a front end web developer back in the like Flash days when Adobe Flash was like king of everything. And from there I graduated into user and interaction design. And from there I sort of understood the company that Ritzy and I were working for needed a research arm. And so I started the research arm of the company we worked for and I grew, it was like 5 of us researchers when I left that company. So my experience throughout the years has, has sort of lended itself really well to what design systems are. Right now.

I even, even kind of thinking about how we first started, I remember you had introduced design systems at that company. Do you remember what we were using? Because this was 2017, design systems were kind of on, just kind of booming, right? We were just getting there. What do you remember what we were using like at that time?

Yeah. So we were, from what I remember, we were doing HTML and CSS and JavaScript prototypes. We were using Sketch for some of our design work and we didn't have any design system anything. And that's actually one of the reasons why I was hired at that company. What I showed in my interview was the beginnings of the design system that myself and a couple others were working on. At the previous place that I was. So to give you a little bit of background as to what the landscape or the context of 2017 was in design systems, it wasn't a thing, right? Brad Frost's book Atomic Design had come out in 2016, I believe, and my experience with With Atomic Design, it was not so much a light bulb as like a, finally somebody wrote this down in a book. I worked for a software as a service company at that point, and we were running up against this really big problem of everything was custom, like software as a service. Like we were trying to sell out-of-the-box software and we couldn't really do look and feel or functionality out of the box because everything was custom. But right around that time, sort of the preprocessors like LESS and Sass were starting to get really popular. One of the first things that I ever did with LESS was I took jQuery UI and wrote a LESS variableized styles— like stylesheet for jQuery UI. And that really opened up the possibilities and the doors for what we could potentially do with design systems, right? So we gave our people two files. We gave them a variable file that they could use and change, and then anything that they needed to do custom, it went in an overrides file, one set at the beginning of the process and one set at the end of the process. So everything else was pretty, like, once you get variables into your code, it becomes really easy to start manipulating those things. And so in 2012, 2013, before, you know, Brad Frost's book came out, things like that, we had already implemented a way to easily brand and run through a very custom look and feel for one of our clients. Based on just those two files, which is really sort of amazing and cool, right? We were changing stuff like border radiuses and colors and gradients and things like that. And it really started to open up the possibilities. And so when Brad Frost's book came out in 2016, it was like, oh, thank God somebody put it in a book. And so full circle, when I started at that company, I had brought with me patternlab.io, which was Brad Frost's sort of makings of a design components design system type thing. I wrote up a 5 or 6 page document heavily based on Brad Frost's book about why you do it, what you do, how you sort of start to standardize. And that sort of fell on deaf ears, but It's not because it wasn't valuable, it's because of a big problem that we run into with design systems all the time, which is culture and process, right? Like, and buy-in. That's a huge problem even today with design systems.

Man, Rob, you hit a few things, a few big topics, you know, brought up, you brought up one thing that just lightbulbed to me just now as you're talking was the difference between style guide and componentization, right? Like I think that's, you know, seeing that you're at the Pattern Lab I/O, for me that was like the big thing was the organization shift from this style guide that just kind of had everything in a list, you know, just every— and even how it was used, right? See, like it was a CSS style guide with an override file, which was used most things too. Like I did it with Bootstrap, you know, a lot of times I use like a Bootstrap file, which is the generic, and then I'd overwrite specific things. But it was, it was just everything laid out. There was no organization or documentation around usage or anything like that. So I think really one, one of the big aspects I remember you bringing was, was the documentation of this and not from a code standpoint, but from a design standpoint as well.

Right. It's, it's the nuance is lost in the semantics, I guess. And what I mean by that is is everybody calls it a style guide or everybody calls it a design system when it's really not a design system. And a design system really consists of the code, the design, and all of the guidance, governance, and guardrails that you put around it. It also includes content. And branding, right? Like all 5 of those things need to be equal partnership or it falls down. A lot of the preconceived or misperceptions that people have, preconceived notions that people have is the design system is a silver bullet. One size fits all. Like just put out a design system and everything will be awesome automatically. And that's really not the case. It's a combination of things working together. Because designers, they're not content experts. Content experts are not designers. Branding specialists are not coders and coders are not brand specialists, right? So each thing needs its own place and an equal partnership. Think of the design system as a consumer of those things, right? It intakes those and makes them available to people. But it doesn't dictate what it is, right? It will give you guidelines and governance. And I'm a big proponent of guidance over governance because we all know that design is messy, that coding is messy, like software production and implementation is messy. And you will not always have a one-size-fits-all. I'm a big proponent of guidance over governance because we all know that design is messy, that coding software implementation is messy, and there's not gonna be a one-size-fits-all. One size fits all. They're always gonna have edge cases. And so guiding people on how to use components and use the design system is way better than telling them, hey, you can't do this and you can't do that. When I, when I first started in the role I have now, like it was, I was very strict with like detaching instances in Figma. You do not detach instances in Figma. And I think that's just naive, right? Like that's just a lack of understanding of how people use these things in practice, right? I've since then adopted my strategy where now it's put it all in a separate file, right? Like put it all in a separate file. Make a component library out of your components in your project, and then bring those in as a secondary library because it makes it very easy for people like me who has to manage and oversee and sort of police, for lack of a better term, a design system, understand what you're trying to do. And it gives us a really good target for what we want to put in the design system, what variants and what special cases and things like that. Look, people gonna do what they gonna do, right? So I would rather organize the chaos in a way that is manageable for me to help them in the future. All right.

Can you elaborate on that? Like just managing the design system, not just because I think there's a difference between establishing it initially and then keeping it up to date. How do you have any tips and best practices for that? Also too, if you could speak on the difference of having a team. I think a lot of places like they are talks lose this, having a team versus not having a team dedicated to that.

So the reality, I'll start with that first, 'cause that's a big point for me is, you know, if it's important to you, you're gonna commit to it. Right? If it's something that is important, you dedicate resources to it, you commit to it. Because we all know that doing things in our spare time is automatically the lowest priority, right? There are things we have to do. We have to eat. We have to take care of our families. We have to make enough money to pay rent. There's Maslow's hierarchy of needs, right? And the things that we must do are the highest priority. The things that are nice to have or, you know, whatever, they can always go to the back burner. And we all live busy lives, so we know like things get put on the back burner, they get forgotten about. Right? So if you say it's important and you want it to be important, then you need to commit to it and commit resources or time to it. Otherwise, it's not important to you. And that's just the reality that we live in. That's not me saying like, oh, I don't think you can do it, because you probably can. But in essence, if you are, that means you're dedicating time to do it and probably on a regular basis, whether that's your nights or weekends or whatever.

And when you say you, like you, I assume you're talking about, well, in, in this scenario, I assume you're talking about the company, right? The company prioritizes it or the, you know, the collaboration of teams or the product team. Who, who in your mind is the, the you that you are talking about?

Right. So I'll give the case that we ran into at the company we worked for. Right. You know, we've been pushing design system. For the entire time I was there. And it was always a, oh, we're going to build this in our spare time. And we kept trying to advocate for this, like, no, it's not just the Figma files, it's not just the design side, it's the code too. And we had developers who were interested in building that code side too. And so we came up with that proposal. Proposal, like, hey, give us one day a week. Like, let us on Friday work on the design system, right? And they're like, nope, nope, you gotta do it in your spare time because we have all this other work to do and no one has capacity or allocation. We were in SAFe. So if you know SAFe, then you know that everything is sort of planned out for a quarter or however long your, your PI is, and you just run outta time. Stuff carries over, things are more complex. Like it's the, the nature of our business. It's the nature of what we do. And so we always tried to do it in our spare time and it was a quarter of what it could have been. Like we still got stuff done, but it wasn't nearly as much as it should have been and what we were capable of because we didn't commit time to it. So always, always, always. Yeah. Yes. Always experience.

Experience.

Yeah.

We got, I remember we had gotten just through design, a design file. We didn't get to any of the other cool stuff that you had talked about on having the code. Um, very minimal documentation on usage, but we really, if anything, it was a component library. Um, and we were doing it in that federated model where it was like, okay, You guys do a little bit, you do a little bit. Um, if it touches your project, maybe you'll touch it. Um, but in terms of keeping it up to date or managing it, that's where it was all lost, right?

And, but, and it's a full-time job, man.

So you having a team, right, like that now, that now does that, how is that, right? Like, I, I've, I have gotten to work with some companies that have had a team that, that was specifically for it, but I wasn't on that team. So I'm new getting to to manage that team or manage a team that does that, how do you keep track of updates and things that change? And like you had said, you see designers coming up with new use cases in their files. How do you start implementing that into the design system?

So what we're trying to do is we're trying to be a full service team, which isn't always the greatest. But it helps us keep the pulse on what's going on. So, um, what our team does today versus what it did when I started are very different things. Um, today we hold, uh, office hours once a week for an hour, um, where anyone who uses or is curious about the design system can come in and either listen in or ask questions or just sort of like challenge a component or like, hey, I'm trying to use this component this way, it's not working. Hey, I had to detach this. I wish I didn't have to detach it. Like, what's going on? Hey, this code isn't working in the use case we need it to. So office hours, we do a working development and design session every other week for an hour to give additional time. But that comes from the adoption, right? So we didn't have adoption when I first started and we did one particular thing, which we can get into in a second, 'cause I wanna finish answering your question. We basically built a page of our site from an old design and showed them this is what this thing can do. But we, we keep track of what's going on and issues and things like that. We keep track of that through some tools that are available to us in GitHub. So we use the discussions and the issues in GitHub. We have a contribution model and we try and get people to contribute back. But those tools like issues and discussions and forums and stuff like those things are absent in the design world. Like we, we don't have those tools. Like I can submit an issue in GitHub and, and I can ask a question in the, in the discussion forum and I can get answers and people can have that two-way conversation. Like we have comments in, in Figma, but that's just not enough, right? Like we need a way to track this stuff. We need a way to keep historical records. We need ways of versioning it. They have changelogs in, and GitHub automates your changelogs too, depending on like the labels that you put in. So all of those tools that developers have had access to for so long that really help them understand and like code, those are not available in our design tools. And so we always assume that creatives are like, oh, I'm a creative, I'm a designer, I'm gonna do what I want. And I'm guilty of this too, like everybody sort of thinks that way. But in reality, is it because we don't have the tools for them to understand, right? Like we don't have, where are we supposed to put our documentation? How are we supposed to provide examples? Like we showed development examples. We have a documentation site that we built that mimics the single page application stuff that we do. And we have a bunch of examples for developers of like how to use the code, right? What props to put on, like how do you call this? Like how this needs to be an array and it updates from this and blah, blah, blah, right? Non-existent in the, in the design world. So of course designers are gonna use it to their extent. They're only people, right? So they're gonna use it to the best of their ability, but they're under the same pressures and deadlines that developers have. So we need to give them the tools that help them understand like we do the developers, right? And I'm starting a project to, to help address that, hopefully.

Nice. So funny, as you mentioned that, I just thought about like how, because when you're first describing, I'm like, yeah, I guess we do have, we have comments, right? To talk. But the minute you hit resolve, like the thing's gone, right? There's no tracking, right?

Uh, you can bring them up. Like, it's kind of weird. You can show like all resolved or like all comments, not just the unresolved ones, but it's a pain in the butt, right? Like, it's not a good experience. Yeah, it's not a good experience.

You can't track as a designer, right? I'm gonna track there. Number one, we're looking at all the comments everywhere, not specified, not over time. We're not— it's like, it just it's just not a good experience overall compared to some of the, like, and like you said, those dev tools, some of those things when you first described it, I was like, oop, a little over my head. I don't know. It sounds like a lot. But then as, as you got more in depth with the use case, you, it really made more sense of, of the use case, right? Seeing the changelog of a specific component or seeing a way to talk around like, this is not functioning the way I need it to. The buttons, turning on and off icons is janky, or switching the, I've had times where I've switched a variant and then like reshuffled the whole, or reset all my overrides, right? Like it was a problem. And hopefully it gets fixed, hopefully somebody updates it, but you know, there's no tracking and that's very problematic. So I'm excited to see where that project of yours goes. And yeah, that's a, you know, a huge problem to solve that, like, like you said, developers have kind of already solved and we need that on the design side.

Right.

But you brought up like GitHub, you did bring up, sorry, just kind of transitioning into kind of tools you use. You brought up GitHub. I'd love to hear how you use, like, do you use that for the design side or is that mostly dev side? And what other tools do you use for the design system and stuff like that?

Yeah, it's a great question because the tool set is always evolving, right? And somebody's coming out with something new all the time. For our purposes, we use like 4 main things. We use GitHub for our repo, we use Figma for our design, portion, we use a doc site that we built for our documentation examples, and then we use Storybook so somebody can go and play around with the component, right? So in Storybook, you, for those who don't know, you set up controls for your components. So you can have like text, you can have like if something shows or not, you can have treatment for a button. And all those things are sort of like regular form controls, like a toggle switch on and off, a select dropdown, radio buttons, or just an open text field. So somebody can go in and they can take your component through its paces and know, sort of have a good idea of what controls what, right? In our documentation site, we use that more for like real world examples. So it's one thing to have a component in Storybook that has all the configurable things and properties and variants and all that good stuff, but how do I use it? Right? Like how do I actually use it in the wild in real life? So we use that opportunity for our documentation site to show developers like, this is how people actually use this thing, right? And as we are finding bugs and as we're making improvements, we are adding to our documentation site to say, here's a new thing that we did, here's how you use it, here's how you configure it, and then this is what the end product is. So they can go in and they can show like, if I click into an input field and click out and it's the error state, like I can show the error state when I click out if it's blank. And you can show some of that functionality of the components For design, Figma, that tool has come quite far since the first time we actually started working on design systems. And now there's, so I think with the newest improvements that they made with variables and the different types of properties, I just finished doing our text link, so an anchor tag link component. And I took it from like 87 different variants to like 12. Like it's significantly reducing the amount of, of time and like effort it takes to create these components in Figma. One of the things that we use all the time is, cuz there's always this balance between configurable and custom, right? Like custom configurable things or like out of the box, like does this component have everything I need or do I need to modify it? And we're trying to eliminate the modification as much as possible with these new properties and configurations. But at the end of the day, like if you have a form, like we can't tell you what's gonna be in that form unless it's like an address or like an email signup. And even then it's like, what's in that form? So we use a concept called swappable instance all the time in modals and forms and all that stuff. And basically what you do is you will, you have the component housing, right? So you have your modal window, your dialog box that has a heading, a closable, a body of content, and then buttons and potentially even a footer, right? So you have those major components. and the content body portion of it, you make it a swappable instance. So you can then create a component that has all the stuff you need in it, and you don't have to detach the instance. Now you just swap instance on the, the form you just made. And that's been a game changer for us. Like we've seen a significant decrease in detached instances because of that one thing. So it's all about how your team uses it, cuz like that's not gonna be for everyone, but chances are like it's gonna, it's gonna be useful for you and your team, but you have to figure out how to use it or how people use it, which is another sort of tool that we use, which is testing, right? Like it's, this is the same as, as any other UX anything, right? What problem are we trying to solve? How do we know it's a problem? Are we building the right thing? How do we know? Are we building that thing right? How do we know? And we don't know. We can assume as designers ourselves, right? Like, oh, this is how I would use it, right? I would do this and this and this and this. And we just refactored our modal component and we tested it with designers and it was not how we thought they were going to use it. Right? So how you actually work in practice versus the theory of what the component should do are sometimes very different things. So you're always validating that things are useful for your users. And that translates to the end user usage, if you will, is can the designer accomplish what they're trying to with the least amount of detaches, the least amount of configuration, possible.

The, the testing aspect's really interesting. I, I had written down, um, you know, like education, right? Because I assume there, there's probably some level of education you do to, to help make sure designers know what, like, what and when. Like, there's some kind of education, and maybe that's done in the office hours or something like that. But when you brought up testing, I was like, okay, it's interesting because you're— I assume you're testing to see what they if their instincts align with what the expectations should be too. But do you guys do any type of like education or like when there is a new component or an update, do you announce it to everyone? How do you, how do designers know about these updates and how to use these components or even what components exist, right? Or do you just send them the link to your documentation and hope for the best or? How do you do it?

So every new designer, I spend at least an hour or two of one-on-one time with them going over everything. I give them all the links and I show them, here's our Figma components. Like, you make sure you bring this into your project if it's not already, which it should be already. This is how you use the components. There's this So we have, on each component, we have a design spec or design specification and a functional specification, clear space, space between things. But then we also have instructions on how to configure it as well. If you want this state, you need to toggle this. So like if we take button as an example, one of the variants is hierarchy. So primary, secondary, tertiary. So if you— and we take screenshots of the design panel on the side, on the right side, and like have these little like finger arrows and stuff. Like if you want to change the hierarchy, you have primary, secondary, tertiary available. You click this dropdown and it'll give you the list. If you want to show the icon before the text, you toggle the show leading on as true. If you want the trailing, then you show trailing as true and you turn off the show leading. We give them all of this information in the file itself, but people don't read. So the education portion of it, it's like, so we've encountered this problem with both designers and developers to a certain degree, but developers are more used to like having to go to Stack Overflow and find like solutions or reading the documentation for the framework that they're in, like Vue or React or something like that. So they're used to going in and like reading documentation and trying to figure it out. Designers are not as used to that. They're more used to like, I'm going to go on YouTube and find a video or or something like that. Like there aren't a lot of resources. Like some people go to the community forums in Figma, but most of the time there's a video attached to it anyway. So we asked specifically in the last usability test we did with designers, like if you don't know about a component or you want to learn about a component, where do you go? And they basically said, I look for stuff that already exists in the project. So they're going to go into the project that they're working in and they're going to go and find a modal and they're going to copy that modal, paste it in their stuff, and then try and finagle it to do whatever they need it to do. If that doesn't work, then they just reach out to our team, right? They reach out to me and they say, hey, I'm trying to make it do this. And this is where like our team as a service team comes into play very heavily. Because we have our own work to do and we're a very small team, but we try and make time to make sure that people know how to use our stuff. The most effective way we've found for people to understand how to use our stuff is if we sit there with them to tell them, and that's not possible all the time, especially as we're scaling up. Like we're running into problems right now where we just don't have time to do it. And we told our teams like, hey, We want to help. If we had more people on our team, we would be able to field every question within 24 to 48 hours. We'd be able to investigate it, but we don't have that time. And the more people that use the design system, the more it starts coming up. And the more we're like, all of these other tools, like the questions and discussions section of GitHub, the issues section, the lack of tools for the Figma people. And the designers, like all that stuff starts to become evident when you start to scale. So it's hard to give everybody what they want. For sure. Yeah, it's really hard to give everybody what they want.

Yeah, this is a problem I've struggled with on my team as well of do we all align on the the same component names, knowing what exists, uh, it functioning the way it does. Um, we, we also have like a kind of an office hours, but it's not everyone. It's really just like a design system meetings around people that are associated with the design system. And then you kind of expect them to go past that knowledge, but right. It's, it's been a challenge. It's a challenge. Like you said, like trying to, to do that. I think even having the, the culture that people reach out to your team is already more than some that I've seen, which is nice. I did one thing I wondered, 'cause you brought up a lot of development knowledge, right? Like knowing about GitHub or knowing some of the code translations or how much dev knowledge you think is necessary to one, use the, use the design system at all, or two, if a designer wanted to be part of the design system team, right? Right? Say you had an opening for a position, how much dev knowledge do you think is necessary to work on that team or to work with design systems in terms of building design systems?

And that's a great question. To work on the team, you need to have, well, depending on what framework and how your design system is implemented on the code side, whatever code framework whatever you're working in, like you need somebody who is very strong, at least as a senior level person to work on that code base. Because what a lot of people don't understand is all of the frameworks and things that we use, front-end technologies that we use, they're all built on HTML, CSS, JavaScript, right? Or almost all of them are. And if you don't understand the underlying frameworks, then you don't understand what you're working in. And especially on a design system where support becomes quite important, if you're like a team like ours, you need to have that knowledge. You need to be able to go in, pull down somebody's branch of their code, go mess around in it a little bit and say, oh, I know what's happening. Like for fear of getting a little too technical, like one of the issues that we just had, like we're doing some accessibility work and somebody, you know, one of the things that came up in the accessibility check was like the dropdown not being keyboard accessible. And so, you know, on the surface you think, you know, The, my first instinct is to go and check our components in code and not only our doc site, but in our Storybook instance and try and verify the issue in our stuff first. So we did that and we said, okay, it's working in our stuff. Not sure why it's not working in your stuff. So this is most likely an implementation issue. I would check your implementation. And so they go in and they check the implementation. And it's intermittent, meaning it's happening in some places but not the other places. And so what eventually happened was the developer working on that came to us. The developer on our team, on the design system team, rooted around with them in their code a little bit and realized that it had to do with When the component renders, it is one way, it's in one state, right? With an empty sort of array of options. And then the rest of the screen builds, the data comes in and it populates that component with additional information. So the dropdown starts with select, a fruit, let's say. And then the data comes in and puts all the fruit that are available into that dropdown and updates it. But then the reactivity causes it to not be accessible by the keyboard because it didn't refresh the component. So it's not updated. So it kind of sticks. And that's like a, yeah, technically it's an implementation issue, but technically it's our component should handle something like that too. So in, in, at the end of the day, we're, we're fixing it on our end because our components should really do that, but it's not something that we can catch necessarily with our code and Storybook and in our doc site. So like support, being a support team is, is super critical. And if you don't know the underlying technologies behind the frameworks and things like that, like you're not going to catch that, right? You're not going to catch that code and, or that edge case. And we found that a lot of the people, or in my experience, a lot of the developers that we've worked with have been like billed as full-stack developers, but they're more backend developers. And that's So they're not as familiar with front-end code as our team. And so we're finding that a lot of the times we're catching these things simply for a lack of knowledge of front-end technologies. And so when I hire for my team, you have to be proficient in HTML, CSS, and JavaScript, as well as whatever framework we're working in. Because if you don't know the source, then how are you going to detect or diagnose the symptoms? You can't root out the primary cause if you're treating the symptoms. So if your house is flooding, like you're not going to put a rag around a faucet that's drip, drip, dripping. You're going to turn off the water main, right? And you need to know that there are water main exists before you can understand how to turn it off. Right? So if you don't know what the main thing is or what the root cause of it is, like you're not gonna be able to fix it. And so design system team developers, especially like they really need to know their their craft well. Yeah, I agree.

I agree completely. So, you know, kind of coming back to our outline here, what have you liked now having that experience from, you know, your initial past from design system to now working on a design system team? What are some areas that you've really liked, you know, being part of that design system team and leading it?

Yeah. So probably the thing I like the most about working in design systems is I get to utilize my entire skillset. As I stated at the beginning in my intro, I started off as a frontend developer and I did that for 4 or 5 years. I transitioned into interaction and UX design and I did that for a number of years and then I did research for a number of years as well. As well. And to understand the landscape and the big picture of a design system, you need to be proficient in all of those skills or have knowledge of all of those skills. And you can tell since— so we have designers and developers on our design system team. And Designer's going to design, developer's going to develop. And they're like any other contributors, right? Like they focus on their craft and their specialty and damn everything else. And I don't, I shouldn't say it that way because it's not, but they just don't think about it, right? Like they think about it from their perspective. And so Working in as a design system sort of leader, you have to know both and you have to see the outcomes of both. You have to be like a future psychic almost, because you have to know how this and this converge at the end. And what's good for developers is not always good for designers and vice versa. So you have to understand and have lived in both worlds in order to truly understand what the best course of action is. And there are some people that probably have done one or the other first, and that's fine. A true leader is a true leader and they can understand like the best thing for their product. But you start to see the true potential of what design systems are and how they help the companies that people employ them in when you've seen both worlds. So that's probably my number one favorite, most favorite thing about working with design systems is I get to exercise both muscles. And it's amazing to be able to jump into the code and the next day be working on a refactor of a Figma component. That's super cool to me. I love doing that. The other thing that, or one of the other things that I like the most about working in a design system team is the fact that we help people. So I grew up in restaurants. I was a server, bartender, busboy, like my first position or first job was a dishwasher in a restaurant. And they don't call it the hospitality industry for nothing, right? Like, you truly are making like somebody's day by serving them food, right? You know, think of like the Michelin star restaurants in New York that like give people these amazing experiences. Like, do you mind if I tell an anecdote here?

Go ahead, do your thing.

So there's a TV show called The Bear, and one of my favorite episodes is called Forks. And it's about, it's loosely based on, I think, Madison and 24th. It's a restaurant in New York. And the owner overheard as he was going through the dining room, overheard the one table say like, yeah, this is great. Like we saved up and like this was our number one thing we wanted to do when we came to New York. Like we saved up so long for it. But I didn't get to have a real New York hot dog. And so what the guy did was, in the show it's set in Chicago. And so he overhears him say, I didn't have deep dish pizza I was in Chicago. So he ran out down the block to a deep dish joint that he liked, brought it in and convinced the chef to prepare it and send it out as part of their meal. And it made a lifelong lasting impression on them. There's one thing to have a good experience. There's one thing to create a core memory that people will always talk about. So that's how I view hospitality industry and restaurants and things like that. Like, you know, you're there to make somebody's experience like better. And I get to do that by being a service team. Like I get to like help somebody who's super confused, has a deadline at their wit's end. Like they don't know how to use this component or it's not doing exactly what they need to. They can't find it. Find it online, how to fix it. They can come to us and they can get help and we can help them. They can come to us and say like, hey, I was using this component and I thought this would be a good idea. Wonderful. We'll add it to our backlog. You just want to talk about stuff? Like, cool. We can do that too. Right? So I get to do that. Like I get to help people. Use this thing that myself and my team has created and it helps to improve their quality of work, their quality of life at work, right? Instead of having to recode an input every single time, you know, just use ours. Instead of, you know, like instead of having to write this text all the time, like put it in a variable in a file and like you can access that and now you don't have to write it all the time. Cool. So those are probably the two biggest things with working in design systems that I absolutely love is I get to help people. I get to make their lives better and give them a better experience when they're trying to implement really complex software. And I get to use, like, I get to flex all the muscles I've learned over the last 20 years or so. And I really enjoy doing it.

Man, Rob, your anecdote was deep. That like described all UX design for me, right? Like it's creating that experience overall. And I thought that was beautiful.

Yeah, there's a book called Unreasonable Hospitality. I forget who wrote it. It was just recommended to me, but the guy gave a TED Talk and like, I ordered the book like the next day. It should be here like in a day or two, but it's, yeah, it's called Unreasonable Hospitality. I, it's so funny.

I saw this graph on Instagram too that was like, why, why users come back? And it's like, cause you like a small slice is like, cause you had a great product. And the majority of the chunk was like, because you provided such a great experience, right? Like that's what, what people really like. Come back for and enjoy and talk about, um, and things like that. And the, uh, the other thing I was thinking too is like, you're right, man. Like, there's— who, who wants to do that tedious work of creating a button over and over, right? Like, people— we— like, most designers didn't sign up to, to make buttons on Figma. They designed to— they, you know, are looking to create those experiences. They're looking to solve problems. Same for developers. They don't They don't want to sit there and create the tiny things every time. They're looking to build interfaces and, you know, build, not create buttons, you know, over and over. There's much more difficult things to worry about, like logic and functionality, not how this button looks. So that is such a— it just makes people's lives more enjoyable when they're doing it, like doing the work.

It opens it up for better quality work. Like you can focus. One of the things that I hate about working in software development is the, it's the term lowest hanging fruit. Because to me, in my mental image, like, like you can call it whatever you want. You can call it a quick win. You can call it lowest hanging fruit. You can call it whatever you want. But it's the easiest things to sort of put a bandaid on. Like when user experience and design for me is like, I wanna solve the hard problems, the tough problems, the complex problems. Those are the things that give me like satisfaction and And changing one thing to another or removing something because it is potentially confusing or what have you, like all of the quick win, low-hanging fruit stuff is like garbage. Like get it outta here. Like I want to solve the big juicy problems. And when you have stuff like a design system, like you're not, you don't have to worry as much about the quick win, low-hanging fruit stuff because your components are battle-tested, they're sound. They're consistent, and your developer and designer time is spent not creating a rectangle with text for a button, but solving those big juicy problems. You get higher quality work. It's easier to say, yeah, we can do that when I don't have to build everything from scratch. Right.

Let me transition that one, that into, uh, something you had brought up earlier and, you know, kind of into the next topic of some of the hardships around like design system. One you had mentioned earlier was getting that buy-in. And I thought this kind of related to that, right? Like, because of, you know, the, the building a button over and over. So how, how is it that, or ways you've seen successful in getting buy-in for that design system or investing in that design system team? Biggest challenge for your team that, you know, that you can elaborate on or know of?

So the biggest challenge is always adoption. Every place I've worked, the biggest challenge is always adoption. And it's not going to be a silver bullet. Like, I'm going to give you an example of how we did it, but that's not always going to work for everyone. You're going to have to like, figure out what works best for your organization or like your specific circumstance. But the general rule is I can talk about it all day, but until you actually see it in practice, like you're never gonna get it, right? Like everything is good in theory, but you have to apply that theoretical stuff and practice it in order to fully understand it, right? Like I can tell you how to build a car. I can tell you how to make a cake. I can tell you how to do all this stuff. You can follow a recipe, but you're not truly going to know how to do it unless you actually do it or you see somebody doing it, right? And so that was how we gained adoption. We went from like 2 to 3, maybe teams using the design system when I started to now we have like 20 to 25 teams that are using it and counting, right? Like we're, the next initiative that we're doing is focused on getting the next wave of adoption, but it's also show like rather than describe. So what we did was we were trying to figure out how to, get our foot in the door with this big initiative that was happening. And the historical, so first off, we talked to everyone, right? I talked to everyone when I started and a lot of people told me it takes a really long time for stuff to get built. And there's a big problem with designer to developer handoff. So those are the main sort of sticking points why a design system, which everybody thought was a great idea, but in practice like really couldn't be done. So we went and showed them it could be done, right? So I think the project that attempted to use the, what was the design system before I started, took them like 10 or 11 months to build like 2 pages and it's like, cool. Like that's a long time for 2 pages, even if they're really complex pages, that's a really long time. And so what I did was I said, hey, they're doing this new initiative. Like, let's show them that this stuff can be done in under 10 months. Right? So we built one page of like medium complexity, I would say. We built the presentation layer, used, like, we didn't hook up any of the data or anything like that, but we built the page in like a day, day and a half. And we gave it to him and said, here, like, we built this in a day and a half. And, you know, all of the talk about our components are big and too slow and blah, blah, blah. Like we checked in performance, it's like 94% performant. In the Lighthouse plugin in browser. It's 84% accessible. And a couple of those things are very specific browser things that brought it up to like a 91. And we could work together and fix those accessibility issues immediately. So not only is it not taking us 10 months to build, and even if we do like split the difference and say 5 months, per page, 10 months total. We built it in a day and a half. It's 94% performant and it's 84% or whatever it was accessible. And, and that's in the 2 days tops, right? And that was with 1 developer. Now we had 2 developers and what we did to further that was we, the first month or so that the second developer was there, he didn't work on anything. He just got used to the design system. So we gave him a bunch of screenshots from the existing solution that we're redesigning and said, here, take all of these screenshots that are in PDFs. And recreate them with the design system. And so he went in and in a couple of weeks he had like 6 or 7 different workflows, like complete workflows done in like 2 weeks. And we showed them off to the people and said like, this is the power of what can happen, right? Like he didn't have a design at all. Like he had screenshots from a PDF and he went in and there's like functionality that's built in. The dropdowns have like dummy data in them. Like you can use the radio buttons, like it was done, right? The workflow was done, right? And that was the, the biggest selling point for us was we're proving to you, even if you don't want to use it, fine, right? Like that work needs to get done anyway, right? So now not only Did we prove to you that you can do substantial amounts of presentation layer work in a very short amount of time, but it's functional and you just need to remove the dummy data and put the actual data in and you're good to go, right? Like how much reuse is that, right? Like how much work did you save by, by doing it this way? And At that point it became sort of a no-brainer. You know, when we were looking at redesigning a big initiative, they were like, well, why aren't we just building it with that? Like it's already there for us. So we demonstrated it enough, like, and the perceived value, because it's perceived value really. If we did that and the the deciders or the stakeholders said, yeah, so what? Like dead in the water. But thankfully the stakeholders, the deciders, they bought into it. When you, when you give them that sort of value proposition, like, hey, you can build significantly faster and have your development teams and implementation teams work on things like the business logic and the backend stuff and like hooking everything up, like the interface will already be there when you need it to be. That's how we sold it. And now we're working on the next level of that sort of adoption on Teams, which is like using it for all the lines of business, right? So we're making it a true like multi-platform, design system where the underlying code is the same. And now the stuff that I did when I first started, like the jQuery UI theme inputs variables to quickly visually style something, that's starting to come into play now where we can use the same code. We can replace very specific variables and like have 80 to 90% of it like themed the way it should be that matches what exists today, et cetera.

I actually took that as a note as just look, some of the topics you brought up, I feel like they're whole sections that we can talk about. And I feel like maybe we'll have to come back for like a round 2 on some of these discussions.

Absolutely, man.

Such good points like accessibility, multi-platform, company buy-in. Some of these things are really good topics, but we're starting to hit— we just hit the hour, the hour mark. And I think this is a solid wrap-up point. I appreciate what we've covered so far. It was a lot of data, a lot of information. It was actually fantastic here to hear some of the maturity that you were able to shine. Like, I've got— I've worked at a lot of companies that don't have this level of maturity, don't have a any company buy-in, no code connected. So it was refreshing to see what that maturity looks like from, you know, your descriptions and things like that. And it's just like, you know, the shining star of where to get to, 'cause like you said, companies need to buy into that, the amount of time it saves. And if you think about that as how that translates to money over time, it's tons, right? It's so much, 10 months compared to 2 days. Insane, right? Like, so yeah, I just, I thought that'd be great. Let's, let's bring it back for round 2. Thank you for, for everything, Rob. Any, any closing, closing comments? Any way that people can see any, get information from you? Maybe your LinkedIn or something like that?

Yeah, I mean, hit me up on LinkedIn. I unfortunately don't have a Twitter or X accounts anymore. But I'm on Discord, 8-bit.link, and I'm on LinkedIn as Rob Baronas. Feel free to reach out if you need to, if you have questions or anything like that. I do want to leave you with like, where are we going with design systems? And the two big things that I see is a content design system. Where your content lives the same way that your actual buttons and inputs and things like that live. And the, it's getting there, the code in Figma and vice versa, like getting one, like the two-way conversation between code and Figma or design tools, like the line is starting to blur so heavily. Especially with things like Code Connect and Figma and Anima and Supernova starting to do it. There are a ton of tools out there. Use the one that's right for you, but you got to investigate them. What works for me doesn't necessarily work for you, but keep your eye on things like content design system. Keep your eye on things like code, like the two-way code to design and vice versa things. I think in the next year or two, Those are going to blow up.

Oh, for sure. I just forgot we went to that, that con, the discussion with Anima to talk about, to see if it was going to work. Um, and which was fun because at the time too, maturity-wise, it might have worked better for you because you guys had that while we didn't have the code connect, like a code base that aligned with ours. So you're right, there's definitely a lot. And you even see Figma's talks around, um, connection with code. Yeah, that content design system, we're gonna have to talk about that 'cause you're right, that's a Rob left field new age thing that might be there. Just thinking about like what you were talking about buttons, like we have a copyright team, right? Like that uses certain brand standards and stuff like that. So knowing how to or what examples and stuff to put in the button label or descriptions of what things need to be. That, I see a lot of potential for that. We might have to think about that some more. There's, you throw in these ideas that may be revolutionary to the game, which is why I always enjoy talking to you. I just made that last video around the research, right? Research repository. What about, you know, to me, I feel like a lot of these things, if you think about the actual usage of a design system, it is to connect the, like you said, like the development team, the designers, it can connect other people too to usage and, and things like that. Cuz like I said, copywriters, researchers, you might get into interaction design, similar flows. Like there's all kinds of ways that this design system can scale to do, to help connect the people working on products and the products themselves.

Absolutely. Yeah.

Okay. I also wanna say I'm gonna link your LinkedIn into the bio so people can find you.

Yeah.

And connect with you. Um, and until the next time, thank you guys for watching and, uh, see you later.