On Theme: Design Systems in Depth

Naming is hard, but have you tried working with people? with Guy Segal — #15

• Elyse Holladay • Season 1 • Episode 15

Share episode

📲 Text the show your thoughts!

Guy Segal joins Elyse to unpack the messy, complicated world of… people. Guy shares practical strategies from his experience at Thomson Reuters, including the powerful "pre-mortem" exercise he used to rebuild trust and alignment for the design system. They get vulnerable and unpack why (as cliche as it sounds!) genuine listening, storytelling, learning to give and receive feedback, and actively engaging with product teams, is so much more impactful than relying solely on processes or artifacts. Plus, Guy shares why he hated it at first when product teams started using the name of the design system.

Links & References


💖 On Theme is a brand new podcast, so if you like what you're hearing, please hit subscribe and sign up at designsystemsontheme.com!


🎨🎟️ Into Design Systems is May 25-28
Get your ticket at intodesignsystems.com/ontheme

Into Design Systems is back with their annual virtual conference, May 28-30, 2025. Get your ticket now for three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. 

Guy Segal:

Humans haven't really changed, even if the tools have. There's something very, very basic, in the sense that people want to be heard. People want to feel that you hear them. And a lot of the times when you have that friction between people, or like, someone really doesn't want to use your design system, it's mostly because they think you don't really care about their problems. And just asking them, what can I do that would help you? What problems are you facing right now? And how can I support you? Now, you don't have to do everything they say, it's for your consideration, and then you can decide what to do with it. But at the very least, you acknowledge the fact that their priorities are not necessarily your priorities.

Elyse:

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28 30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket at intodesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show. Today on the podcast, I'm super excited to welcome Guy Segal. With over 25 years of experience in the tech industry, Guy specializes in UX, product design, and design ops, excelling in design leadership, and people management. In recent years, Guy has focused on establishing and growing design systems, leading teams to optimize efficiency and enhance user experiences, and he is currently doing just that at Thomson Reuters. Guy and I have become friends over the past year or so in the design system space, and I really value his thoughts, especially on some of the messier and more complicated parts of design systems. So Guy, thanks for coming on the podcast.

Guy Segal:

Thank you so much, Elyse. It's a honestly a pleasure.

Elyse:

Well, I'm really excited. And I'm really excited about our conversation. I say excited way too much on this podcast, but I really, really am. I think that you have some really interesting takes on a part of design systems that we just don't talk about enough, which is communication and dealing with other people. Why is it that this is not a topic that gets discussed enough? Why is it so hard to give advice, and think about, and learn about, how to manage people in design systems? And I don't even mean like, being a manager, I just mean having conversations with people, understanding people like the psychology of teams, all of this stuff. You have worked in design and design leadership for a really long time, and I think you've got a lot of really exciting stuff to share. So let's just dive in. What is the problem here? Why is it so hard? Why do we not talk about it in design systems?

Guy Segal:

I think it's part of a bigger issue where we don't talk about it at all. Design system happened to be just the thing that we're focusing on for this conversation. But communication is 90%—this not a scientific number— but it's 90% of what we do. In design, in development, in product management, whenever you work with other people. When we were talking about what conversation we're gonna have, and I wrote down the suggested name for this episode, I called it,"naming is hard, but have you ever tried working with other people?" And it's, it's exactly that.

Elyse:

It would be so easy, if it just wasn't for all these other people and all of their opinions and all of their feelings. It would be so easy if we could just make components and be done with it.

Guy Segal:

I know, and then just that's it, you're measured by how many components you created and everyone is happy.

Elyse:

I think, I think we tried this and it didn't work.

Guy Segal:

But, but what happens is, and again, this is not unique to design systems, but we are not given the right tools, or sometimes any tools at all, to handle working with other people. We all learn the craft itself. How to do something, how to design components, how to build components, how to work with tokens, all those things. The biggest thing that we see every day is there's gonna be some friction. There's gonna be some conflict. Whenever you work with at least one other person, there's gonna be some friction, because unless you're clones, they're gonna have different thoughts, they're gonna have different needs, they're gonna have different incentives to do things. And it's not always gonna mesh with you.

Elyse:

Uh, as a Gemini and somebody who feels like they have very different opinions all the time, I feel like if I had to work with a clone of myself, I would still have friction, because I conflict with myself all of the time. We are full of multitudes. A lot of the communication topics that we hear about are, you know, how to sell your work, or how to describe your craft. But I think that there's some things that we can talk about today that are much broader than that, right? Like, building trust on a team. How do we help people understand, not just like ROI value, but where we sit in an organization, why we care about the things that we care about. How do we relate to other people in our organization? And I know that you have a lot of experience with this. We were chatting in the pre-show and you have had this experience at Thomson Reuters, where you are now, when you came in to a new team, as a leader on a new team. Start there. Tell us about that. What was your experience coming in? Where was the team when you started?

Guy Segal:

Yeah. So I joined a little over three years ago. There was a new design organization set up. It used to be fragmented across the company. And after the organization was sort of unified into one design org, they also said, okay, now we want to have a team that's going to build one design system for the entire company. So I joined to build that team and lead that effort. And I, in quotes, inherited a team of six people. A combination of designers, UX engineers, content designer, and those were people who've been at the company between, I wanna say five and 15 years. So they've been there for a while. And they got burnt on previous design systems efforts that they tried. So at least two, if not three, that they've worked on previously. And all those, they were—

Elyse:

Yeah, they've seen some things.

Guy Segal:

