Alex Wilson on Successful Design Systems

Alex Smith: Hey, Alex, thanks so much for coming on the show today. And thanks for having me. And to start out, can you give the audience a little background into your journey and Science Systems?

Alex Wilson: Yeah, sure. So I actually got into it. Before it was really called the design system, I was building UI kits for different companies that I had worked for. And actually, I'm at tiro price now. And we started with building UI kits and found that eventually, that we needed to pair that up with design, and then build a formalized design system. We didn't want to have a UI kit or a style guide, we wanted a centralized location for it all. And so that's how I got into a formal design system work and never looked back. So excited to be on, excited to talk about it with you. And with your audience.

Alex Smith: Going back a little bit more, you have more of an engineering background or design background?

Alex Wilson: So definitely more in the engineering background. And in fact, I started my career as a back end engineer, I eventually got into the front end space, really got intrigued by this system thinking of how can we like keep sharing what we're building, because I hated building the same thing over and over again, then you switch between the different products. And then I was really hooked on that front end for no work. It was a constant feedback and immediate feedback, which is something I really enjoy.

Alex Smith: One of the things that I like about your background is that any design is gonna have to collaborate with engineering, before we dive into design systems. Just quickly, how do you advise that for someone who maybe has that perspective in your back pocket? Like how should designers think about working with their engineering peers?

Alex Wilson: I think it's important to stress the reason why choices are made. Because from a developer's point of view, a lot of the time, you don't understand why the design choices are made. And sometimes it can be questionable. It's like, I've got to make this animation, it's going to take me such like a certain period of time. And that could be lengthy. Why am I doing this? And then you could come with like that reasoning, you say, This is why we've made this decision backed by research. And then that developer gains empathy for the position of the designer. And over time, you end up collaborating a lot more together. And it becomes more of a conversation rather than a storytelling from designer to dev, the dev might eventually start asking questions, why aren't we tackling it this way that was proposed for this other design? Where's the consistency there? And so then you can actually have a real back and forth, which I think is nice.

‍Alex Smith: So I think when I hear about a big company, you know, implementing a design system? When does that become the reality? Like I know, there's big companies that still don't have them. And I know the small companies that probably have a very sophisticated one. So it feels like when do you actually take that step?

Alex Wilson: Well, it's a great question, because I think there's this idea that, especially for people that are new to design systems, or companies that are new to design systems, that it's, you know, a project, and then eventually it'll be completed. But really, it's a, it's a full blown program that requires a lot of governance and maintenance, and thoughts and people, people problems, and development problems and design problems. There's just so much going on in the design systems space, even within a single company, I think the tricky part is really showing the value, which when you look at a design system, you think about the sharing portion of it, there's a lot of value there. And there's a lot of value and consistency. But until people are actually seeing it and understand what the meaning behind the design system, sometimes it's hard to pitch that. To answer your question about how do you scale at a large company, I think you've got to work through those, those really early growing pains. But once you're there, it really starts moving. I think that we're in a good spot now at the firm, and we've got like a ton of buy in and of course OKRs and business initiatives aligned.

Alex Smith: One of the stats, I always see when reading by enterprise design systems is still that's somewhere between 40 and 50% aren't successful in the long run. And I don't know if that comes down to you know, not explaining the value into higher ups or that's not getting translated to users, the usability issues aren't being addressed or really why these design systems are failing. I'm wondering if you have any insights into that and how teams can avoid being in on the team where the design system doesn't necessarily like pan out I guess?

