On Theme: Design Systems in Depth

On Theme S1 Minisode 4: Converge conference 2025 Recap

• Elyse Holladay • Season 1

Share episode

📲 Text the show your thoughts!

I'm back from Zeroheight's Converge conference in Bristol, UK, with my recap and thoughts. In this minisode, find out my three major themes from the event: reducing complexity, shifting towards code to design, and the narratives "framing our future". 


Resources & Links:

Elyse:

Hey. Elyse here. Welcome back to On Theme: Design Systems In Depth. I just got back from Converge, ZeroHeight's conference, it was in Bristol UK this year, and then a couple of days vacationing in London. And I wanted to share a recap of the three themes that I saw from the talks, the conversation, and the mood at Converge. It was a really wonderful event. I have been to and spoken at many design systems and tech events over the year, and this was one of the ones that made me feel like we were back in pre pandemic, golden era of conferences. Pre pandemic, small coalitions, groups of people got together and put on these amazing events, and companies were willing to sponsor so many amazing events. And now it's really challenging to put on an event. It's very expensive. People's expectations have gotten very high. And so now you see events only from massive organizations. And yes, Converge was sponsored by ZeroHeight, but it did not feel like a giant conference from a design tool that I will not name. It really felt like they were doing something for the community. And it was just, it was such a pleasure to get to put faces to names, people that I only know on the internet, getting to talk to people in the hallways, at dinner and after party, is just one of the best things about these events. So if you were there, if we got to chat, it was absolutely lovely. If you weren't there, you should definitely go next year, or to some of the other events coming up. So as I mentioned last episode, I'm dropping a handful of minisodes through the end of the year. Last time I shared a little bit about how I felt things had changed, mostly around AI tools, over the summer, and a couple ways I think that LLMs could be useful to you right now. I also had the pleasure to write about that in the ZeroHeight blog, so go check that out, I will put the link in the show notes. In my talk at Converge, I was speaking a lot about the future of design systems, how I see us being able maybe to deliver on some of the promises that we have been promising around design systems for an extremely long time. And when I was writing this talk, I, I was feeling like it was a little bit of a compilation of all of the spicy takes on this podcast so far this year, and I was actually feeling concerned about how people were going to receive it. I try not to totally succumb to the hype, but there were a lot of ideas around how AI could actually help us deliver on a lot of the promises of design systems. So you could look at that as a fairly optimistic take on what AI can do for us. And that felt really scary to deliver in a moment where, again, tons of layoffs. But as an aside, I don't actually think that the layoffs have anything to do with AI I do think that AI is showing us some productivity gains in some companies, especially very small, zero to one companies. But I think that most of the big companies that are laying people off, it actually doesn't have anything to do with AI, they're just saying that, and it has everything to do with economic factors. We were having a conversation, one of the many dinner conversations at Converge, where we were talking about how, at least in the US the R&D tax benefit for companies went away a couple years ago. And so now all of these engineers are way more expensive than they used to be. And how in the US also the economy is basically being propped up by AI. And it's a challenging economic moment. And so all of these layoffs, like people are not being replaced by AI with the same level of output, we're actually accepting a different level of output. We're accepting a different shape of company. And there's just a lot of story around it. But we're gonna get to that in theme number three, so I digress. But as I was saying, I was actually a little bit nervous about how my talk was gonna be received. But Madelin, when she gave the intro, she was talking about some of the themes that she was seeing as the head of product at ZeroHeight when she's talking to all of these customers. And I feel like she just set me up so well for this talk. It was super, super interesting to see the way that her themes resonated with mine and honestly from the talks the whole rest of the day. So if I had to summarize all of the things that I heard at Converge, in the talks, the hallway conversations, the party conversations, the mood and the vibe in general, I would categorize them in three ways. First, I would say reducing complexity. Keeping it simple, keeping it straightforward, and not doing things just for the sake of doing them. Second, code to design. I talked about this last minisode, I talked about it in my talk, and I did not expect the reaction that I got from that. And then lastly, this idea of mythology, these narratives that we are in, that we actually have more control over than we think that we do. So let's dive in. First, reducing complexity. There was so much conversation around reducing complexity, not gatekeeping, simplifying things, and the idea that there's just not one right way. If you have been listening to this podcast, you know that I have been harping on this all year, this idea that we are doing things that you are supposed to do because that's what a design system is supposed to have. I honestly think that this is a property of the massive hiring just before and during the pandemic, and a reflection of the maturity level of design systems. Over the last five plus years, we started to get a lot of content where people are talking about, this is how you do things like, set up tokens for your design system, this is how you insert whatever here. And I rail against this content because I'm coming at it from a place of nuance, but I actually think it's really interesting, because we're getting this content from a place of growing and hiring, right? So think back to, let's say 2018-19. We've got more and more people coming into systems, we've got more and more design system teams that are hiring, they're growing. And of course there's a desire, a hunger to understand the role, to understand the work. Design systems was seen as a really desirable role to be in. So here we are, we're writing about, here's what worked for us. We're emulating the big successful systems, and we're talking about, here are all the things that you are supposed to do. Now, obviously a lot of these things you are, air quote, supposed to do. There's a reason that we come to these same ideas and these same conclusions, the ways of doing governance and education and tokens and all of this stuff, because it works. However, somewhere in the last handful of years we got to this point where that is like the only way to do design systems. And if you don't have all of those things, you don't have a good enough design system, or you're not doing it right. what I find really interesting about that is how it coincided with the broken promises era of design systems, right? We, I think, feel like, I did all of those things, why didn't it work? Why doesn't this organization receive this in the way that they're supposed to? Why are they not happy about this? But the perspective that I've been taking, and the perspective that I was seeing at Converge, is we are doing so much, and why? For what? For what outcome? We are overdoing, over-engineering, over-building so much, specifically on the design side, and doing it in a way that I am not actually convinced is solving a whole lot of problems for most teams, most of the time. Luis Ouriach from Figma gave a really interesting talk about tokens where he was basically saying, why do you need all of these primitives? Why do you need all of these tokens? And a couple other people echoed. Of course, Donnie D'Amato, talking about mise en mode. And every time I hear things like that, it's just very funny to me, coming from an engineering perspective, because I'm like, yes, we've discovered variables. You know, in code, you define a variable, and then based on context or scope or if checks, you can just change the value of that variable. We build these extremely elaborate setups specifically around tokens. And I think it's mostly because of the shape of our design tools. But I think it's also a little bit, designers not understanding what's possible Which is another reason I always advocate for designers understanding the medium that they work in, which is code. This was very apparent when during Figma Schema they talked about extended collections. So let me set the scene for you. There's a handful of us in this teeny tiny, wonderful, classic British pub in Bristol. And we've all got a pint and we have a laptop set up and we are watching the keynote from Schema. And they're talking about extended collections, and then we were all like wait, what is that? What is, it's ju— it's just overrides, like, it's just the way that variables are supposed to work, and should have worked from the beginning. And one of the conversations that we were having a whole bunch was, what's going on at Figma? Obviously, without knowing, I honestly think that Figma has gotten very focused on building the solution that its design customers ask for, and possibly maybe having some scale problems. The engineering capabilities at Figma are really astounding. They are doing multiplayer, they were really one of the first to do multiplayer, and their ability on the engineering side is just really spectacular. But from a product perspective, it's very interesting that they have continued to build in a way that designers say, this is my solution, rather than trying to think about what's actually the best way this should work. And to me, extended collections is a really great example because it's how variables work in code and it's how variables and tokens in Figma, I think, should have worked from day one. And regardless of why they didn't do that from day one, whether that's scale and scope reasons or technical reasons or product reasons, what they've done is they've built this tooling that has made it so that designers are building these really complicated token structures and also just building components in really complicated ways. The release of slots I think is extremely fascinating. We're actually really excited about slots as components because again, slots, inside components is React children. That is how the web works. This is how the medium works. But now we've built up all of this practice around these incredibly complicated ways of setting things up that I think aren't actually providing us a whole lot of value. Of course, there are exceptions to every rule. I was at dinner with ToniAnn from BetMGM and Ismail and Ben Callahan, and we were having this conversation about how a good system, a good solution is solving an organizational problem. The best design system is not the one that looks like all the ones that you see online. It's the one that solves your organization's needs. And ToniAnn was telling us how they had set up some nested light and dark mode tokens at BetMGM. And she was saying, actually from this sort of like air quote, ideal way to do tokens, or the way maybe that Donnie is talking about with mise en mode, or how code works, it's not the best setup. It's actually quite complex. But it allowed for her to solve some organizational communication problems, to bring some organizational agreement and to actually change the way her organization was shipping. And that is far more important than getting the most like perfect setup. There was a great quote, I believe this was from Erin Potter and Ashley Zhu's talk, confidence is the mechanism of adoption". Understanding what you need as a product designer or engineer, why you need it, and having fluency in that when you are in your own flow state. Whether that's knowing where to look at the docs, knowing what color token to use, knowing what component to use. All of this was about reducing complexity, making it easier to choose, and that again, confidence is the mechanism of adoption. I thought that was so powerful because it is so true. We want design systems to be how our teams build UI. We have to make it possible for them to build confidence and be fluent in using it. So all the stuff that we're doing to make our design system look shiny, or do tokens the right way, or set up these complicated components with multiple layers of instance swap slots, are we actually reducing complexity for the people who use this system? And in my experience at Color, and my experience as an entrepreneur, and in my experience in these conversations, one of the things that I keep coming back to, is that it's almost always possible to do it an easier way. It is almost always possible to find a scrappier way. And I used to hate that, like, scrappy just means that you're not actually willing to invest in the right thing or the real, like good, actual way. But I've really come around on that, because there's almost always a way to get the result you want in a faster, simpler way. It's not going to look as shiny, but is what your team needs shininess? If you can do the easier way, it's easier for you, it's easier for your consumers. It's easier to understand, it's easier to maintain. And we don't need to build complexity into the system just for the sake of having a beautiful, complex, shiny looking system that you can brag about on your portfolio. If I could sum all of this up, this idea of reducing complexity, it's, there is no one right solution. We can't just look at what a design system is supposed to be like and do that and expect the results. We get the results from doing the thing that delivers an outcome into our organization. It sounds so obvious to say that, but this was such a theme at Converge that I genuinely think everybody needed to hear it, because we all apparently felt we needed to say it. The second theme was code to design. And I have felt this way for a long time, but it's really coming to a head for me with all these AI tools. There is an obsession right now around design to code. Around taking your Figma mocks and generating code from them. Figma is all about this, they had Code Connect, they're trying to do it with Make. I am seeing examples of this all over the place, people trying to build custom MCPs, convert their Figma files and get structured data and turn it into React components. but you, like we already have the code. So I had a whole section on this in my talk at Converge, and when I got to the moment, the one slide, where I was literally like, I will die on this hill, we need to be building code to design, not design to code, I actually got applause. Like the audience actually applauded, and stopped me talking for a second, which really, I felt like that was one of the most important things in my talk, but I also didn't actually know if it would land with anybody. So that was a real shock to me and a really fun moment for me. Because I really believe this now. And I believe that it is possible now. And it was really cool to see that the community also was seeing that vision. I was talking a minute ago about how, we have gotten focused on building systems around the shape of Figma and the way that Figma requires you to do things. And Figma is never gonna be code. And I just cannot understand the use case for building React code off of your Figma components. I genuinely cannot. Unless you are doing some experiments as a designer or like building a little portfolio project. In the real world, this makes absolutely no sense. If you are a true zero to one startup or a solo entrepreneur, you are using existing component libraries, and building your design on top of them. You're using Webflow, you're using shadcn, you're using Material UI, whatever. If you are an existing company, you already have code. Even if you decide to build all of those UI components yourself and not use an existing component library under the hood, you have code to go on, because you have an existing product. So you have an input that you can pull from, or you probably have 25 inputs and you can pull from all of them and combine them. There's no scenario where you need to be building your components off of your designs. So this was a huge theme. This was the number one thing people came up to me and said to me afterwards, like code to design, I can't wait to see that. I totally agree, I think this needs to happen. And this was where I found, I think, the most AI enthusiasm, this idea of seeing it as like normal technology, or technology that's gonna solve a specific problem for us, rather than this like overhyped oh, it's gonna take all of our jobs and do everything in AGI, no. I was so thrilled to demo a tool called Dessn, it's d-e-s-s-n dot ai, Dessn. Gab and Nim, the founders, were there at Converge. Disclaimer, Color is a paying customer, but Dessn has not paid me to talk glowingly about them. This is genuinely a tool that we're using and we're really excited about. And this was a really fun moment for me as well, on a personal note, because as soon as I had the very first conversation with Gab, back in the spring we both knew we were just super philosophically aligned. And I think we've become not just business partners, but friends. And they were there, her and Nim her co-founder. So I was the first talk of the day after Madelin opened for ZeroHeight. And when I got up there and I was starting to talk about these themes, I could see them, they were sitting in the front row and they were so enthusiastic and it was a really fun moment for me as a speaker. So Gab and Nim, thank you for being there. But like I said, I got to demo Dessn and how we're using Dessan and they're actually doing this code to design thing. They are working on an infinite canvas that lets you design, as a designer, with rendered code components. And I don't know anybody else who's doing this. I think all of the other like AI design system tools are still really focused on Figma, or letting you build components. Dessn is really focused on building a design tool that works with code under the hood, and I truly think this is the future. And to me, seeing the enthusiasm around the idea of code to design was really heartening. Again, I think that AI is actually powering this in a way that is allowing us, or potentially going to allow us, to solve one of the problems that we've been talking about in design systems from the very beginning. Bridging the gap between design and code. And instead of actually doing that, we have built up these spaces, this moat between design and code. Even design system teams hire designers and they hire engineers. And there are companies out there with design system teams that are only designers and don't have attached engineering, which also just blows my mind. And yes, there are creative technologists, there are design engineers, there are lots and lots of us hybrid unicorn folks out there, not brushing us under the rug. But broadly as an industry, we started with this idea of, how do we make it easier for designers and engineers to speak the same language? To design something where the built engineering output matches the design intent, and to go in the space between these tools. And instead we have managed to reinforce that space, reinforce that gap this whole time. And I think our tools, again, I was talking about Figma earlier, I think Figma is doing that. It is making that space bigger and harder because they are building products to serve the designer's idea of what the solution is. so that's why I'm so excited about AI in this particular space. I think AI is going to actually allow us to design with our real code components, something that has been an idea of floating around in the ether, a vision, a dream since the 2010s, or honestly, probably before that, but for me, certainly since the 2010s. I think the most interesting pushback that I heard around this idea of code to design. And around LLM design tools in general, is we don't actually want our product managers to be making designs. We don't actually want our engineers to bypass design, Like what is gonna happen if we let all of these other people get their hands on the design? And to me this just sounds like gatekeeping. We don't wanna give them access to things. We don't want to trust them to make good decisions or have good ideas about our product. Now, I know that there are some real practical, tactical problems with this, and certainly even at Color, we're having this conversation. But I think we're having it more from a perspective of, how do we enable a PM to do design that actually follows the design system rules and is going to look like Color's design, rather than, we don't want you to touch it, you're not allowed to touch it. The sense of gatekeeping is really strong, and isn't it what we wanted with design systems in general to let our teams make great designs that follow the system rules? Like the whole point of this whole endeavor was to bring the ability for anyone, any team, even if they didn't have enough or any design resource, to build product UI that looked like and felt like our brand. Like it's in the core mission statement of design systems, like consistency, and here we are going no, you can't have that. Even though maybe we are at a point where you could have it. But we don't want you to have it. We don't trust you. And this is also why I never get the"design systems limit creativity" thing, because this job is not a creative job in the arts sense. It's, yes, it's creative in the making stuff sense, it's absolutely creative in the ideas, in the problem solving, in the generating, the all, like all of that. But it's, if you wanna do art, go do art. You have so many other places in your life to create art and to make beautiful things. And a design job, software engineering job is a problem solving job. It's building a UI to solve a particular problem for a particular brand, and, the point of a design system is to make it possible for everyone who has good ideas around the product to make a design that follows the rules we've established for what makes a good UI for that brand. And I think we're on the threshold of actually being able to do this, and I, I think, the teams that are gonna succeed, the design systems that are gonna succeed are the design systems that are not going to gatekeep design, or police it, but actually make it possible for everybody to participate. And I think that's again, the point of what design systems always wanted to do. So last, I'm gonna end with what I think was absolutely the best talk of Converge, and that was John Voss talking about framing the future. And so this whole third category is about like the mythology and the narrative of the current moment. I think John is speaking the most truth, giving the most powerful talks and content on the moment that we're in. You absolutely need to go watch this talk. I know that John said that he was gonna release a version of it for everyone. So please, please go check this out. It was absolutely phenomenal. And John was talking about this idea that there are specific frames, specific narratives, and ways of talking about technology, about the economy, about the world, that shape the way that we think. And it, I mean, that sounds obvious to say, but when you are so steeped in those things. And it's not just like tech, the industry, it's the United States, like it's the world, it's everything. We are all just marinating in that all of the time. It can be very hard to step back and see outside of that, and understand that the world could be different. So he gave a whole bunch of specific examples, around techno optimism, around the moral value of progress, and the idea that inevitably we will see the good of technology by continuing to try to make that come to life. And that's just not necessarily true. The technology could be used for good, it can also be used for evil, and that's been true about technology, about human progress since humans have been making progress. John framed all of this up for us in such a clear and compelling and motivating way. My big takeaway is a quote from his talk where he says,"the future is not a destination we have come here to predict. It's the outcome of the conversations we are having." We did not choose the framing of the conversation we're having about technology right now. We didn't get to pick to be in a world where we are reading on LinkedIn about how companies are forcing everybody to use AI and laying people off. We didn't choose to live in this political climate. But the vision of the future that we have right now, specifically in technology, is really intentionally narrow, and has been narrowed for us by a handful of people, whose framing of the narrative, especially around AI has a lot of underlying motivations. And some of those are moral, some of those are immoral, some of those are political, some of those are economic. But it's very good for AI companies and investors to make it sound like, all of this good is coming, there's gonna be all of this, economic value that we're gonna get if we keep doing this. There's also a political motivation for all the doomerism, right? AGI, oh, we're all gonna die. These are just two stories and they're framed in a specific way, but they are not inevitable. None of this is inevitable. Nothing is inevitable. We get to participate in how the future gets made. And our communication skills, our understanding, our media literacy, our ability to empathize and collaborate and be together as humans, is how things get done, and how things get made. I'm thinking of course this week about Zohran Mamdani's win in New York, his mayoral campaign, and the way that people coming together and talking very clearly about how they want the future to be is incredibly impactful. And you don't have to always adhere to all the stories that other people are telling you. The world is not that simple. The world is a very complex system and we want it to be simple, but it is not simple. And so I think my biggest takeaway from Converge, from John's talk, from all of the talks, from the conversations afterwards, is we have work to do. How do we stay resilient? How do we go out in the chaos of the world and figure out how the future gets made? Our expectations shape our reality. If you start from doom and gloom, like you are gonna get it. If you go into your work expecting all of these negative things, expecting and assuming that things are not gonna go well, that's what's gonna happen. We really genuinely do shape our own future. So to sum up, keep it simple. Think about code to design and designing in the medium, and remember that we get to shape the future. Thanks for listening. See you again next episode, and hopefully at a design system event in the future.

Okay.