—they have! And they were successful to some degree, but none of those efforts survived the move to a unified design organization and something that the company believed would be able to carry on. Because the matter of the fact was they brought me to start something new. So they see this and they say, well, again, we're starting from scratch. Why is this time gonna be different? Why would this have any chance of succeeding? And I knew that I had to address that. Because if we didn't address that, if we didn't have a team that believed in a mission, we can't do anything.

Elyse:

Yeah, and that trust and that vision and the belief in that vision, that is underneath all of the other things, right? You can start by doing interviews and doing an audit and all of this stuff, but you're already starting from a whole bunch of assumptions about what the organization needs and what success looks like. How do we surface some of those assumptions and some of those fears, some of the things that the team was worried about? What was the team worried about? Where did their trust fall off? And how do you even start having those conversations? So not like what are the answers, but how do you even start having those conversations?

Guy Segal:

So this is what I did. A big disclaimer to everything I'm gonna say here. This is my story, this is my experience. I'm not teaching the one good way to do everything.

Elyse:

Mmm, this is why it's so hard to talk about communication and people is because there is no one right way.

Guy Segal:

Exactly. But there are principles. And I like to look at it from a perspective of, what is the outcome I'm trying to get to, and how might I get there? What are the different ways I can get there? So this is what I did here. I did an exercise called a pre-mortem. What you do is, you take a group of people— in this case, I took the team— and I asked them a very simple question. Let's say it's a year from now, and this design system project that we're starting, has completely failed. Why did it fail? And it's a design exercise, so legally you have to use stickies. And you write those things and you put'em on a wall and then you group them. And a lot of things came out. First of all, it was a very therapeutic exercise. Like they got to externalize their fears, their hesitations, all that negative things that usually we don't really have an outlet for. Because at work a lot of times you have to maintain a certain face. So the team was very prolific in all the different reasons that they see why this is not gonna work. Mostly surfacing, you know, fears based on their previous experience at the company. And once we had that all out, and we grouped it into different categories, that gave us two things. First, it was that outlet for the team to just express it, express their concerns, in a way that was acceptable, and not just them complaining. And the other thing was, it gave us a guideline to, here are the things that we should be looking out for, and we should actively avoid. A lot of those things were around communication, unsurprisingly. Keeping people in the loop, communicating what we're gonna do, being more transparent, including people in the work. All the things that sound like, yeah, of course you do all those things to be a successful design system team. But many, many times you realize it in hindsight, when things aren't working.

Elyse:

Yeah, and those are all the things that seem easy, to say that you're gonna do, and are actually really, really hard. They're hard to do consistently. They're hard to do well. And I think as an industry, one of the biggest mistakes that we've made around communication of the system itself, of the technical, of the change log, the roadmap, whatever, is simply that we take it to be self-evident, that the design system is good and it is helping people, and that they want to read this information and that they care and that they're excited like we are. And that by having it, it's gonna be a net positive all the way across the board. And having worked on a design system team that really lost its users trust, lost our internal team's trust, like I can share with you our technical vision, but you don't even care about that, when you are like, I don't even trust you to deliver. How do you start building that trust back— like, you can't say, oh, it's gonna be different this time, I swear! How do you start communicating that, first to your design system team, and then you know, getting them to communicate that to, to your product teams, to your potential users?

Guy Segal:

I think the pre-mortem was very successful in that sense because it proved to the team that we are talking about this and we are going to be proactive. Again, not saying we got everything right. And we're still finding ourselves slipping into old habits, or forgetting to be as transparent as we can. But it's definitely better than if we didn't do that planning ahead. I think the really big changes for the team to understand that things might be a bit different this time, and there's a trust from the company, is any sort of external proof.'Cause I can tell the team, oh, it's gonna be different, people are gonna love this, everyone's gonna use it, adoption is gonna be at 120%. But until they see people outside of the team, talk about the team, talk about the design system in a different way, that's not gonna make a difference. So when they hear the Chief Product Officer mention the design system in an all hands, that's a wow moment. Wow. Okay. It's not just us now. There's awareness of it. And when the first team adopted like a few components from the design system and were very positive about that experience, and talked about it, again, that's proof that things are happening. So you really have to seek and grab any sort of, I would call it testimonial, and evidence, that people are paying attention. That's the first step.

Elyse:

So how do you start doing that? When you are also in this scenario where, like, you got brought in to make a new system or change the existing system. That takes time. Even for your own internal team, there's a time lag, between doing some of the work and actually seeing some of those testimonials. How do you kind of manage that, gap that in between like, okay, you've done the postmortem, okay, we're gonna talk about this. We're not gonna just brush it under the rug. I have leadership's ear, like in this case, you presumably have a mandate from people in your organization above you to make it different this time. And of course, as humans we need to develop that trust. What do you do in that interim period, before you have anything to show?

Guy Segal:

That is the toughest period. It's always a question of, how soon after you start to work, people are gonna come to you and ask, when can we see some stuff? When, when are you starting to deliver the components? I think what was really important is to talk about the design system, every opportunity I got. So one of the first things— after that pre-mortem and starting to do some of the work and gathering requirements and those kind of things— we picked a name for the design system, cause I really wanted to have a name that the team can rally around, and would be different from previous names of other design systems in the company. And once we did, I made a big announcement, and I had our content designer write a story behind the name, and why it's called that. And we just announced the birth of the design system. There was nothing else to show at that point, but we had a name, we had an identity. And I tried to grab onto any of those opportunities. So the next big milestone, we had the beginning of a Figma library. And again, we made, we had a live event and we demonstrated it, and we explained how we got to it, and what's next. And really trying to find opportunities. Because again, that demonstrates to the design system team that people are paying attention, and people care about what they do. Because if they don't feel people care about what they do, then again, motivation gets lost.

Elyse:

