In this episode of The Design Systems Podcast, Chris Strahl welcomes Guy Segal, the director of digital ecosystem and design systems at Thomson Reuters. Guy shares his experience of building a design system that serves over 150+ brands and the importance of having a point of view when you are working to bring both quality and consistency to a large portfolio of products. From design system missionaries to trojan horses to carrots and sticks, Guy and Chris talk about how to gain the buy-in you need to build a design system product teams will want to use.
Guest
Guy Segal is a design leader with over 25 years of experience in the tech industry, specializing in UX, product design, and DesignOps. Leveraging his passion for design leadership and people management, he has a proven track record of fostering innovation and collaboration within design teams, establishing and nurturing design practices, and leading teams to success. Guy's expertise extends to various domains, including product, UX, and service design, as well as a strong background in web and UI development. In recent years, he has been focusing extensively on design systems, establishing and growing teams around the practice, and launching systems that optimize efficiency and enhance user experiences. Beyond his professional endeavors, Guy is an avid enthusiast of board games, food, and movies, welcoming conversations on diverse topics that extend beyond the realm of design.
Guy’s Design Downtime podcast: http://designdowntime.com/
Transcript
Chris Strahl [00:00:00]:
Hi and welcome to the Design Systems Podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at knapsack.cloud. If you want to get in touch with the show, ask some questions, or. generally tell us what you think, go ahead and tweet us at thedspod. We'd love to hear from you.
Hey everyone, welcome to the Design Systems Podcast. I'm your host, Chris Strahl. Today I'm here with Guy Siegel. He's the director of digital ecosystem and design systems at Thomson Reuters. Guy, you've held a bunch of different positions in your life that have all been about design or user experience or engineering in some way. And I think in your initial submission to be a part of the podcast, you talked about how you'd been building stuff since 1997. And so you've got a great history and a background both on the engineering front and on the design front, to kind of bring a lot of expertise and experience to this talk.
Guy Segal [00:00:57]:
I think part of it is also the ability to have some perspective where I don't necessarily flock to the latest and greatest, because I know that, you know, you wait a while and there's going to be something new to replace it, and that new thing is going to become new very fast.
Chris Strahl [00:01:16]:
Yeah, I mean, the world of web design has changed a lot. As someone that built their first website in Notepad and then I got a Mac and then I built it in hypertext editor or something like that, I also understand that change. There was HTML and there was css and then there was PHP, and then next thing you knew, JavaScript ate the landscape. And now here we are in a very different world. And along that journey, Thompson Reuters has gone through a lot of changes as well. And so, I mean, I think that I saw Thomson Reuters on the web at a very early age before I knew what that actually, like, really meant. Right? And so as a giant media company, you know, the web presence has always been a big part of the channels that you use to reach consumers. But I'm sure that it's not homogeneous.I'm sure there's a lot of differences between the way that things get built. How when you think about being the person that is being asked to deliver a design system for hundred plus brands, what does that look like? What kind of considerations does that have?
Guy Segal [00:02:25]:
I think whatever the most important thing when you come into this role, and I started in this role a little over two and a half years ago to come in and build a team and actually build the one design system to rule them all from scratch. One of the most important things is having a point of view, being able to declare, this is what we're doing. There are about 150 different products within the Thomson Reuters umbrella, and a lot of them were come from companies that were acquired throughout the years. One of the flagpoles of a design system is that, you know, visual consistency that is definitely needed here because you have so many products that, you know, some of them were created 20 years ago and look like they were created 50 years ago, and you need that point of view. You need to say, okay, we're starting from this point. You need to be very adamant about what you're going to not compromise on, but also very open about things that you are okay compromising on.
Chris Strahl [00:03:25]:
So give us some examples of that. When you think about, like, what's an okay compromise versus what's a barrier, where do you throw up a wall?
Guy Segal [00:03:33]:
So with so many different products and different design teams and approaches and things that already exist, you can only take so much into consideration when you're building something that has to serve a large audience. And one of the mechanisms we put in place, for example, is what we call design ambassadors, where we have representatives from each design team within the design organization who are kind of like part of this ambassador council, and they serve as kind of like a two way conduit into their design system. They communicate to us the needs and the requirements that their products have, and they sort of bring back the word of the design system back to their product design pods.
Chris Strahl [00:04:19]:
Very missionary. It evokes a lot of feeling of, like, some weird patterns of colonialism there, right? Like, hey, let's go, like, find a place that needs design systems and let's go spread that to them.
Guy Segal [00:04:29]:
In a way, yes, because you are trying to affect some change in how people think about that product design. This is kind of my secret. In a way. I see the design system as largely a Trojan horse within the organization. This is a way for us to bring some of different ways of thinking about building products. But when you start that kind of work, you can say outright, okay, we're going to change everything we're doing. You have to start in a way that is more digestible and it's something that's easy for people to do. Like, okay, let's use this tool instead of this tool, and slowly you get people to start thinking a bit differently.
Chris Strahl [00:05:09]:
Yeah, it's interesting. That's not the first time I've heard the Trojan horse metaphor, and we've had a lot of, like, there's a lot of, you know, sort of evil metaphors there in this episode so far. But regardless, the idea of, hey, culture change can happen as a design system gets implemented, and the design system can actually be the catalyst for a lot of that cultural change and change in the way that people think. When you think about, again, to kind of push a comparison, what are the carrots and sticks that you provide people when they're thinking about adopting that system? Because there's two sides of it, right? There's the need and the desire both for the design system team and the product team that's implementing it, to have that consistent experience, to be a part of that brand, to be attached to the parent company. But then there's also this idea of, like, hey, that's constraining or restrictive in some way. And I'm sure that there's some trade offs that you're talking about with these folks that are oftentimes difficult for product people to stomach. What do those trade off conversations usually look like?
Guy Segal [00:06:07]:
You know what? I was actually really pleasantly surprised when we started the work, and I was fully expecting a lot of the conversation around the design system as a constraint, the design system as a yde, you know, a straitjacket to continue the evil metaphors here.
Chris Strahl [00:06:23]:
This turned out to be a banger of a, like, hey, let's just go with the dark stuff and keep going.
Guy Segal [00:06:29]:
And I. And we got almost none of that. People really understand what a design system is. I don't think I've seen any sort of fundamental pushback about the design system. It's all around. What is a trade off? What are we giving up by taking the time to adopt the design system or to use the design system? You asked about carrots and sticks when we just launched the design system, or version one, that was at the end of 2022, the carrot back then was our support, our time. Like, we would work with you, we would be with you. We would sort of hold your hand in a way and help you start using it.After we saw really great uptake into teams adopting and starting to use the design system. From my perspective, the carat is the design system itself. We got enough anecdotal evidence that it's helping people move faster. It's solving some of the existing accessibility issues that they had with the previous stuff they used. So the design system itself is at least on my team, we see the design system as the carrot and we kind of, in a way structured our OKR for this year, for example, around that notion of if the design system is of quality and it has what people need, they're going to use it. Why not?
Chris Strahl [00:07:49]:
I want to come back to the why not here in just a second. But when you talk about like the quality of the design system you've created, I think that you all have a fairly modern approach to design systems. And I know you're not like a trends guy, but this wide use of web components and a deep integration with a lot of what's happening in figma is actually like, I would say, fairly cutting edge. So talk to me a little bit about the design and technology choices that represent that quality.
Guy Segal [00:08:18]:
To you, it may seem like cutting edge using web components, but it is caused directly by the fact we have so many products and so many tech stacks, from people who are using angularjs to the latest version of angular. We have all the different versions of react, we have Vue js, we have am, we have a lot of different technologies. And our design system engineering manager decided to go with web components because of that, because of it being technology agnostic.
Chris Strahl [00:08:49]:
Yeah, I mean, it's certainly a powerful way to support a huge array of diversity. And I think that drives home the point of what you were looking at for the design system was kind of that like one ring, right? How do you have all of the dwarves and elves and men all get together and all decide on what that one thing is going to be? And the answer is like, they're not, they're going to all want a lot of different stuff. And that technology choice is giving you the flexibility to have a core system that can be implemented across a variety of different landscapes.
Guy Segal [00:09:23]:
Exactly. And one more thing that we sort of learned in the past year when we just launched, we were accepting everyone, like we wanted to help everyone get on the design system. We were not selective at all. We learned a lot from how products and teams were adopting the design system. We give ourselves the space to be a bit more selective. So if someone has come to us and say, you know what, we have to support ie eleven, we are very comfortable in saying it's nice to want things, but even Microsoft isn't supporting ie eleven anymore.
Chris Strahl [00:09:59]:
Yeah, that's funny. And I mean, maybe there's where your sticks are, right? Is the idea of like, hey, if you want the design system, there are requirements you have to fit within. I think that there is this idea of building for quality but really constraining what that building compasses, that's a valuable lesson there where you all have a system that works for lots and lots and lots of different products. And within those different products, you have to be very strict about what you do and what you don't do. And I think that's really interesting. This idea that, hey, we're not going to support this browser, we're not going to build this one component, because we need to think about this across an ecosystem is interesting. That takes me back to the original point. We talked about the idea of providing somebody a system with quality that doesn't feel like a straightjacket.How do you get people to color within those lines and still represent that quality without it feeling restrictive? Because I think it is really interesting that you're talking about like, hey, here's a system, here's a lot of controls on that system, but the system is like such this valuable prize that people still want to jump in there.
Guy Segal [00:11:11]:
I think a big part of it is how we communicate that level of quality. Just like when I'm describing the way that the design system comes to solve some technology problems or issues within the company, it also the way we approach it internally within the design system team, it comes to do things a bit differently in how we release things and how we think about what is quality, what is something that is good to release to other people. So we actually, when we just started at work, we met with a few of the design teams and we asked them, what would be the minimum level of quality for you to start using this? And we had a long list of requests of requirements, essentially. And we met as a design system team and we came up with the list of criteria that we called ready to use. And it has a certain level of accessibility requirements because accessibility is huge. And we have a dedicated accessibility specialist who reviews all those things for the design system. We had some other elements within Figma, within code that all put together this list of knowing when it's okay to release something. So it also prevented us from just spinning and knowing when it's okay to release because we knew that they were ready to accept it.
Chris Strahl [00:12:27]:
Interesting. So you actually had not a necessarily written down contract, but a relationship with your product owners such that you basically said like, hey, this is the thing I'm thinking about building. They're like, well, if it does all this stuff, will use it. And then you were basically like, all right, here's the thing that does all the stuff, now go use it.
Guy Segal [00:12:45]:
Exactly.
Chris Strahl [00:12:45]:
And is that one of the ways that like, the work has changed a lot, because that sounds like an interesting process, right, where large organizations largely have a difficult time just getting different product teams to talk to one another, let alone like actually collaborate around something. And so this, like, moment of collaboration upfront where you're basically like, hey, this is what we're building. Do we all agree? That seems to have paid a lot of dividends, both in the, the choices you're making when you're building stuff, but then also in the way it's ultimately affecting the way that folks work?
Guy Segal [00:13:16]:
So I'll actually take you back to the beginning when I just joined the company and I was working with a team that they were all working on some of the smaller design systems within Thomson Reuters. Throughout the years that were in specific areas of product or certain niches, certain use cases, they did not have a lot of faith in this new design system because they've seen the previous ones fail to some degree. One of the first things I did was facilitate a pre mortem workshop where I asked a year from now, this new one design system has completely failed. Why did it fail? And just gathered all that baggage that they had to understand, what are the possible things that will trip this up? And then the smart thing is just do the opposite.
Chris Strahl [00:14:06]:
So what are all the ways that we see this failing? Let's not do those things. I love that. And so, you know, who's involved in that sort of conversation, that facilitation, is that you and a bunch of product owners, is that the design system team, like, what does that communication flow look like and who organizes that invite?
Guy Segal [00:14:24]:
So that was just within the design system team. That was myself. I was facilitating it with the people who previously worked on different design systems within the company. And it was a great, very cathartic workshop of just getting everything out there, everything that all these sort of fears and concerns that they have about this new work. And looking back in hindsight, it was all about transparency and communication and involving the rest of the organization in some of the way forward, but it was things that were just not automatically considered.
Chris Strahl [00:14:59]:
So when you think about that idea and that buy in and all of the work that went into this initial push for the design system, like, what did that flow look like for you all? So you have this pre mortem, you sit down, do you go build the system, you do this requirements gathering, and then you built something. What did that first thing look like? And then how did you put it in the hands of the product owners that were helping like co create those requirements with you.
Guy Segal [00:15:27]:
So we started with a Figma library. We had a big push of, okay, we need to release something, we need to give something. People are waiting. And the team very quickly had to become comfortable with, okay, we need to put something out there. It may not be perfect, it's version one, and we are okay with it because again, we had that notion of ready to use that helped us feel comfortable with releasing that version. One of the Figma library that seems.
Chris Strahl [00:15:54]:
Really important when you think about that. Ready to use, is that a spec? Like, what is that that looks like that really determines that? Ready to use. Is it just a requirements list? You talked a little bit about that term earlier, but exactly what does something that is ready to use entail?
Guy Segal [00:16:07]:
In this case, it was a checklist, okay, in this case, it was a checklist or sort of list of approvals from different functions. So I'm very lucky to have a team that has UX and UI designers, have UX engineers, have content designers, accessibility specialists, software developers, UX researcher. So we have all these people. And it is also such a different way or a much more collaborative team than we see in the rest of our organization, where product engineering and product design do not sit within the same structure. So just being able to have all these different functions together and look at something as a team was a huge leap forward for us.
Chris Strahl [00:16:51]:
So you had this cross disciplinary, cross functional idea that then ultimately generated what amounted to a set of gates, a set of checkboxes that said, like, this is ready to go once it achieves these checkboxes.
Guy Segal [00:17:03]:
Exactly.
Chris Strahl [00:17:04]:
Okay. So then when you have this initial push that you're doing and you're releasing this stuff for the first time, you talked about this initial build, then what happened?
Guy Segal [00:17:14]:
So some people started using it, which is awesome. A lot of the times we've seen that the design team sometimes wait for, in quotes, I would say, permission to start using the new design system. Because again, if they are designing something using a design system, they're creating some sort of a expectation that the product engineer who's on the other side and building it will know what to do with it. And since we did not have that aspect yet, that coded aspect of the design system came a bit later. It took a while until that really became the norm within the design organization.
Chris Strahl [00:17:55]:
Yeah. So the initial value is something like, all right, hey, design team, we have this system that's built in Figma, and it gives us at least consistency of the things that we're designing. But the engineering consistency came later, and that was largely based on people building web components to fit the things that existed in Figma. Yes, exactly when did that come about, and how does that part of the conversation happen? Because so often inside of big organizations, people are like, I built a really great library of components in figma. I have a design system, and I know that you're aware that it's much more than that, but oftentimes that second part of the conversation about how do I go just beyond docs and Figma components into the world of actually, like, connecting with code. That seems to be a struggle for a lot of teams. So talk to me about how you accomplished that.
Guy Segal [00:18:44]:
To be honest, working with this team has really ruined a lot of other design system work for me because I am so privileged and spoiled, to be honest. Our head of design, who sort of set this plan in motion of having a design system and having a design system team dedicated to it, he really put all those functions into one team. So I joined and I basically had a blueprint of who I should hire. And one of the things was this commitment from the product engineering organization to have a dedicated team of engineers to the design system. I cannot imagine we would be where we are without that dedication and commitment from the software engineering team.
Chris Strahl [00:19:30]:
Awesome. So you had some executive planning that happened, and that executive vision translated into resourcing commitments not just within the world of design, but cross functionally. And those people worked on one team together. It wasn't just like, hey, here's some stuff that happens in Figma now we're going to throw it over and have a bunch of people in engineering build that. They were all one design systems team building that infrastructure together for all of the different products.
Guy Segal [00:19:54]:
Yeah. And even though we are again spanning two different parts of the organization, we work as one team. We plan our sprints as one team. We are one team. Defacto.
Chris Strahl [00:20:07]:
Yeah. So are there any lessons learned there? Because you mentioned talking about how this has spoiled you or ruined you from ever working on another design systems team. Like, what's the big difference that you felt? Is it that commitment or is it something about the way that you work together? What is it that really feels that sense of difference here?
Guy Segal [00:20:27]:
I think all that, but I would focus on a lot of the technical feasibility and the technical quality of the work. I think there's so much that when a designer looks at designing a component in Figma, just having the input of a software developer or even a UX engineer coming in and thinking about it from the perspective of how it's going to be built and how it's going to be used elevates the quality of that design so much that without having that context, it's really hard to imagine what is that added value that gets there and having that one shared. I would say this trifecta of designer, UX engineer, software engineer together helped communicate a level of quality that the design system has.
Chris Strahl [00:21:15]:
Yeah, it's interesting, right? We talk a lot about in just, you know, organizational behavior, we talk a lot about how diversity of opinion tends to lead to stronger result. And in this case, I definitely see that, like, in the work that you're describing, having a system that is, first of all, robust enough to stand the test of time and also serve a lot of different products just in figma is a pretty impressive feat. But then to be able to tie that to a web component implementation that ultimately ends up serving, I don't know, dozens of different technology stacks, that's really interesting. And to keep that all under one roof, oftentimes that level of complexity is really hard to manage without a highly collaborative team that really focuses deeply on that quality. And in my own experience, I've noticed that the more complex a technical implementation of a design system is, very often the more times it needs to be chopped up or fragmented in order for people to make sense of it. But it seems like you've been able to thread this needle of saying, hey, I have this really, really interesting technology implementation that serves a whole bunch of different product use cases, and it's tied very intimately to the fundamental intent of designers in the organization. So, I mean, how has this changed people's work? I'm so curious to know that first product that was predominantly built with a design system or the perspective of that person that for the first time ever, didn't need to relitigate a checklist component. Is that a sigh of relief for those folks?
Guy Segal [00:22:43]:
It was really funny, actually, because the first team that used the design system in their code, they did not know they were the first ones to do it. Everyone wants to be adopter number two. No one wants to be adopter number one.
Chris Strahl [00:22:57]:
Yeah, you only, you only talk about being a guinea pig when you know you're being a guinea pig.
Guy Segal [00:23:03]:
And they had no idea, no one else was using it, so they jumped in with, you know, both feet. And it wasn't a huge thing. It was kind of like, you know, five screens, a new flow they added to their product. But from ideation into it being live in production, it took six weeks, which is unheard of in a large enterprise.
Chris Strahl [00:23:24]:
That's incredible. Right. Like, when we talk about, like, the savings that design systems create, even bad design systems take processes that usually take many, many months and shorten them into a conversation about weeks or years, and all of a sudden that conversation shifts to months. And so hearing these sorts of stories is incredible, because when you talk about, like, hey, I want to go and redesign a major feature, and that major feature redesign, from ideation to implementation, is six weeks. That's insanely fast.
Guy Segal [00:23:55]:
It is. And it really helped us to. Of course, we jumped on it and we published a case study of this, and we really praised that team as much as we could because those kind of things are the best ways to sell a design system to a potential user.
Chris Strahl [00:24:11]:
Yeah. I mean, you probably made that product owner look like a hero, too.
Guy Segal [00:24:14]:
Absolutely. And that really opened the door to us feeling confident that we're not selling snake oil.
Chris Strahl [00:24:23]:
You have something real here, and it has a lot of value.
Guy Segal [00:24:25]:
Exactly. And it's provable value.
Chris Strahl [00:24:27]:
Yeah. How do you think about proving that value when you go talk to those executives that initially funded the process or funded the initiative because it's present. Right. It's clear, like, when you're able to say, like, hey, look. Look at these timelines, look at how these things have changed. Look at this quality bar, number of defects, look at how those things have changed. But, like, what does that conversation usually lead to? Is it about like, hey, we're going to continue to invest in this tool and this infrastructure in this platform? Or is it about like, hey, like, here's the benchmarks for how this team is really changing our service model.
Guy Segal [00:25:01]:
We're not there yet, so it's not that kind of benchmark. I think we're still in the days of, this thing used to take x days. Now it takes, you know, x minus something days, and it helps you move faster and helps you go to market faster, which is, in a lot of cases, this is still how the product organization thinks about things. How fast can I get this to the hand of my customers? So we're still in the days of that kind of calculator that, I don't want to say efficiency, but acceleration.
Chris Strahl [00:25:32]:
Right. And, I mean, we have that on our website where there's some back of the napkin ROI metrics for this that are largely about time saved. And I think it's interesting to apply that because the consensus that people seem to revolve around is in the neighborhood of 30% to 40%. And so, you know, you're not able to quite move it twice the speed, but pretty darn close a lot of the time.
Guy Segal [00:25:53]:
And even if we're not there yet, because the scale of the organization, even if we move ten to 20% faster, that's already massive. That's unbelievable.
Chris Strahl [00:26:03]:
Well, I mean, you have product owners that will kill for 3%, right. I think that there's a lot to that idea of if you're able to prove consistency of double digit savings in time and effort for things, that's a massive boon to the organization at scale. And I think that's why big enterprise companies are so keen on this stuff. Is that design system team? Yes, that's an operating cost for the business, but ultimately the scale of that cost is distributed amongst a whole lot of people, a whole lot of consumers, and it makes them all a lot faster. The incremental savings is massive on a per employee basis. I think there's an interesting CFO math to do there around like, hey look, my Opex is X. It's plus some number of thousands of dollars with a design system, but my savings is Y. And the delta in that math is like five to ten x.But that's where we need to get to, I think, as a profession, as a discipline to really start to be able to make these cases at scale. But it's awesome to see folks like you seen that play out and seeing that play out very positively across an entire organization of products.
Guy Segal [00:27:12]:
Absolutely. In a lot of cases, I mean, not that it's unexpected, but you see the sort of the anecdotes of people saying how quickly they were able to do things. A lot of times they're taken into account or they're considered more seriously than the back of the napkin numbers, which may seem fudged or, you know, a bit of a exaggeration.
Chris Strahl [00:27:35]:
Yeah, I mean, nobody believes you when you tell them you're going to save 30%. But I think the anecdotes, they're case studies, right? It's case studies of where things have worked in the past. And building on those case studies is really powerful.
Guy Segal [00:27:47]:
One of the things we're trying to do is identify what are those big initiatives within the company and try to see how we can support those, because that is, again, a way for products to adopt the design system without outright thinking. I'm adopting the design system. So accessibility, huge topic for us. We have shown that, for example, in some cases there were products that had a certain list of bugs in the backlog that are tied to accessibility. And we went to them and asked if you were to adopt this new design system that we're building how many of those would become obsolete, would be removed? And some said, you know what? We think up to 50% of the issues we currently have would be gone if we were using the design system. That's a huge selling point.
Chris Strahl [00:28:36]:
So one of the things I like the most about this conversation is we've kind of tied these fundamentals together around, like, what a design system is, which I think most of the listeners to this podcast understand, to how it gets implemented and then how it shows value. And that sort of three stage process is something that is fundamental to the design systems journey. But oftentimes it can get lost in the, oh, I have to go build 45 components. And I think that it speaks kind of to the quality of leadership and your personal drive in this. And it feels like you've been able to keep that vision of like, hey, somebody's making a bet here on a design system. How do I build the right thing, show the right kind of value, and continue to prove that this is solving this big organizational need. And that focus on that, I think is a big driving factor of the success here. And that's awesome to see.
Guy Segal [00:29:28]:
Yeah, one of the big things we learned working on the design system, or at least I learned, is that that decision of what to prioritize, what to put on the roadmap, has to come from a shared understanding, because the design system team is always going to be smaller from the rest of the organization. So that means we have fewer resources, we have less time to produce something that people need. Let's make sure we're producing the thing that is right.
Chris Strahl [00:29:53]:
Well, hey guy, I really appreciate you being on. Thank you so much for taking the time. Appreciate your perspective on this. It's been an awesome conversation and great to get back to basics for a minute.
Guy Segal [00:30:03]:
Thanks, Chris. It's been a pleasure.
Chris Strahl [00:30:05]:
This has been the Design Systems Podcast. I'm your host, Chris Strahl. Have a great day, everyone. That's all for today.
This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about find us on Twitter. We'd love to hear from you with show ideas, recommendations, questions or comments. As always, this pod is brought to you by knapsack. You can check us out at Knapsack.cloud. Have a great day.