On Theme: Design Systems in Depth

On Theme S1 Minisode 2: 2025 Predictions

• Elyse Holladay • Season 1

Share episode

📲 Text the show your thoughts!

Elyse shares five predictions for design systems in 2025 and beyond in the second pre-season minisode. Text the show to share your thoughts and predictions and maybe even be featured in a future minisode!

Early Bird tickets are available until January 15th for Into Design System's excellent annual virtual conference, featuring Nathan Curtis, Romina Kavcic, Cintia Romero, and more. Get your tickets now before prices go up at intodesignsystems.com/ontheme

Elyse:

Welcome to On Theme: Design Systems in Depth, and welcome to 2025. I'm Elyse, and this is minisode number two, and we are just two short weeks away from the first official episode. I'm recording this on January 1st and I couldn't let the new year go by without a few predictions. So today I want to talk about five predictions for design systems for the new year and beyond But we can't look forward without knowing where we've been. So stay tuned because in our first few episodes of the podcast, I'm thrilled to chat with OG design system practitioners, Brad Frost and Jina Anne, who are going to take us back in time to how design systems as we know them today came into being. I'm also so excited to announce that I've teamed up with Into Design Systems for season one of the podcast. Into Design Systems is back with their annual virtual conference, May 28th through 30, 2025, and early bird tickets are 35 percent off until January 15th— just two weeks away. Visit into design systems. com slash on theme to get your tickets to three days of practical hands-on sessions, showing the what, why, and how of design systems. You'll hear from folks like Nathan Curtis, Romina Kavčič, Cintia Romero, and more, plus you'll get takeaway files and resources, there's introvert friendly discussion in Miro, which is super fun, and live Q& A with the speakers, of course. This year, the conference is really focused on developer handoff, accessibility, multi brand theming, and design system governance. So get your early bird ticket now for just$379, including all the recordings and files to take home before ticket prices go up on January 15th. Big thank you to Sil for supporting the podcast and listeners, I hope to see you there at the conference in May. All right, let's dive into these 2025 design system predictions. One, AI is changing how quickly we generate artifacts, but not what gets generated. Two, generating code from designs is not the way. Three, you already have a design system, and this one's a twofer, more non-tech companies will be getting into building design systems. Four, focusing on specific patterns over foundations. And five, your best success metrics are stories, not numbers. First, I believe that AI is changing how quickly we generate artifacts, but not really what we generate. Yes, AI is a big change, but I don't think it's actually disrupting us as much as we might want to read about in the hot takes. It is faster to write code. It is faster to write content, to find and use variables or properties, or generate something like a design system component. It's getting faster to create mock ups, generate brand assets, write docs or dig in the docs and, find the answers. But these are all like grunt work production tasks. I saw a post recently that was like AI will enhance creativity, and, uh, I don't know. Maybe you can think about it like the 80 20 rule, if we are not spending so much time on busy work, which I can only think of as a good thing, maybe we have more time for creativity and craft, but I think that remains to be seen. We are definitely generating output, but maybe not yet craft with the AI tools themselves. Cameron Moll shared an excellent graph in his latest talk where he was describing the cycle of tech advancement. As we get faster ways to generate more output, we generate more output, and that gives us less meaningful engagement. And that brings us to a return to more personal craftsmanship, a more personal approach, which means we produce less content. Output and we have more meaningful engagement, but then we need to make more stuff, so we find faster ways to generate more output. So I think that AI is definitely going to change the way we work with our design systems, how we find information within them, how we generate components or generate mocks, but I don't think that the AI tools are yet at a place where it is making the new meaningful stuff for us yet. I'm sure it's coming.. Maybe not this year. But I am excited about something that Jina Anne has been talking about, which is using AI or LLMs, especially in our codebases, to help us generate different UIs for various users. At a really simple level, think about button placement for a left handed phone user versus a right handed phone user. There's many, many more interesting and complicated ways to think about that, but those are some of the ways that AI could actually create different UIs for us. But my prediction for 2025 is we're not quite there yet. Number two. This one might be spicy, but I feel really strongly about this. Generating code from design is not the way. We have been so focused on generating code from mockups. And yes, it's really cool to go put a picture into Claude or ChatGPT and have it spit out a bunch of code based on a picture. That's amazing, but from a design system perspective and from a building software products with a large team, I don't think this is the way. Figma CodeConnect is basically a domain specific language for Figma. It's neat, but I think it's a mistake that we are going to need a third layer to translate between design and code. I did one component with CodeConnect and I was like, this is an absolute waste of my time. We already have the code. Figma is not the browser. Figma will never be the browser. We will always need to do some kind of translation between the picture that we make and the code, but we already have the code. I will always come down on the side of the browser and the existing code that's going to be more true to what we want to build than trying to generate it from an image, no matter how much information we can encode in that image like Figma's API. I think Framer, Webflow, WeWeb, these companies are doing some very very cool work reimagining what designing for the web and UI can be. They're actually really robust and we're taking components and actually designing with them. And I think that is where the real future of this bridging the gap between design and code is going to come in, is going to come from the code first. So I'm really excited about tools like Dessn AI. They're really taking this idea and running with it. They are reading the design system out of the code base and providing a UI that enables designers to edit real product and produce a PR. And I think that is the way to go. I think we are going to start designing with the code components rather than trying to generate code out of the designs. All right. I said before, this one's a twofer: you already have a design system. So stop trying to build a new one, slash, more non tech companies are going to get into building design systems. I keep saying design systems are just how we build UI now. And in many cases, even if you don't have a design system team or call your frontend setup a design system, you already have some kind of foundations of a system in your code base. You already have colors. You already have typography. If you're using something like React, you already reusable components. It might be ugly. It might not fit your brand vision. It might be disjointed, but what if you considered that your starting place rather than building an entirely new thing from scratch? Rather than being like, we're going to do this token architecture and we're going to make a new button and a new input. What if you consider what was already there the seeds of your design system? So yes, you're going to do refactoring. You are going to consolidate. You're going to clean things up, but I think we need to let go of the design system failed and we need to make a new one, and we're going to start a design system from scratch. You already have one in your product. You already have a system for building design and just because you can't put it on a shiny doc site and call it an official design system with a name doesn't mean that you don't have it. And I really want us to start from there rather than focus on building a design system, air quotes. So on a related note, I think we're going to see more companies using design systems or building design systems, specifically companies that are not classically tech software companies. I mentioned in minisode one, the Gartner hype cycle for product design and they still put design systems at the peak of inflated expectations. And the peak of inflated expectations is early publicity produces success stories, but also lots of failures, and some companies take action, but most don't. So that means design systems is still at a point in the adoption cycle, where most companies have not made a move here, even though within our little bubble it may seem that way, but there are lots and lots of companies, software companies, yes, but also lots of non classically tech companies that have not actually made a move here yet. So after the peak of inflated expectations, there's the trough of disillusionment. And this is interest is waning as experiments and implementations fail to deliver and investment continues only if the product actually improves. As we move through this trough of disillusionment and into improving the way that we deliver on design systems, we are going to be seeing more and more companies building design systems, and I think we're going to be seeing that off their existing code and off of pre existing component libraries, rather than completely reinventing the wheel. I think we're going to see this especially in, again, non classically tech companies. Think Domino's or Chick fil A, right? Like food companies that are also, like they have an app or they're building some software. Or, non consumer software, non B2B software. Other spaces retail, e com, things like that. Where they're starting to see the value and see improvement by using something like a design system, but they're not buying into the peak design systems this is what building a design system looks like. I think these spaces, refactoring legacy products and using what's already there as the roots of the system, and expanding into these non tech spaces are where hiring is going to be in 2025 and beyond. I think we are hiring more, but look for more fractional or contract roles, and look for them at a kind of strategic level, like not just hiring an engineer to create a bunch of components, and look for roles both full time and contract that blend building with strategy. We are building the system and we are managing it. We are not just building components and we are not just doing strategy. I think there's going to be a lot of hybrid roles like that. And I think we're done with big teams. But we also know that we cannot completely ignore this part of our org. So this is where I expect hiring to be in the future. All right. Number four, focusing on specific patterns over foundations. You will hear a number of guests upcoming on the show. Talk about this, but we are way over-indexed on extraordinarily complex token architecture over indexed on foundational elements. We spend and have traditionally been spending so much time on these things. And it's not because they're not important. I don't think that's going to go away, but existing code component libraries that are robustly tested and well staffed and well maintained, they have already invented these wheels. There are lots of variations, yes, but, we don't get as much value out of reinventing the button or the input or the switch or whatever, as we might have once done. So unless you are a massive, global, multi platform, multi brand organization, you likely do not need to be building this stuff yourself. So the real value, I think, is in focusing on patterns that are relevant to your products and to your business. And this is where design systems really got started. We were building reusable things that lots of our teams could reuse across the product. And there was a backlash, like, oh, I can't use the system because it's too focused on one specific product area, and so we've gotten to the point where all we're doing is building foundations, but there's not as much value in these foundational components as there are things that are very specific to your needs. So, I think we're going to see more focus on relevant patterns and components. So that could be a specific large component, right? Some kind of sidebar, or, panels, maybe even a header, some kind of like navigation thing, complex cards, or it could just be patterns the way you position and align buttons across parts of the product. Design system teams cannot and should not be innovating the product itself, or gatekeeping and controlling designs and how they ship, but I do see design systems as owning the patterns and the reasoning behind those patterns, documenting those patterns, sharing out how those patterns are used, and getting product teams to adopt them to move the product forward. And yes, this is complicated. This is hard. This is much harder than just putting out some colors and some buttons. But I think this is what we really mean when we say visual consistency, especially at the leadership level. We get a lot of visual consistency straight out of the box from colors, type sizes, spacing, like the foundational stuff. But when your executives are looking at their product, when they go use it and test it out, they're looking for visual consistency in, where are buttons as I go through a flow? How come the header jumps around? How come there's more spacing over here and, on the left and right over here, how come these page layouts are all different? They're looking at that level. And I think it is time for the design system to be focusing on delivering pattern consistency across the organization. As kind of a corollary to this, I think we need to realize that we are all building the product. We need to all be more cross-functional. Being able to think like an engineer is a superpower for designers, and being able to see details in the UI is a superpower for engineers. Our tools are getting really abstract, they are abstracting away a lot of complexity and everyone can be a builder now. We talk a lot about bridging the gap, but this is not like a mythical thing that only an AI tool can fix! You're bridging the gap every time you sit down with your designer engineering counterpart and review a flexbox layout. Learn the box model. Learn about arrays. Learn about variables. Learn why it matters when spacing is too close or too far away. This is multidisciplinary design system thinking work and I think everybody can take more ownership of that, and should, going forward as we start to focus on patterns Last number five, your best success metrics are stories, not numbers. Metrics are great. We love a metric. And if you can tie your design system work back to revenue or some internal engineering or design efficiency numbers that you have, that is amazing. But, leadership doesn't care about the number of tokens or components you have, or the ones you've removed. They care about outcomes. How their organization is behaving through use of this tool. They care about real visual consistency, they care about UX consistency. These things are not so easy to put a number against. We can and should be doing more to manage the perception of design systems and their value in the organization on smaller timescales than yearly. And I think with more narrative. Numbers are great, but we're humans. We love story. We love narrative, and we can talk to our consuming teams, to our boss, to our leadership about the system and about what it is enabling, even without numbers. Just like there should be no surprises in your performance review, there should be no surprises about your design system. You should know what your consuming teams need and how they're feeling at any given time, and you should understand the perception of the system in your organization. Reporting back to leadership on the value of the system can be a challenge because systems show value over time. That doesn't mean we should sell efficiency gains once at the beginning and then not talk about it. Instead, it means we should be updating our organizations regularly on what we are doing, why, our outcomes, their sentiment, and not just with dollar signs, but really understanding the story that's being told in the product teams, in leadership rooms, about the system, and work that narrative. I think we're going to see a lot more success maintaining the design system over time when we are connected to business goals, when we do have some metrics and numbers, but when we are actually talking about the perception and the outcome and the sentiment around the system, I think the future of design systems is bright. We are realizing we need to work in some new ways. The kinds of problems we're solving are changing Our tools and abstractions are changing and we're collectively exploring what that looks like. In some ways, what we are solving now in 2025 is so different than what we were solving a decade ago or two decades ago. But on the other hand, we're still trying to ship beautiful, usable software, things that people want, products and companies that are going to be successful. And we've been doing that long before design systems. We are still a group of people building a thing and that means the design systems are just another tool to help people continue to build the thing and do it well. I would love to hear your hopes, dreams, predictions for the future of design systems. Click the text me link in the show description or send me a DM on LinkedIn and let me know what you hope to see in the design system space in 2025 and beyond.