Yes. I love that. There's this really great quote from Brad Frost, he has an article called Choosing a Name for your Design System. He says,"A design system's name is its brand name, and that name becomes a shorthand that encapsulates and embodies what the whole effort is about." I love that so much, because that rallies us around something, like, oh, we're doing it differently this time. And all of those little things start to build that, that trust, that sense of community, that sense of— maybe this is a little bit of a, like, spicy way to talk about it, but that sense of specialness othering people can be really, really damaging, but we love to belong, we love to be part of an ingroup, we love to have a label to apply to ourselves, to bring us together so it can be really positive as well. And so when you have a group of people that's like, hey, we can all get behind this effort and we are the, what's the Thomson Reuters design system?

Guy Segal:

Yeah. Yeah. It's called Saffron.

Elyse:

Saffron, right? Like, we're the Saffron team, we are on board. This product team, like we're so excited about this Saffron effort. That matters so much because people naturally really wanna belong to a thing, and when they belong to a thing, they wanna see it succeed. And so I love these little, this one trick! But that's really understanding how people are, I think.

Guy Segal:

I remember the moment where people started using Saffron, the name of the design system, as a verb, like, we're going to Saffron-ize this product.

Elyse:

Oh I love that!

Guy Segal:

And I hated it in the beginning. I hated it. I did not like it. But you know what, people starting using it so much, that I said, you know what, okay, as long as they're using the design system, I'm okay with that. And again, that was another point of proof that, the design system is now in the consciousness of someone else, right? They're using it as a verb. It's something that is part of their language.

Elyse:

Yeah, I love that. That shows buy-in. We are like, oh, buy-in. And we talk about adoption and metrics and numbers and all of this stuff, but to me that's what buy-in looks like. When somebody is like, I've changed my language, I've changed my behavior, and I'm like participating in this, as a thing. So during this phase, how are you talking to leadership? I feel like the communicating to leadership, getting leadership buy-in is one of the most challenging, like hottest topics in design systems lately. Obviously because of layoffs and because of failed design systems, we all wanna know like, how do we do this better? Um, but that moment, that period of time, again, where just because you had an organizational mandate to come in and make a unifying system does not necessarily mean you're gonna succeed at it. And there's a period of time where, you're starting, and you just aren't seeing a lot of output yet. I mean that's, that's true in any kind of product, right? Like you build a new product and you have a couple of months where you're just getting your stuff set up, you're getting your infrastructure set up, you're like getting the pages set up, and it's like it takes a while before you can get to any kind of MVP level of product. As the leader of this team, you're communicating to your people, your design system team about trust, and about how do we see buy-in. How are you going the other way? How are you communicating to leadership about what y'all are doing, whether or not it's working, and how they can be speaking about the system and the effort and the trust, in the interim.

Guy Segal:

So we had a plan going into this. So we had a year long plan and we said, in Q4, we're going to release version one of Saffron. And this is everything it's gonna have. Like our assumption. We didn't say how many components, but we said it's going to come with this type of documentation, it's gonna come accompanied by this. Of course, every plan, you know, once you start it, it becomes obsolete because reality hits. So even though we said, we're going to release version one at the end of the year, we started to get questions. Or suggestions, I would say. Hey, we would really love for our designers to start working with the design system, where is a Figma library? We learned that we just can't plan a full year ahead with full confidence, right? You can plan a quarter, maybe two, but you know, every year since we started a design system, we've had curve balls thrown at us. And they were all good ones, but we had to really pivot quickly and adjust our roadmap. So in this case, the first year was okay, we would love to have a Figma library by this date. We had a date that we had to hit. So again, we had to change the way we were working. Instead of taking our time and thinking everything through. Some of it was remnants of bad habits, I would call it, of, we need to have everything figured out before we release something. We need to get it right the first time'cause we won't have a chance to fix it. And we had to break that habit. So what we did was, we went to a few of the big products that we knew were going to adopt the design system, or were supposed to adopt a design system. And we asked them, what is the bare minimum that you would expect from a component so you can start using it in your designs? Doesn't have to be perfect. It's not gonna have everything, but what is the must have, that you will refuse to use the library, if it didn't have that? And we got a list of things that it must meet. And that became our checklist that we call ready to use. And that gave us the confidence to start to be okay with releasing things that may not be a hundred percent of everything thought through, but had enough that people can use. And how did we know they're gonna use it? They told us. So that helped with being able to be okay with a decision to release something before it's a hundred percent perfect.

Elyse:

Wow, there's so much to unpack there. But I wanna dive into this idea of bad habits or you know, maybe get into like therapy speak a little bit, right? Like our past stories! But that really affects how we see the world, and how we see other people, and how we think our capabilities of success might even be. And if you've had an experience as a design system team that once you put something out, it's really, really hard to update, and even if you do push an update, the teams won't take it, of course, you're gonna go into any future scenarios going, we have to get it exactly right the first time, otherwise, like I don't wanna just be responsible for putting out some crappy stuff that then is locked in forever. It is so hard to change that kind of behavior, because it is not a thing that you can tell someone, is going to be different, they have to experience it being different, like we were just talking about. Design systems are often a vehicle for organizational behavior change. Because think about all the things that have to change to make it different this time. The teams have to be willing to adopt it. The teams have to change their behavior. The teams have to be willing to do more upgrades. This is why I think it's a problem that we think that design systems make it self-evident that these things are good. We say, oh well we're gonna do more releases, therefore the team is gonna see that they will be able to get more releases, therefore they will change their behavior. And that has just not been my experience that it will just happen, right? like, oh, if we build it, they will come, they will change their behavior. They will not, unless they see that there's something in it for them. Or if they are being communicated with about why this matters. How did you go talk to the team about that? The product teams or your team?