Alex Wilson: Yeah, I think a lot of it comes down to thinking about the user and We're not, I'm not necessarily talking about the end user here. Extremely important, of course, as the end user, however, yeah, we have to think about our developers, our authors, our designers, our AV testers, and make sure that the experience that they have with what we're building is extremely strong, because I think that the fail the points of failure, and of occurring when you have a product, maybe you've built it, but it's not been built in a way that is maybe you don't have consistent API's in on the tech stack, maybe the designs are falling apart, maybe the designs are all over the place, and you're in a large figma file. And it's really hard to understand and read through. And so people would rather deviate because it's not easy enough, it has to be easier than their current process, or pretty darn close to it. So that way, they not only see the benefit, but they're also not taking longer with what they're doing. And so I think that's really key, and then showcasing the work as well, once you start getting people engaged with your product, yeah, then there's a higher likelihood that they'll use it and want to contribute back as well. And that's another whole piece to a design system. That doesn't mean that it's not a measure for success, but it's certainly a part of the scaling process. 

Alex Smith: Let's move on to like, where do you think design systems are headed because I know everything like constantly evolving, right, like in the tools that you get, the tools that you're using to create them, or the value that they drive? Where do you think design systems are going in the next 5 to 10 years?

Alex Wilson: I think they're going to become more and more popular at different companies. But I think the tooling has to get there. So that way, it makes it easier for the companies to, to build and then have their teams adopt, I think we're also going to see, you know, influence from Ai, from all the different tools that we're seeing out there on the design side. And on the tech side, design side, you know, maybe figma will come out with more different plugins that will encourage AI or generative AI usage where it iterates on a design that way, especially if you're a part of a smaller team, it expedites that divergent thinking because you start with a single design, and maybe don't have those people to bounce the idea off of. And if you are able to come up with 10 variants of that design that could speed up your process a lot more than just kind of handling it by yourself. And then of course, on the tech side. There's a lot of no code tools out there that that teams are looking to build with. But there are also challenges with that, too. So there's a lot of companies, I think they're trying to create products for design systems. And we're seeing how well they work over time. The generation of code for designs seems like a great idea. And I think that in certain use cases, that the API and the code that's generated has to be really solid.

Alex Smith: Not only are there a lot of new designers entering the field today, but these designers are probably being asked to work on design systems are with design systems focus teams for the first time. So what advice would you have for those folks who are thinking about new designers, or new to design?

Alex Wilson: System engineers, really anybody that's working with a design system, it's really important to focus on the system as a whole and how that breaks down. It's no longer about how does this component or design work within my context, but it's how does this work within all contexts. And that applies to someone that's, that's working on an application or working on the design system, because then you, you almost have to think about the design system as not just fulfilling the need of one, but the need of everybody. So if you want a thing to be built, it's not going to just happen right away, it's not going to be designed right away, there's going to be a lot of thinking and time that goes into the structuring those specs.

Alex Smith: Alex, I think there's a lot of designers out there who have been trained about designing for the user, see that single design out there. It's in the wild, iterating on it. And I think that mindset is very different once those designers will be going on to a design system team. So how do you advise those new designers to think about working in a system design system versus, you know, individual components or individual user journeys? 

Alex Wilson: Yeah, I think it's a great question, because it is actually quite different. You've got to think of all the different use cases of how that component could, you know, could be used in the wild in product ABCD. And future E, which we don't know. We don't know if it exists yet. Understand also, how your company currently has those components used in the wild. Bring them all together and see what's missing. There might be gaps, and it could take you a while to figure this out. It's worth spending the time I think upfront to figure that out, which does fall low, a little bit more of a waterflow s prime process. But we've seen it work really well at the firm. And we've also seen that flow really well into dev because from our technical side, we can start coming up with architectures based on these use cases. And we know that when we implement it in code, that we've considered a broad range of how developers, designers and the users expect to interact with the component that's being built. Because we don't want to block innovation while also creating these new systems. We want to make sure that designers feel empowered to use the foundational parts of the design system to create new experiences, because we don't have everything and we probably never will have everything that everyone needs, but we can come up with guidelines of how things should be used, and then bring more into the system over time as we see those needs arise.

Alex Smith: Alex, thanks so much for coming on the series today.

Alex Wilson: Thank you so much for having me. It's been a lot of fun.