Guy Segal:

That is so tough. You're absolutely right, like, we build a design system, we know it's good, right?'cause we built it. It's awesome. It's amazing. Why would, like, it's, it's a no brainer. Everyone should use it. And then, you know, turns out that, uh, no, people have other priorities. And even if the, the chief technology officer tells them, hey, everyone should use the design system now. Still. No change. And it's such a common trap to fall into. I know there's a big thing, big discussion around, do we look at the design system as a product, yes or no? But this is one of the things where it is just like a product. Where, how many product companies have you seen that they think just by having a product, people are gonna use it, right? This is the same thing. We know how good it is, but we're not taking into account how it's going to miss our users. You talked about change management. Think about something as small as, a developer who's been using React, and they get a design from a designer, right? They get a Figma file. And they're building that page using React. And if they have issues, they go online, they look up things, or they use GitHub Copilot, whatever they use. But they're pretty self-sufficient. Now we're coming in and we're telling them, no, use our design system. So now if things aren't working, they need to come talk to us. It's a new pattern of behavior that I need to adopt, which is I need to work with another team, to get the stuff that I used to just rely on myself or the internet, now I need to bring someone else into it with their own timeline, with their own priorities. It's gonna mess me up.

Elyse:

And the incentives are often really, really not aligned, like the incentives are not there. Because I'm, if I'm that engineer, I'm going to standup every day and my manager's going, when are you gonna deliver this feature? When are you gonna get this thing in? Are you gonna do it this sprint? And even in a really, really great culture, you know, not punitive, there's still pressure. And so what is the incentive for me to be like, yeah, in three weeks when the design system team gets back to me. Like, no, I'm just gonna do it. I'm gonna ship some stuff. Like I, I ain't got time for that.

Guy Segal:

And this is exactly why it's so important to, again, not just for design systems, but in the case, of you want someone to adopt this, what is the incentive structure that they fall into? What are they incentivized for? What is their performance review based on? And if it's number of features shipped, then, why would they ever wanna slow themselves down to learn how to work with a new design system? That's, that's ridiculous to, to expect them to do that.

Elyse:

Yeah, and this is why we can't just say, oh, efficiency, because sometimes it is more efficient not to. And if we're not thinking about that as a system team, we can't actually address the real things that are going to make our team more efficient. How do you look at your organization, and how do you look at your product teams and start to identify what it is they actually need? Not just components, right? Like that, that part is a little bit easy, in the sense that we can look at our product roadmaps, and we can go to their designers, and we can see some mockups, and we can do some user testing, and we can kinda get a sense of like, okay, what components are gonna be most valuable? How do we identify those things that are actually going to change people's behavior? How do we identify the places that could even use change behavior or different incentives or that actually affect the way that our teams are working? I'm thinking about, you know, the stupid Ford product quote about, they wanted a faster horse.

Guy Segal:

Mm-hmm.

Elyse:

How do we do that?

Guy Segal:

So that's a really good question. And there's no one good answer. It, it's, it's really, I mean, I can't believe, I haven't said"it depends" yet on the podcast.

Elyse:

It depends. That's the other title of this episode.

Guy Segal:

Yeah. So I can think of an example. it's very similar to the strategic initiatives of the company. It's not just understanding where we can plug the design system in to scale a solution for the company. But you can look at it on a personal level, like how is this new work that's coming in, not only changing our priorities, but changing the organization's priorities? Because it's now, this is the thing that everyone has to focus on. How is it affecting them? So they need to change what they're doing. Can we be there, and help them do it quicker? I'll give a an example. Every now and then we have big initiatives around accessibility. Hopefully by the time this airs accessibility still something that's okay to talk about, but for us it's something, I don't know if you're laughing or crying.

Elyse:

Um, both. Please continue.

Guy Segal:

But it's something that is, is top of mind for us. We have a couple of accessibility specialists working with the design system to ensure that everything we release is accessible. And it's something that the company itself really believes in and puts a lot of emphasis on. And if there's a big push to increase the accessibility within a product, for example, or eliminate accessibility related bugs, that is something that, if we don't do anything, the engineers, it's on them, right? They're there to fix those bugs. But if we can come in there and say, hey, let's work together, let's figure out, again, scalable solutions to those things that maybe they could be part of the design system, maybe it is just hey, here's a way for you to use this better. Every time you help someone with something they need to do— and again the big problem with the initial adoption is that you're not really solving a problem for the developer who's going to use that.'cause they need to change a lot of what they do. So you introduce complexity, you introduce a challenge. But if you come in with the specific purpose of, hey, you have this current problem. We have a solution for that, or we can get you there faster or better. You're being a partner. And I think this is a, being a partner is something that is missing from a lot of design system to consumer interactions.

Elyse:

How do you start to identify those things in your organization? Some of them are obvious maybe because leadership is saying we need, insert initiative here. We need AI tools, we need to speed up cycle time or delivery time. I mean, sometimes these things are mandates that we can latch ourselves onto, but sometimes they're not. How do you start to identify those gaps, those communication and incentive and behavior gaps and changes?

Guy Segal:

The solution to almost every one of those problems is gonna shock you. It's called talking to people. This is something that took us a while to get better at. It took me a while to get better at. But really trying to stay on top of the big initiatives, the strategic initiatives of the company. I don't know if you heard but there's this thing called AI that some people are talking about here and there. Our company, much like a lot of other companies, are putting a lot of stock in incorporating AI into the products, which means translating it into the building of interfaces. There needs to be new ways of, for someone who's working with a specific product, how do they access those AI features? How do they work with'em? How do they integrate into their user interface? Knowing that if we don't have a design system in place, if there's no one standard across the company, each team is going to design and build their own unique approach to that. But if we say, okay, as a design system, we're going to help with that. We're going to work with you, we're going to standardize it, we're going to incorporate it into the design system. So there's a scalable solution. I think, identifying what are those points that we can scale, fix, or solution for the rest of the company. Those are really important things to look at and really bring to the top of your roadmap.

Elyse:

I love that. And I, you know, even though we talk about pace layers, and the design system should move slower, I think this is also a really exciting place for a design system to sit, which is, maybe working with one pilot team to get that interaction right and then, scale it out across the org.

Guy Segal:

I remember, I worked at a different company. I was leading a project— it wasn't design systems, it was a regular product design and build— and I was leading the design team on that. And one day, one of the designers, my designers, comes to me and says, hey I designed this, but this is what engineering built. And it doesn't look anything like what I designed. The thing was we were all working in one massive room. And I asked, did you talk to the engineer? And he said, no. So I kind of like made him. Said, go, sit next to the engineer and figure it out together. And then also said, okay, we're not gonna show anything design related to the client before we have approval from engineering. And again, these are very common things, right? You know, engineers and designers working together, but it's not something that comes in natural. And I don't know why, but every project I worked on, I had to reinvent the wheel of people from different disciplines talking to each other. So in this case, a lot of the times we just had to go and talk to developers, talk to designers, understand what's working for them, what's not working, what they're worried about, what keeps them up at night. Like the question I love asking most when I talk to a stakeholder is, what's keeping you up at night? A hundred percent of the time, it has nothing to do with what's keeping me up at night, or what I'm worried about, or what I want them to do. But as soon as I know what they're worried about, I can understand. I can try to find ways of how my solution can help them with that. But it has to be, has to start with talking, because people are terrible at mind reading.

Elyse:

Yeah, we have not developed that skill yet unfortunately. I think we learn so much by, actually, that's not true, I know that we learn so much by going and sitting with our counterparts, whether that's design or engineering, cross-functional, or you know, just going to sit with our product teams. I think a lot of times we wanna do this communication by formal governance process, office hours, like these sort of artificial spaces, where we expect somebody to come, give us a presentation. And that really, as much as we try to say, oh, it's just a conversation, oh, we're just gonna talk, it's still so divorced from what the real life work and process and day-to-day experience and incentives are. I feel like I identify situations where I can make influence from the design system, most often by, being at other people's PRs, or going to their sprint planning, or like getting in a conversation in real time, like in our engineering Slack channel or in our front end channel, when somebody's asking a question about something and just being like, hey, what are you doing? Like, hey, can I watch? Can I shadow this? Can I, can we pair? And it's always such surprising stuff, it's always stuff that I would not necessarily identify from higher level conversations or from tickets or from roadmap planning. It's always like, you didn't know that we had this tool over here, oh, I've only said it a hundred times. you know, but that's that's I think, part of the job. And when we think that we can just, do formal communication or do you know, formal governance, I feel like we're missing out on so many opportunities to actually understand the of what it's like to build products in our organization. Um, and that in some ways hasn't changed. Like the design system as a tool is really different than it was maybe a decade or 20 years ago, but how we build products in a lot of ways is like, I don't know, it's just a bunch of people coming together in a room and making stuff.

Guy Segal:

Humans haven't really changed, even if the tools have. And it's, there's something very, very basic, in the sense that people want to be heard. People want to feel that you hear them. And a lot of the times when you have that friction between people, or like, someone really doesn't want to use your design system, it's mostly because they think you don't really care about their problems. And just asking them, what can I do that would help you? What problems are you facing right now? And how can I be, how can I support you? Now, you don't have to do everything they say, it's for your consideration, and then you can decide what to do with it. But at the very least, you acknowledge the fact that their priorities are not necessarily your priorities. I can't even count how many areas of friction were smoothed over just by having a coffee or a drink, a beverage, with another person that you have a conflict with. And just talking, and just listening to them. And it makes a huge difference when someone thinks, oh, you know what? We may disagree on some things, but I know we can figure it out together.

Elyse:

A little bit of a tangent here because I think that this is so important. How do you have the emotional space or the emotional fortitude or steadiness a leader to do that. When we are unable to go into conversations like that with equanimity, right, we get reactive and we get mad or we don't listen. I'm sure we've all read about active listening, but the truth is those are skills that we need to have when we go into these conversations. What are some ways that, that you manage that, and maybe even more difficult, how as a leader do you help your team manage that, when they have to have those conversations?

Guy Segal:

A lot of practice. Like I said in the beginning, no one teaches you how to do it. I have this talk that I give, and it's all about how you give feedback to another person about their behavior. Like let's say they do something that you want to continue, how do you give that feedback? Or in a lot of cases they do something that you really don't like, how do you give that feedback?

Elyse:

Not the compliment sandwich!

Guy Segal:

Never. The compliment sandwich. I don't call it the compliment sandwich. I call it a different type of sandwich. If schools taught a very simple framework of giving feedback to another person, there will be so many problems solved. Not everything. But if you actively want to make things better, learn how to give that feedback and practice it and get better at it and become comfortable doing it. That's what I do with other people, and that's also what I try to get my team to get better at and practice. I didn't invent anything. You can find it in a ton of books, but it's the very basic method of talking about, here's something you did or said, and this is how it made me feel. And if the person is not a psychopath, they would probably want to change that,'cause they don't wanna make you feel that way.

Elyse:

Yeah, it's tough though. It's tough to receive, especially negative or critical feedback, which is obviously why we default to the compliment sandwich, but, such a critical skill to learn. Managing your own response is one of the most valuable skills that I think I have learned as a design system practitioner. I got some really, really challenging feedback on my behavior around being defensive and being aggressive towards my teammates. This was a number of years ago, but I was not in a really good place personally. And as soon as anybody questioned my work, like we could not have a conversation anymore, like, I was so defensive that I was unable to participate meaningfully. I think the hardest thing to realize, was that I didn't even know that that was happening. And this is the really hard part about this kind of emotional work, is that, I was so deep into my own shit that I couldn't even tell that my relationships with my teammates were being impacted by this. I think the hardest part about it was that the feedback had to come from my manager because my teammates didn't even feel like they could talk to me about it. So they had to go to my manager and my manager had to be like, listen. You, you have to get your act together. Man, that was a really bitter pill to swallow. One of my pieces of homework was to literally go apologize to my coworkers and recognize that my behavior was bad. And I think about that as one of the best things that has ever happened to me. I know it's such a cliche to be like, oh, feedback is a gift. But I could have just gone on blithely being an absolute shithead to my whole team and probably gotten fired. And still would not have known that that's why I got fired. And then be mad for other reasons, and then be like bitter and resentful. And like instead I had this opportunity to be like, hmm, I, I don't wanna make my teammates feel bad. I don't wanna be unapproachable. What, what is going on? And how do I even see that? And I think as design system practitioners, that the takeaway there, well, for me anyway, I won't say for anybody else, is that we can't be effective collaborators if we're not willing to hear feedback. And I was talking a minute ago about my, personal behavior feedback, um, but even feedback on the system, right? We were saying earlier, it's self-evident that it's good and that it will help your team. And this product team goes, nah, it, it actually kind of doesn't. And we go, yes it does. It totally will, if you just use it. Shut up. We don't think that that's what we're doing. And I, that's really the point that I wanna make, is we don't think that that's what we're doing. We think that we are being completely reasonable by saying yes, but it will give you efficiency in the long run, just trust us. And how do we make the space to hear, nah, it doesn't though.

Guy Segal:

That is so humbling because working on design systems is a bit of a different flavor than being a product designer. When you're working on a product, someone is using it, usually someone outside of the company, and you may hear some feedback on it, through user testing or market research or, you know, if someone really hates your stuff, they're gonna post about it online. We don't have that luxury working on a design system team. Because the people using that, they may sit in the next desk. And they're vocal about issues with the design system. So design system teams can get burned out really quickly because most of the time people talk about those things when something isn't working.

Elyse:

Good design is invisible.

Guy Segal:

They don't run to you to say— I know!, no, it's very rare when people come to you and say, wow, the design system is exactly what I needed to do, best design system ever, thank you so much.

Elyse:

That'd be nice.

Guy Segal:

It doesn't happen that often. Right. Mostly you hear how shitty it is. And that can really get to you. Especially if you put a lot of, or you see your craft or the work you do as part of who you are, which is not uncommon in, in the world of design. When I get that kind of feedback, even with everything I said earlier about, you know, having good mechanisms to provide feedback and work with feedback, it still stings. I'm still, you know, fuming for a day. Then I cool down and say, okay, people have an issue. Whether the specific feedback they gave is correct or not, something is bugging them. Let's go find out what the specifics are,'cause if someone gives me feedback that, oh, your token system is unusable, nothing much I can do with that. But show me what you're trying to do. Let's figure out. Sometimes they're not using it correctly, or they don't know how to use correctly. Could be our horrible documentation, I don't know. Sometimes it's something that's very valid. We could be doing better. I'm really trying to train myself and the team to say, okay, our reactions are valid. No emotion is invalid, but they're not productive, in a sense, they're not gonna move us forward. Let's go back and let's put the onus on the people who are complaining to tell us what specifically isn't working for them, and then we can work with that.

Elyse:

There's another really good takeaway in what you just said though, and that is sussing out the real information out of shitty feedback. If somebody comes and says, this is unusable for me, you're right, you can't take action on that. But instead of being like, well, you're wrong, it's totally usable, you just must not be using it right. Like, okay, what's in here? How do we figure out what to do about that? And I think that's a really valuable skill to practice, for anybody who's listening once like an actionable takeaway, is figuring out what's underneath was actually said, which may or may not actually be helpful, or may not even be true. I was reading this in like a leadership blog, it was really geared towards you know, C levels or directors plus whatever, and it was like, complaining is not a behavior to squash or to reduce, like complaining is feedback. We think about complaining as oh, that's not productive, right? You're just griping or like venting or whatever. But underneath a complaint is a real request for, hey, like, this isn't working for me, and I, and I'm complaining because I don't know what to do about it. If I knew some productive way to approach this problem, I probably already would have, or I have already tried and it didn't go anywhere, and so the only thing left to me is to come to my manager and be like, oh my god, this really sucks, this thing is terrible, this thing is unusable.

Guy Segal:

That is so true because if someone gets to the point of they're complaining about it, when they could have come to you earlier and say, hey, this isn't working, the big question here is, why didn't they? Did they feel uncomfortable? Did they feel unsafe to come to you? Do they think you're not gonna do anything about it? And I'm not saying I have an answer for that, but,'cause they could have different scenarios, but it's really important to, once you establish a better relationship with that person, is try to understand from them what was preventing them from that collaboration or that work of coming to you earlier. Maybe it's something that, again, they've never done in a company they're not used to, working across the aisle with someone.

Elyse:

Yeah. So I wanna go back to your story. Take us a little further down the timeline. As you started to build things, as you started to talk about the system at all hands, internally to teams, presumably have feedback sessions with teams, and talk to your leadership about what you were delivering, how did you start to see what you would call success around communication and trust? You mentioned when teams started saying like, we're gonna Saffron-ify this. What were some other signals? And when did you really feel like there was maybe momentum around that and that everybody was really feeling, oh, oh, like, okay, maybe this is actually working now. What was that moment where it felt like things were really starting to change?

Guy Segal:

I think the big change or the big noticeable change was, how many teams were working with the design system and starting to adopt it. It's the fact that they were seeing other teams doing it and that actually built the most trust.'cause again, we can try to sell the benefits of the design system, but until they see someone else using it, and using it successfully, they're not a hundred percent bought in. And again, I mean, even then still, they have to use it and they have to see that works for them to be bought in. So there's so many, so many points along that line that you have to keep working at building that trust. It starts from you proving to them that, hey, this can actually work within your system and your system didn't crash. And hey, look, this other team did that, and they were able to go to market at half the time, because they used the design system. And now look, you did this and it was released, and customers love the new look and feel of the product because this is also something that comes in with using this new design system. You have to constantly sell your design system. The second year, after we released version one, I did something like 10 different roadshows with product and engineering teams. Just, you know, doing a song and dance about, what a design system is in some cases, because some people did not know, and why it's good. And here's what we have in our design system, and here's how you can start using it, and here's who you can come talk to. And we have this, we have our engineering people who can come in and do like a couple of very short sessions to do a proof of concept to see that it's working. But you have to put a lot of effort into building that relationship and, and a lot of it has to come from you because you're the one who wants them to use your product.

Elyse:

How do you feel like your communication changes from the sort of like digging yourself out of a hole, low trust moment, to the, okay, we have something and we're going on this road show and we're doing the maintenance selling. What's the difference?

Guy Segal:

It never stops. It does change in the sense that we have more data to point to. So we have success stories, we have anecdotal data, we have benefits that we see with our customers, and we have benefits that we see from teams that have been using it more than once. This is the big thing for us. Because through our research, we see a big difference in sentiment between teams that have used it once, and teams that have used it more than once, because they are the happy ones. They're the ones that they can say, you know what, using your design system shaved off 15 hours of work. It may not be the same for every person, but the fact that they can point it out and say, yeah, that actually helped me. Those are the people who are using it themselves. So bringing those stories, it's like a light at the end of the tunnel. If you get over the first hump, you know, there's a life of riches waiting for you on the other side.

Elyse:

Yeah. And I love that anec-data. I love the storytelling. It's one of the biggest opportunities I think for design system practitioners. We've been talking this whole episode about, we're humans, humans have feelings. We like to belong, we like to rally around a goal. We love stories. And I know I've said this before, but when we think about leadership, they're just people. They, they also love stories. They have jobs, they have goals, they wanna hear the efforts that they are promoting, or leading, are doing what they want. There is no better way to show that than, telling a story about how that's actually happening. The numbers can be so meaningless without the story. Well, we have 30% adoption. Okay, of what? Is 30% a lot? Is that a lot of teams? Is that a lot of components? Was it zero before? Was it 29 before? Like how is this relevant to the thing that I'm trying to do?

Guy Segal:

Every number, you can add a"so what" to it. I think that is something that a lot of times people miss, or forget to say, oh, like you said, yeah, we have 30% adoption rate.

Elyse:

Okay.

Guy Segal:

So? Is that good? Is that bad? I don't know. But if you add the meaning to it, right, what is the meaning of that number? That is what tells the story. That is what is going to make the design system something that is desirable.

Elyse:

And those stories do not have to be so glamorous: this completely changed our workflow and now we can instantly build things and everything is visually consistent 100% of the time. I get so much mileage out of like the littlest shit, when I am talking to my team and my engineers, like somebody says in Slack, wow, really cool, super helpful, I didn't know we could do that, now I'm totally gonna do that. Screenshot, brag doc, share with my manager, put that in the public channel, like I am all over that shit. Because even though it seems really small, you're surfacing these moments where people are like, hey, that's actually really helpful, oh, I didn't know that. And the more you surface it, the more other people know about it. And then your leadership is, oh yeah, look like these things are happening. That's all storytelling. It doesn't have to be dramatic. It doesn't have to be All Hands presentations. Um, I think there's so many ways to just pull out these little experiences that people are having, when they're positive and surface them to everybody.

Guy Segal:

Especially because a design system is, is a mechanism for skill. They don't have to be big numbers. Like even if you make things 10% faster, it's five weeks in a year, right? You're able to shave off five weeks from a year long project, that's massive for a company. If we're looking at a product that is not using the design system, and a product that is using the design system, and a product that isn't, has, 10 times more accessibility bugs than the one using the design system, again, that's a big thing because it's gonna take more time to fix them.

Elyse:

Speaking of storytelling to leadership, I wanna go back to, we were talking about constant selling of the system. What advice would you give to design system practitioners who like, I just wanna make good designs. I just wanna make good code. I care about building that experience for my product teams, but like, I didn't sign up to be in sales. I wanna build a good system. I wanna build components. I did not come here to spend all of my time making presentations or, doing storytelling, or doing sales. would you say to them?

Guy Segal:

This is exactly the, if you build it they will come. And that never works. Every company that works on a product, just by the fact they're so close to it and so invested in it, their perception of it is usually higher than reality, like they think it's so much better than what it actually is. And on the other side, the people that are potential users, they see it as something that is much worse than it actually is.

Elyse:

They're like, so what?

Guy Segal:

Exactly. Because of the effort they need to put in, right? They need to change something about what they do already to use this new thing. So there's this big discrepancy between how we think about the design system, and how others see the design system. And the value of the design system, because of that, is not gonna be self-evident evidence. Take it to the personal dimension where— you know, no one likes this— year end performance reviews. There's some point in your career that you realize that you have to start selling yourself. And your manager doesn't necessarily see everything you're doing the same way you see it. Design systems are exactly the same thing. You have to, you have to convince people that this is something they should invest in using. That's not gonna happen on its own.

Elyse:

Let's get a little tactical for a second. What are some other tools, communication skills, that we need as design system practitioners, to practice or learn?

Guy Segal:

A big thing I don't see happen too often, on the design system team, is design critiques or any sort of critiques. That are, again, something that's very different from criticism. Critique is not intended to say this is good or bad. Critique is a, a learning opportunity. And it's not just about how do we make this thing that we're looking at better, but it's also, what can I learn about this thing that we're looking at, to make my own work better? I think this is not happening enough. And we're actually starting to do more of those because again, we wanna make sure that we grow as a team, and we develop a shared language around how we talk about those things. That's that's a really simple tool that again, I think is just underused.

Elyse:

Didn't you just do a presentation on this not that long ago?

Guy Segal:

I did.

Elyse:

If anybody who wants to learn more about critique as a skill, I'll put Guy's presentation on that in the show notes. What else? We talked about storytelling, we talked about crit, we talked about feedback. What are some other communication or people skills that we need to focus on?

Guy Segal:

Listening. I know, all these are cliches, but they're cliches, but they're cliches for a reason? Because they're important. You have no idea how many times I'm at a meeting and people talk because they wanna say something, not because they react to something that someone else said. A lot of times when we don't really listen, we wait for the other person to stop talking, and then we say what we wanna say. And actively listening to what the other person is saying, and trying to figure out why they're saying it, what they actually mean, what they're trying to get to, is so important. Because again, that's another mechanism for you, to make them feel heard, which is going to build that trust between the two of you.

Elyse:

I will add to this list, and I will say, having a better understanding of how other people learn and process information. Listening is a skill, but so is understanding that other people input and output information in different ways. I'm a very verbal processor. I don't have a thought unless it's coming out of my mouth. That can, and has, made conflict, because other people can perceive that as me not listening. Other people really like to take a prompt or a problem and go away with it, and think about it, and write about it, and have some quiet time with it, and then they can come back and participate in a discussion, right?, like not everybody is great at externalizing their thoughts in a meeting on the fly. And so I have found a lot of value in learning about how my teammates are as people, and what they like and how they like to communicate. And just saying, do you wanna get on a call and talk about it? Do you wanna write some feedback? Do you wanna send me a video? What are you like as a person and how can we best communicate? And I think that we have, corporate business, tech industry culture is very much, on a call or write a doc. And there are just lots of other ways to communicate, and I think when we can meet people kind of where they are, we have a lot more to actually get to the real thing that we're trying to talk about.

Guy Segal:

That's so important and it's one of the things I actually, I try to teach new managers, that it's so important to get to know the different personalities under a team. The biggest trap is, and it's something that I fall into, other people fall into, is that expecting everyone to behave like you.

Elyse:

Mm-hmm.

Guy Segal:

And this is where a lot of the friction comes into play. Because you see someone behaving in a certain way, or saying something, and you interpret it based on, like, if I were to say that thing, that's what I would mean, therefore that person is an asshole. But you, I don't know why they said that or what they were thinking. I'm applying my expectations to it. And once you learn how other people on your team like to take feedback— not everyone likes to get feedback the same way. How they like work. to be delegated For example, I sometimes get very anxious when something unexpected is happening. Oh, there's this task that came down from head of design and we need to do this. And I learned that I just need to step away, take some time, digest it, and then I'm ready to go. And the great thing is, that my manager learned that as well about me. So they know that they need to give me that space, and then I'll be fine. But without that, it's gonna be really hard for me to work with that. And if you get to know the people on your team or people you work with and get to know how they like to work, that's gonna make your life so much easier.

Elyse:

All these things we're saying like, oh, listening, like, it's so cliche, I think sometimes the most obvious stuff is the stuff that's easiest to miss. It's common sense, it's right there. Of course we're all doing that, we all know that listening is important! I'm listening, I'm listening right now! It's like, okay, we gotta stop and actually think about how we integrate that individually for ourselves, for our teams. Guy, thank you for taking us through all of this stuff. And thank you for coming on the podcast.

Guy Segal:

Thank you so much for having me and uh, let me just ramble.

Elyse:

It was great. Okay. So, you know, everybody knows, at this point at the end of the show, we always do a spicy take. You ready for this?

Guy Segal:

Mm-hmm. I don't know how spicy it is, but I think we get so caught up in tools and processes and guidelines and principles, that this is our go-to when we try to fix something, and we don't consider that it's a people issue. It's always about people. If your solution to a problem between people is referring to a RACI chart, you failed.

Elyse:

Mmm. For our listeners who maybe don't know what a RACI chart is, can you elaborate?

Guy Segal:

It's responsible, accountable, consulted, and informed. It's basically defines the lanes that people are on a project. So this is what you're allowed to do and this is what you're not allowed to do. And if this is the, this is what you have to resort to, to say, oh, you're not allowed to do this, instead of trying to fix the actual human problem... you're done.

Elyse:

Yeah, do love a RACI chart. They can be very valuable, and you're absolutely right, we resort to artifacts as solutions. There's so many other creative avenues that we could also try. So, I love that as a takeaway. Thank you.

Guy Segal:

Thank you!

Elyse:

Thanks for listening to On Theme. This is a brand new podcast, so if you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!