Five 2026 Predictions for Design Systems with Noelle Lansford

Noelle joins me again for some 2026 predictions trend encapsulations, and we try to unpack the absolute madness of the first two months of 2026. 

1️⃣  Designing with code is in, making pictures of UIs is out. 

2️⃣ The new critical deliverables for systems teams are design guidelines, agent rules, tokens, and semantic APIs. 

3️⃣ We're gonna see a real focus on brand expression, but also on one-offs. 

4️⃣ Design system teams, you do organizational behavior change. 

5️⃣ The next chapter of the design system narrative is around quality rather than efficiency. 

Plus: the rise of the design engineer and a return to the early 2000s ways of working? I hope so!, nothingburger brands, and design systems gatekeeping.

Season 2 of On Theme is officially here! 🎉 💖 If you like what you're hearing from On Theme, please hit subscribe on your favorite podcast platform. On Theme is  sponsor free and listener supported, so please support the show with a monthly donation.

Chapters

• 2:30 Episode Intro
• 3:24 1: Designing with code is in, making pictures of UIs is out
• 8:02 Can design with code scale at organizations?
• 10:49 Rise of the Design Engineer?
• 19:25 2: The new critical deliverables for systems teams
• 28:25 3: Brand expression and shipping one-offs
• 32:02 Stop gatekeeping!!
• 34:03 4: Organizational behavior change, not components
• 41:25 Getting your reps in
• 43:04 5: The DS narrative is now about quality, not efficiency
• 46:45 AI owns the efficiency pitch
• 48:20 The new process
• 51:16 Fluffy stuff (you'll miss it when it's gone)
• 53:00 Wrap-up

Transcript

Elyse: The story we've been telling for the last 10 plus years has been about efficiency. We're still using this efficiency story, even though we're also now talking about LLMs. We're saying, how efficient can I be by having the LLM generate all of these things for me? And I think that story is true, but I think it's immediate. 6, 12, 18 months from now, I don't think it's gonna be novel anymore.

What is it that your execs and leaders are gonna be saying, when that's not new and novel anymore? And I think they're gonna be saying things like, why is the code quality of this so crappy? How come I'm seeing the brand get watered down into a nothingburger in all of these designs? Our PMs, they can deliver working prototypes of feature concepts, like why is the design so bad? None of those things are really about efficiency.

Noelle Lansford: Right.

Elyse: The story that we need to get ahead of, and start telling now, is something about how the design system is going to enable your PMs to ship a feature to prod, that fits the brand, and isn't spaghetti code. What is that, and can design systems do it? And can we position ourselves in a place to deliver that?

Noelle Lansford: AI already owns the word efficiency. Design systems sharing space with that isn't going to compete. AI's going to win the efficiency pitch. 

Elyse: Yeah, I think that may already be true.

Noelle Lansford: Yeah. So what does design systems have? What do we offer? If you understand how to position design and engineering ops and high quality craft as an enablement operation— 

Elyse: My favorite word, enablement. 

Noelle Lansford: —inside of your organization, people get that. We're here to make your experience great and if we can make our designers and engineers and our product owners and partners have the best experience ever, and we can take the burden here, we can take the burden there, we can take that, we can take that, figure out the things that you can take from them that are the things that they don't wanna do, right? The things that could be centralized. Those are the things that are the design system. 

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. Let's dive into the show. 

 All right, welcome back to part two. We're gonna start talking about what we see coming up for 2026.

If you were listening to part one where we were recapping my 2025, not predictions, we decided that they weren't predictions, we decided that they were an encapsulation of all the things that we were seeing. So I'm gonna say, looking at my list here, that four of our five for 2026 are chatter, things that I'm hearing, trends that I'm seeing, and one of them is a trend that I'm seeing and also a really strong take that I have.

Again, I have Noelle joining me to talk about 2025 and 2026. Hey, Noelle.

Noelle Lansford: Hey, I'm excited about this. Since now we're talking about this as trend encapsulation, we need to be like reporters, like: coming to you live—

Elyse: from LinkedIn!.

All right. Let's get in to what we see on the horizon for 2026.

Noelle Lansford: Let's do it.

Elyse: I'm gonna start with the hottest of my takes, uh, which is that designing with code is in and making pictures of UIs is out, period. Why are we still making pictures of UIs?

Noelle Lansford: I, I love that you started with this one because I feel like you're not alone in this prediction and designers are on board with you. That's my hot take addition to that.

Designers that have been in Figma, I'm talking to them and they're like, I don't even wanna touch Figma anymore. And like, nothing against the tool, Figma, hi Figma, I love you. But like, if I can do it and there's code as a prototype at the end of it, why wouldn't I do that? And I'm seeing so many more designers, you know, at medium and large companies start making that transition. 

Yeah. 

Elyse: A hundred percent agree. I have so many thoughts about this. I have been seeing so much chatter about this in the last six months, in a way that I didn't see any chatter about it prior to that.

And I've personally seen the transformative effects. We've been using a design with code tool called Dessn at Color. More on that another episode, I am gonna have Gabriela, one of the co-founders of Dessn on the show later this year. I'm a huge fan. Suffice to say, I'm seeing that happen in real life in my company. I'm seeing a lot more chatter about it on LinkedIn.

But the reason that I say that this is kind of just a hot, spicy take, 'cause I don't actually know if I think that this is a thing we're gonna actually see a ton of this year. I think that there are so many companies who are still deeply, deeply, deeply invested in— we're gonna say Figma as a shorthand for this process of working. But again, it's not about Figma as a bad piece of software by any means.

But this way of working where, you write a product requirement doc, and then the designer does a bunch of pictures, and pixel pushes, and then you hand it off to engineering.

And more than I'm seeing chatter about designing with code, I am still seeing chatter about generating code from Figma. Do you disagree?

Noelle Lansford: I don't know if I disagree. Maybe it's the algorithms. I feel like I see more people talking about starting in code, than the other way around. But I don't doubt that that content's out there is the thing.

Elyse: Yeah.

Noelle Lansford: I just might not be seeing it because of the people that I hang out with. 

Elyse: Yeah, I see a lot of designers talking about, oh, I'm learning these vibe coding tools, or I'm, you know, learning code stuff myself. I think at organizations there's still a choke hold of like, first the designers use Figma to make the pictures, and we have these Figma components of our design system, and then we're trying really hard to like use Figma MCP to generate mocks, I think that that's still the primary way of working.

Noelle Lansford: That's true. That's true. I think there's buckets of people trying the different things.

Elyse: Totally.

Noelle Lansford: What I see a lot of is like design technology exploration teams. Where it's like, people are still deciding what tools to use. A handful of companies that I've worked with where it's like, okay, this product is gonna try to use this design tool, this product is gonna try to use this design tool.

For an exploration standpoint, it makes a lot of sense, right? The jury's out, I feel like, there's not a clear winner, like maybe, maybe you have opinions, Elyse, on the best one. But I mean, as far as universal adoption, I think you're right. People are still very locked into Figma. People are very locked into that workflow and because they are locked into it, they wanna see it work. So there's— 

Elyse: Yeah. 

Noelle Lansford: —still a lot of exploration in that way. And, at the same time, at the same companies, there's teams that are off doing the other thing. So it's like split down the middle even at the same company.

Elyse: Yeah, totally. I don't think we'll see a clear winner or cohesion this year. I think we're gonna see a really long tail of organizations still primarily working in Figma and then trying and, and here's the spiciest part of my take:

I think that we are going to spin our wheels for a lot of this year trying to get code output from Figma to be good.

Noelle Lansford: Mm-hmm.

Elyse: I know somebody is listening, going, mine's good. Good for you. In general, it's not good. And I don't think it will ever be as good as the code that we already have.

But that's the thing. It's not because the code that's being generated is garbage. It's that we already have the code components.

Noelle Lansford: Yeah. You already did it. 

Elyse: You already did it. You might as well be using that.

And so, you know, it's not about the quality— because the quality of the code that Figma is gonna let you generate is gonna get better.

Noelle Lansford: Right. If you already have it, then you already have it.

Elyse: Exactly.

So I really see this happening in, in a couple ways. Like one, I just think that that's illogical, right? It is illogical to make a picture of a UI when you can create a working UI that shows you states and interactions and animations. I think it's illogical to waste credits, your LLM credits, generating code that you already have.

From that standpoint it makes so much sense, that we are going to start to work with the things that we already have, with the code components that we already have, and be able to design with them.

And I will always, I will always come down on the side of the browser and tools that let us work in that medium. That is always gonna be more accurate than trying to generate it from an image. Like you can encode a bunch of stuff into Figma nodes and into schemas, like I know Nathan Curtis is doing a ton of stuff here. And it's really powerful and I like great, amazing. And I think that ultimately, what you're trying to build is web. It's HTML and CSS, it's React, or whatever, and you already have that. Why try to recreate all of that, when you can just use the thing that you already have? Maybe you could go to all this trouble and you get finally like a one-to-one and you still have made a copy, like you already have it, you can just use the code. 

Noelle Lansford: I think the answer to that question— 'cause I get frustrated by this as well— but then I go into a large enterprise and think about how it has to scale for the design team. And I think if it was just about scaling for the engineering team, we'd already be there, but we have not yet found a way to scale to the design team that's meaningful.

And until that's solved, I understand why people are gonna want to try to solve that problem that way, but you know, is that the best way to solve that problem?

Elyse: Yeah. And I, and I don't think so, and I think the tools here are still early. I was talking about Dessn a minute ago. I think it's incredibly powerful, but they're still very early. You're still prompting a lot with words.

Or you have tools like Subframe that are replicating, Figma's pixel pushing UI, and you can only use like Tailwind. And I don't think either of those UIs— prompting or just, change like one pixel at a time— like, I actually don't think either of those are the most ideal pattern for creating designs.

I think we're gonna see a lot of new interfaces here. I think we're gonna see a lot of exploration. I think prompting in English will only be a small part of that puzzle. But I do think that we're gonna see a move eventually towards designing with code because—

Noelle Lansford: Mm-hmm.

Elyse: —I think you have so much more precision, when you actually can see like, the select, the shadow, the animation, the behavior, in a way that I think it's just incredibly hard to impossible to do that when you're making a picture.

Noelle Lansford: Totally.

Elyse: And— you were talking about this a few minutes ago with designers experimenting with tools, and, and you're seeing designers like, I'm trying vibe coding things. I really see the design engineer, the designer who can think in the medium of the web, as the designer who is gonna be really successful in the future. This is definitely chatter I'm seeing all over the design industry, people talking about design engineer as a title.

Noelle Lansford: People want design technologists suddenly.

Elyse: Design technologists, design engineers.

Noelle Lansford: Where were they at earlier?

Elyse: Yeah. Yeah. Well, you know, it's funny because I see this actually as a return to the way that we worked in the early two thousands. The tools are really different, but in 2005-12, before design systems a little bit, the designer on the project would very often be making pictures in Photoshop, and then also creating the HTML and CSS skeleton. Like this was the beginning of my career. I made a Photoshop mockup. It was pixel perfect. You had little like image gradient maps that you would cut out and then like repeat in CSS, but engineers, backend engineers didn't understand anything about HTML and CSS. And they relied on the designer to also provide the skeleton of the frontend, and they would wire it up and connect it to the backend and APIs and functionality. And at the time I, I mean we didn't have React, and this was like even before jQuery, so like I wasn't making dropdowns, I was still giving them a picture of what the dropdown was supposed to be like.

Noelle Lansford: Right.

Elyse: To me, this is a so much more sensible division of work. You have design and the front of the frontend, and interaction pattern, so like there is some JavaScript involved, right? State, hover and focus, you know, animations, what happens when I click on this. Versus functionality in the backend, and when I say functionality, I don't mean you click on it and it opens. I mean—

Noelle Lansford: Right,

Elyse: —it saves, it goes to this page, it navigates in this way, it, you know, calls the API.

Noelle Lansford: Saving your data, all that good stuff. 

Elyse: Because look, most of the engineers we call full stack engineers are backend engineers who are also being forced to write the frontend. And they don't want to.

Noelle Lansford: Or vice versa.

Elyse: Yeah.

Noelle Lansford: Yeah. Yeah.

Elyse: You know, we, we spent a decade arguing over whether or not designers should code. And I, and I don't even think that's a relevant— like, yeah, you can learn to code, you can learn git, you can get in the terminal, like blah, blah, blah. You can learn the details of the code.

But I think one of the things that LLMs do, is they actually allow you to lever those skills, without actually understanding the code, right? Like understanding how interactive elements work in the browser, what's possible, making the variants of a component, understanding the DOM, how to articulate the logic and branching pathways of a component, right? You can use those skills without actually having to know how to write the individual lines of code.

Noelle Lansford: Right.

Elyse: And to me it makes sense that designers need to know how to do those things, because the designer is the person who owns the UI, which is not a picture.

Noelle Lansford: Know your canvas.

Elyse: Anyway, I feel really strongly about this.

Noelle Lansford: No, I love it. And I feel like funny about it, because we started at different times, but you had this experience as well, like I started as a technologist. It wasn't called that then, but that was my job, and I felt that it was a very underappreciated job, which I think all design technologists have felt. 

Elyse: Yeah.

Noelle Lansford: At some point in their career. 

Elyse: Yeah. Well, and especially in the late 2010s, it was a thing that we were still hiring for, but also kind of like, well, you're not a real engineer, but you're not really a designer. And you're just like— 

Noelle Lansford: Yeah there were a lot of like social bummers about it.

Elyse: Yeah, yeah, yeah, yeah. But that was not true in 2008, and I think we're going to see a return to the criticality of that role.

Noelle Lansford: Yeah. Well, and it's, it's funky too, because I feel like everybody is a junior design technologist.

Elyse: Yeah.

Noelle Lansford: Because they're doing vibe coding, and it's like, aha.

It's interesting to watch, right? Because everybody's making the same mistakes that I feel like— and I will probably make them again in AI too, but like— I remember one of the things that I did very early on as a design technologist, was being the busiest person in the room with nothing to show for it. And I just feel like I'm watching everybody do that right now with AI, where it's like, I can do this cool thing, I can do this cool, look at this cool thing. And it's like, yeah, but what did you make? What did, how did you tie that back into your business objective? How did you support your goal? It's like, I feel like—

Elyse: This is, this is a little bit of an aside, but I feel like that's the difference between the design technologist title and the design engineer title. There was a period of time where the design technologist title was the innovator, like, oh, look at this, we can try this new thing. But they didn't actually really have a pathway to shipping stuff.

And I think the design engineer, or the idea of a designer who has these skills— and here's another piece of chatter I'm seeing all over the internet— they're shipping to production. And from, from the way that the titles have shaken out, that is design engineers.

Obviously there are design technologists out there who are shipping to production, and titles are only one piece of the puzzle. But generally, that's the way that I've seen it shake out. Because I, I do think it's not about, hey, look at this cool thing that I can make, although you have to do that to learn. But it's—

Noelle Lansford: It's so important.

Elyse: it's so important to learn. You have to have room to experiment.

But from an organizational standpoint and the idea of like, what is this is gonna mean for our jobs and our teams, I think it's going to be: designers own the front end. And I think there are tools, like Dessn, that are making a pathway, a UI for designers to own the frontend without having to code.

And I see a lot of people talking about like, I'm a designer, and I finally got over my fear of the terminal and downloaded Cursor. And like, that's great and amazing, like, if you wanna learn how to code, that's incredible.

But I feel quite strongly that you shouldn't have to. And that we are gonna see new tools that allow you to leverage those skills, and the skills of understanding the browser, and the skills of understanding the UI, and the interactions, and the frontend, without actually having to be in terminal, in GitHub, in the, the specific lines of code.

Noelle Lansford: Yeah. You know, the thing that I ran into very quickly is, it's just too much to keep track of, right? I never found myself to be an expert in both. And so I was like, okay, I'm gonna put my flag in the design sand, and say I'm a designer who knows how to code. You don't need to do with all the latest code technology things that are happening. My decision was like, what's the thing I'm gonna keep up with? I'm gonna keep up with design. I know how code works. I know how the browser works. 

Elyse: Yeah.

Noelle Lansford: Instead of just, I'm split down the middle.

Elyse: Yeah. Like, I, as someone who actually considers myself quite strong in both, I, there's still a whole swath of things that I am not good at. Like, I'm really not good at animation and motion. I was never the person who was making CSS art. I'm like, okay, at React.

I mean, the, the range of things that you can know is extraordinarily big. 

Noelle Lansford: There's so many things. 

Elyse: But your company, the needs of your team, are really gonna define what those skills are. I just haven't had need to be really good at motion in my career, and there are some companies where that's just really important. But just to, to kind of come back to this idea of designing with code is in, and I think that there are some skills that designers are going to need to continue to develop, that are around the skills of working with their medium, e.g. the browser, rather than making pictures.

And we were talking about ownership in the previous part, the 2025 recap, but I actually kind of see some of the, the reluctance or fear of designers doing this, coming from what seems to be a like, fear of losing control of the output.

Noelle Lansford: Mm-hmm. 

Elyse: Because the browsers are variable. You can have users zooming on your things, you can have users with like custom themes. You know, LLM output is non determinative. I just feel like the idea that as a designer, the picture that you made was a correct and complete controlled output of what you were gonna get. It was just like really obscured by the way that we were working, right? We were like, oh, I've made the design and I had full control over what the design was, and its output. Like, no, you didn't, 'cause then you handed it over to your engineers and they did something different in one place, and then all the browsers are different, and then the user, you know, is zoomed into like 400% font size. And like, you didn't actually have that much control over the output of the design that you made. And so getting comfortable with that is, I think, a really critical part of designing with code as well.

Noelle Lansford: Yeah, just know your canvas.

Elyse: All right, moving on to number two. I said last year that I thought we were gonna do patterns instead of foundations, but I don't really think that that came true.

And I think what I'm seeing, and what I expect to see in 2026, is actually that, design guidelines, agent rules, tokens, and semantic APIs, these are gonna be critical deliverables for design system teams.

So, Noelle, in the pre-show, you coined this idea of foundations are in, components are out. What do you mean by that?

Noelle Lansford: Yeah. Components are out if you don't have them yet. If you have components, you're gonna use them, but you're just not gonna be focused on making them.

Elyse: Like, making your own inputs, making your own buttons, like rebuilding custom versions of your own atomic components. 

Noelle Lansford: Right. Yes. 

Elyse: Another nuance here is that everything is a component. A component is a design system component that's in our package, but every React chunk, every React file is a component.

And so what do we mean when we say, we have a component or we need to make a new component? This idea that the design system was components, and the product was one-offs, I think just doesn't hold up anymore. So I think making these atomic components is not where design system teams are gonna be spending their energy.

Noelle Lansford: At these really large enterprises that I've been talking with, there's such a focus on tokens, and foundations, and basically, what are the guiding principles that all of us need to understand.

A lot of this has to do with all the AI experimentation. If you don't have your brand locked in, you're never gonna see it again, because that'll get generated right out.

Elyse: Mm-hmm.

Noelle Lansford: There's none of that left.

Elyse: Yeah.

Noelle Lansford: So being really clear and explicit on what those principles are— Like what is this supposed to feel like? What is this supposed to look like? How are you supposed to respond to using this as a user? If you don't have those things, your design system team is probably gonna be really locked in to that, and figuring out how to make that as consumable in small pieces as possible, which is usually gonna be a token.

Elyse: Let's break that down. Tokens, obviously we all know what tokens are, but being able to define, these are our colors, these are our semantic colors, these are our brand colors, this are our type scale. Like all of these little decisions about what things look like, being encoded into individual variables.

But I think we're also gonna start to see something that Murphy Trueman has been writing about, which is this idea of your component is an API, or your design system is an API. The example that I really like here is, let's say that each of your components comes along with a schema that defines specific relationships that it can have. So, you know, on a page you can have a button, and if a button is standalone, it's primary, and if there's a primary button, it can have a secondary, but it can't have a primary and a tertiary together. Or maybe it can, those are your rules, and those rules are what makes your brand feel like your brand, and your product feel like your product.

But we haven't ever defined that in a, any real, structured way. I think a lot of design systems, and especially ones that have patterns, start to define this, but not maybe explicitly in terms of like a schema, and when I say a schema, I mean literally like JSON, like a structured computer readable object.

Noelle Lansford: Yeah, I think that that level of detail would bode well at companies that don't change their brand, like ever. Like they know their brand they know it well and they're gonna stick to it. When there's a lot of churn in the brand definition, those kinds of rules are gonna be really hard for organizations to adopt at a pattern level, because you're gonna start getting into the like, well, why can't we change this? Why can't we try it this way? And now we're like programmatically defined that we can't do it that way.

We were kind of talking about this in the 2025 piece, right? I really do think that there's a lot of value in that for companies who aren't technology companies that have a brand, that people know, that they're not eager to change. That's an investment that could totally be worth it. 

Elyse: I love that you brought that up, because at Color we're actually doing a lot of evolution of our visual language right now. Our brand isn't really changing, but like, how do we evolve our visual design? And so the downside of a semantic API like that, or a schema like that is, is rigidity. For sure.

Noelle Lansford: Mm-hmm.

Elyse: I think you're right. I think we'll see it at some places and not others. I think we'll see more or less rigid versions of it. One of the things that I'm experimenting with, that I think maybe is the less rigid version of it, is this idea of encapsulating design guidelines. You know, maybe this is like agent rules or, you know, a system prompt with design guidelines.

I've been experimenting with it from the, how do I put this into the LLM? perspective, but any time that you are forced to articulate your own thinking or methodology, especially around something as subjective as design, you're actually doing a really, really powerful design exercise.

So we've been thinking about colors and, you know, we had rules, now our design has evolved. Our design needs to evolve. So we're using colors in ways that don't quite feel good and we know they don't quite feel good, but we need to ship it, and so we're just gonna go with it.

And we're like, okay, we need to take a step back, we need to codify our thinking around this so that our designers can design consistently in a way that feels really good to us and that meets our needs.

And then I think we can take that and put it into design guidelines that we can give to, in our case, Dessn or, you know, into, into any kind of like LLM that you're using.

So there's all kinds of subjective and nebulous design decisions, that when we think about AI being bad at design and producing slop, it's because there's no, they're using these foundational primitives that have no semantic meaning, and they're just guessing. 

Noelle Lansford: When you put in nothing, you get out nothing!

Elyse: Yeah.

But we have subjective design rules around those things. And, and I'll, I'll give you an example. Think about a chip component. In a lot of public component libraries, a chip is used to show status, right? You can have, you know, an error and a success and a warning. You have these statuses and the colors are semantic that go along with them. Well, we have that component. But we are a cancer screening product, and so we never ever want to use like a scary red chip to show a patient their risk, like that is incredibly unempathetic. It goes against all of our design principles. And so how is the LLM supposed to know that?

Noelle Lansford: Right, because that goes against like almost all public knowledge of chips.

Elyse: Right. And that is the kind of thing that we need to be able to put into words. It could be a semantic API, but I think it can also be something like a system prompt, that's like, here's some things that we never do. Here are some things that we very often do, and here's why.

We've been thinking a lot about, clickable cards and not clickable cards. What are the affordances? What's the difference between those two things? So being able to say clickable cards have this border, this shadow, this affordance, and non clickable cards look like this, would give an LLMs lot of knowledge, based on what it is that you ask for, like showing content versus a card that actually goes somewhere.

And that kind of written design guideline, agent rules, schemas, like defining these semantic relationships and defining the subjective reasoning behind some of these decisions, I think we are gonna see those as a really critical deliverable for design system teams.

Noelle Lansford: I, I mean, that's what I've been calling foundations. I feel like all of us been calling that foundations for a long time. It's just such a easy layer to skip. And I'm so glad that it's getting a spotlight in 2026. If you see a brand that makes you feel a certain way, they probably have brand foundations. If you have a brand that like, functionally works, and makes the company money, but like... [shrugs] that's the thing that is hard to pitch when you're in a company. It's like, well it still works. And if you're really stuck on it works, then you're probably not gonna get really tight foundations.

Now, with the expansion of AI. You have to have this. If you want to see your brand on the other side of all these iterations, you have to know that stuff, and you've gotta have an opinion about it.

And it might feel kind of like high and mighty design stuff. It feels really fluffy.

Elyse: Because it's not shipping anything.

Noelle Lansford: Right! It doesn't ship anything, but it does very directly affect—

Elyse: Everything that you ship.

Noelle Lansford: Everything. Everything. Like you can have an absolute nothingburger of a brand if you don't do this part.

Elyse: I think we're gonna see a lot of nothingburger designs in 2026.

 But that actually takes us straight into prediction number three, which was one that you suggested and I love, which is we're gonna see a real focus on brand expression, but also on one-offs.

Noelle Lansford: Yeah. AI is making it so possible to create one-offs and experiment quickly. And I don't think design systems can or should stop that.

We can have opinions about the quality of the one-offs, but I think we're gonna find ourselves in a pickle if we're like, well you can't do that because that's outside of [blah blah blah]. And it kind of goes against what we just said, right? But I think a lot of these one-offs are expressions of the brand. Or like you're talking about, I'm hearing a lot of companies say it's time to do a visual refresh. A really quick way to iterate is to iterate outside the design system. starting with the design system for iteration gets really slow in the components. Like, you may have some flexibility in your tokens and in your foundations to play around, but...

People want iterations and they want them now. And if you have the brand guidelines and you have the ability to generate them outside the design system, you're probably gonna do that, 'cause it's faster.

Elyse: I don't think this goes against number two at all. I think the whole point of having those design guidelines, tokens, agent rules, semantic APIs, is so that you can do iterations and, and do evolutions. To your point earlier, like it could be too rigid, yes. But if you can say, these are the rules that we know we don't wanna break, these are the design guidelines that make our brand, our brand, now you can, you can iterate and you can do one-offs. You can ship all kinds of things that still feel like your brand and your product that don't feel like AI slop and also don't feel like you've lost your brand expression.

Noelle Lansford: Yep. And I think we're seeing a lot of product teams do this.

What's interesting is, and it makes sense, right? It's like product teams are gonna experiment on their product. 

Elyse: Well, and that's where you should experiment, right? You put it out there, you learn, and either you're like, nope, not that, or yes, and actually now we want to codify that or systematize that, you know, so that, so that all the other teams can also benefit. 

Noelle Lansford: Yeah. I think the temptation here is going to be similar to what we saw in like 2023, which is like... there's gonna be more one-offs in 2026 probably, than there there've ever been. Design system teams, you don't have to go like, play whack-a-mole with this. That's my hot prediction. If you're a design system team, you can't focus on hunting all those down. 

Elyse: And you shouldn't. I think you shouldn't gate keep those things and you shouldn't try to stop it. This will take us into our next one, but I, I think you're totally right. The pressure to ship is there, and if as a design system team, you're going, no, no, no, don't like, include me, but we had to change this and we have to like, you, you are, people are just gonna go around you. We saw that years ago, and I think that that's even more true now.

So providing, again, design guidelines as a critical deliverable, or tokens as this critical deliverable that is going to enable teams to deliver these things— maybe calling them one-offs is kind of negative! —Like delivering features, delivering experiments, delivering new parts of their product, in a way that, frankly— isn't this the promise of design systems the whole fucking time? Which is like to deliver their parts of the product and their experiments while still being visually consistent.

Noelle Lansford: Right. Get your design guidelines in.

Elyse: Yeah. Yeah. 

Noelle Lansford: That's gonna be the fastest scaler, I think.

Elyse: Yes.

Noelle Lansford: More than, like you're gonna have people experimenting with AI, and it's gonna be frustrating, 'cause you're gonna be like, I have a button that's perfectly great sitting right there, and you've just generated a new one. Like there's just gonna be more of that.

Elyse: If you design with your code base, that doesn't happen.

Noelle Lansford: Right, and you're exactly right. Like, I hope to see more of that, but I also think there's gonna be teams off making completely experimental stuff that, you know, don't care about the design [system], like they're not gonna take the time to even hook that up. 

I guess just to say that like, can't worry about all of those, and it's okay for people to experiment, you know? We always say in design systems like, don't reinvent the button. But sometimes it makes sense to.

Like if that's really the focus of your product, sometimes it makes sense to reinvent it. Let the teams try!

Elyse: Yeah.

Noelle Lansford: You're not the gatekeeper of the button. 

Elyse: Gatekeeping is over. Really I think to, to sum up here, the point of brand expression, the point of one-offs, the point of not doing all this gatekeeping, is that we recognize that to have design as a differentiator, that involves iteration, it involves experimentation, it involves trying things. And that there is a natural progression, a cycle of expansion and experimentation, and then back to cohesion and consolidation.

We see this pattern over and over and over. Even amongst brands that I think are very, very established. They will kind of explore off in a direction but then you bring it back to the core brand.

And to allow for that, you cannot be afraid of that experimentation side. And you also have to be able to support when they wanna come back and do that consolidation.

Noelle Lansford: Yes. It can't be an I told you so. That doesn't feel good either. 

Elyse: No, that's not, it absolutely cannot be an I told you, like— 

Noelle Lansford: I'm sorry you did your job? 

Elyse: This is a natural pendulum that we're gonna see. And I think it's important that we do that because nothingburgers. It's so easy to generate stuff. All websites look the same. All web apps look the same. If you want design as a differentiator, you have to be able to evolve your design, and iterate on your design, and polish your design. And I think we're gonna see a lot more visual design craft, actually.

Noelle Lansford: I think so. I think, uh, the designers are gonna pull up for this one.

Elyse: I hope so. I can't wait to see it.

So speaking of gatekeeping, my prediction number four, and I know a lot of people are not gonna like this, because you really just wanna go off and make components, I guess? But design system teams, you are here to guide your organization through adopting new design and engineering process.

You are not a team that makes stuff. You do organizational behavior change. That is what you are for. That's, that's the new world. No matter how many people you have on the team, which it probably isn't a ton of people, you cannot build every component, every pattern, every one-off.

You cannot be involved— and especially, Noelle, I'm sure you can speak to this, but like at big enterprises? Like I can barely do it at a company the size of Color. But at a big enterprise, you have hundreds of teams? Like you, an individual designer, a design system team, cannot be the team that makes stuff that goes to production.

We just can't do that anymore.

Noelle Lansford: Put it on a shirt, put it on a poster, mail it to your friends.

Elyse: Venmo me, I'll send you one.

And I know that this has been a whole discussion, a kind of a contentious one over the last couple of years, is like, well, is it actually our job to teach you how to use Figma? Is it actually our job to teach you like basic design principles? Like, yes, it is your job? Like I think that factually, yes, in the future, it is your job.

The design system team is here to help their product teams, their designers, and their engineers level up their skills at design, level up their skills at frontend, adopt new design engineering process, manage that pendulum of, you know, consolidation and consistency, experimentation and one-off. Help the designers understand what components are, help the engineers understand what good front end is. Use these new LLM tools, provide tokens and design guidelines and system prompts for all of these tools. Build that infrastructure and that tooling.

And I think that's a really different— well, I was gonna say, I think it's a really different shape for design system teams, but I'm not actually sure that that's true. I think design system teams have been doing a lot of this.

Noelle Lansford: Yeah. 

Elyse: I think that's the place that you need to be focusing, and if you're not doing that, you need to be doing it, more than making components.

Noelle Lansford: Yeah. I love all of that. 

Elyse: I just had Noelle on to agree with me. Maybe I should actually invite a guest on who has different opinions.

Noelle Lansford: Hey, nevermind. I disagree and here's why.

Elyse: Thanks.

Noelle Lansford: And here's why I disagree. No, I, I really can't disagree with that. I mean, it is my company motto is, design systems are 90% people, the other 10% is easy.

Elyse: Put it on a shirt.

Noelle Lansford: That is just why, why I feel that way. That's literally it for me. If you understand how to position design and engineering ops and high quality craft as an enablement operation— 

Elyse: My favorite word, enablement. 

Noelle Lansford: —inside of your organization, people get that. We're here to make your experience great and if we can make our designers and engineers and our product owners and partners have the best experience ever, and we can take the burden here, we can take the burden there, we can take that, we can take that, figure out the things that you can take from them that are the things that they don't wanna do, right? The things that could be centralized. Those are the things that are the design system. And if you make that experience really great, then they get to focus on making a really great experience for your user. And they would never say, or I hope, they would never say, my user should just be smarter and know how to use my product. Like they don't get that luxury. Your user are your designers and your engineers. So like a little bit, how dare you think that it's not your job to help?

Elyse: Yeah, totally, absolutely agree. And I think the way that we help, is not, I'll make that component, I'll put it on our roadmap, it'll be ready in six weeks.

Noelle Lansford: Right.

Elyse: Sometimes you make a thing. Like, I literally today shipped a new component, was pairing with my designers on, because two different designers needed something on two different parts of the product. And we were like, okay, how do we get together? And that was so that my engineer didn't have to build a janky version of it themselves, two different janky versions of it. And like, I knew that this could be a place where I could really make us go faster.

But I would say that I spend, and I think that this is about the right ratio, maybe 20% of my time actually making things. Not new components, that's actually quite rare. But I'm talking about even like shipping, you know, code updates to existing things, or like doing refactors.

Enablement is such a huge part of the job.

You know, I think for a lot of design system teams, when they think about this idea of oh, I have to teach my designers, now I'm a content creator making Figma tutorials. But I, I think the enablement is actually the systems thinking part of design systems, applied not to components, but to organizational behavior and process, right?

How are your designers and engineers interacting? How are they working together? Where are the places that things aren't smooth or is confusing? So for me, as we've been using Dessn to have designers designing with code, we're handing off Dessn projects about as much as we're handing off Figma right now. But the, the process of doing that is still very, very new.

Noelle Lansford: Right.

Elyse: Maybe a third of our engineers have actually been on the receiving end of that so far. There's features that Dessn doesn't have yet. You know when your product designers hand off something in Figma, you have stuff written on the art board that's like notes?

Noelle Lansford: Yes.

Elyse: Where does that go? You know, how much of the code can they actually use out of Dessan versus, you know, some of it's just like scaffolding code.

So there's all of these ways of working things. And a huge part of my work is like, keeping track of all of that, thinking about it, documenting it, writing it, like I am, I'm going to Eng All Hands and I'm talking about it. And it's not even, I made a formal training. I'm literally just like, I need to just show up here and talk about it. 

Noelle Lansford: You're just there.

Elyse: I'm coming to your standup. 

Noelle Lansford: Showing up is huge.

Elyse: I'm asking you how it's working, I'm DMing you, I'm following up. I'm trying to define what that process is. Especially with these LLM tools, I don't have a playbook that I am somehow keeping secret from the rest of my company.

We don't know how to do it yet. Everybody is figuring it out. And that's true, LLMs aside, any time that you change your way of working, you have to go through the struggling, messy middle part of figuring out how to do the new thing. If you're listening, do you remember migrating from Sketch to Figma? Like that is the same thing, and part of your role on the team, if you were on the design system team then, was helping your teams figure out how we were gonna use Figma to do designs instead of Sketch.

Noelle Lansford: Right. I mean, part of it too that's interesting is with the going downness, whatever that, whatever that is? 

Elyse: What?

Noelle Lansford: Going downness. This is my Midwest coming out, come on. The going downness of components.

Elyse: The fall of components.

Noelle Lansford: There we go. Yeah, I like that. That's dramatic. But the fall of components, with that being less of the focus, there we go. We got there.

With components being less of a focus, it's interesting that your repetition of tasks is going down as well. And I feel like that's one area that design systems has always had an edge on, right? The reason that you're able to train people in Figma is because you just sat there doing the same task in Figma 50 times in a row, and you know that task like the back of your hand and a product designer isn't gonna have that much repetition doing properties and variations and things like that. Design system teams, they get the reps in. And it'll be interesting to see if we're still getting the reps in on these kinds of tools. Like if we're not focused on building the same thing over and over and over again, you're not gonna have the same depth of expertise as quickly. Not to say you won't get it, but I don't know, that's an interesting aside to how the evolution of team training and expertise on design systems teams has been established in the past.

Elyse: It's absolutely true, at least from the, the side of like, how do I build with LLMs? Like, I, I don't know. It's as new to me as it is to anybody else. But I am finding, to your point, that because I am trying to do the enablement, I'm getting my reps in. Because I'm seeing—

Noelle Lansford: There you go. 

Elyse: —Every team. I'm looking at everybody's project. I'm helping them, I'm pairing with them, you know, and, and so I do think design system teams, like the whole value that we offer is sitting across. Across the org, cross functionally. And so I think we, we are gonna get our reps in. I really do.

Noelle Lansford: Yeah. Nice. I love to hear it. 

Elyse: And related to this, see, they all tie into each other.

Prediction number five, I think that the next chapter of the design system narrative is around, for lack of a better word, quality rather than efficiency. When I think about positioning design system teams as doing organizational behavior change and doing enablement, it's also part of the story about the value of design systems, the value of your role.

And especially when we think about, you know, a post AI world building the component, building the input for the umpteenth time, is not a valuable use of your time as an individual designer or design engineer or engineer. Like that already exists, you probably already have one in your code base.

And I think at peak design systems, we were saying, the sum total of my value to this company is that I can like, make buttons. You know, and obviously I'm being snarky here.

But the things that we were selling to the organization were these much bigger stories about, what is our value prop? What does a design system offer you? I think those ultimate values of a design system are still there. I think we need to be talking about that story, telling that story, and then repositioning design systems and design system teams in a, in a little bit more of a future-focused way.

Noelle Lansford: Yeah.

Elyse: The story we've been telling for the last 10 plus years has been about efficiency. We're still using this efficiency story, even though we're also now talking about LLMs. We're saying, the design system enables your team to get the value out of LLM enabled work, right? How fast can I generate these component variations? How efficient can I be by having the LLM generate all of these things for me?

And I think that story is true, but I think it's immediate. I think it's true now, and I think it will die quickly. I think once we have gotten over this initial hump of like, how do we actually get some the savings gains. 6, 12, 18 months from now, I don't think it's gonna be novel anymore, that your engineers can work faster by using Cursor to generate their code, or like with Figma MCP. I think maybe that's not even novel in February of 2026. Maybe it's some places it is, there's gonna be a long tail.

But like, what is it that your execs and leaders are gonna be saying, when that's not new and novel anymore? And I think they're gonna be saying things like, why is the code quality of this so crappy? Why am I hearing from engineering teams that, the maintenance burden is so bad, and they have all this legacy spaghetti code now? They're gonna be saying things like, how come our design is diverging? How come I'm seeing the brand get watered down into a nothingburger in all of these designs? They're gonna be saying, how come Team A is putting out great new stuff and shipping, and Team B isn't? Our PMs, they can deliver working prototypes of feature concepts, like why is the design so bad? Or when the PMs ship a whole new feature straight to prod, why does it suck so much, and why was there an incident?

None of those things are really about efficiency.

Noelle Lansford: Right.

Elyse: For lack of a better term, I'm putting that all under the heading of quality, which is like, not really the right word, open to suggestions. But I think the, the story that we need to get ahead of, and start telling now is something about how the design system is going to enable your PMs to ship a feature to prod, that fits the brand, and isn't spaghetti code.

What is that, and can design systems do it? And can we position ourselves in a place to deliver that?

Noelle Lansford: I wanna say I disagree, just so that I have a disagreement with you, but I, I'm really interested in this. I don't know that quality's the right word either. AI already owns the word efficiency. Design systems sharing space with that isn't going to compete. AI's going to win the efficiency pitch. 

Elyse: Yeah, I think that may already be true.

Noelle Lansford: Yeah. Like already. Back to the one-off thing, like make a one-off. You can keep on making one-offs, and it's a lot cheaper than it used to be to do that, purely, you know, speaking from a money perspective.

Elyse: Maybe we'll talk in a different episode about how the cost of AI is really subsidized right now, and all these code generations are actually way more expensive than it's actually costing us, but that's a whole different episode.

Noelle Lansford: Yeah. But yeah, like AI has efficiency, so what does design systems have? What do we offer? 

Elyse: I think you're really onto something here because we were saying, hey, this reusable component can make engineers move four times faster from idea to product. But now the engineer with the LLM can do it 10 times faster.

The question then becomes, is the engineer with the LLM doing it with the system, or are they generating new code and like— 

Noelle Lansford: And like, what is the system?

Elyse: Right. Is it, is it a component? Is it the design guideline? Is it the pattern? Is it how we write copy and speak to our users? It's all of these other things. And again, I think we're gonna see— you can call it slop, you can call it experiments or explorations or deviations or one-offs or like whatever. You can just call it shipping product. But like, we're gonna see a ballooning of output. I think we already are, because output is cheap. And I maintain that output has always been cheap. We just didn't think about it that way. And the LLMs are really showing us that it is cheap. Like that you can throw away that code, you can do that experiment, that AB test, delete that stuff. We can just do that faster now.

Noelle Lansford: Yeah. And people are doing it with their own hands that have never done it before.

Elyse: Yeah, there's more cooks in the kitchen, right? I think designers shipping to production is fucking cool. And like, we should do that. And it means that there's more cooks in the kitchen. So the system becomes the ways of working, the, to your point earlier, foundations, but I don't necessarily mean atomic components.

Atomic components plus design guidelines, plus, you know, maybe semantic relationship API schemas, plus these enablement things, that make it possible to live in a world where lots of people can own the product, can ship good design.

What should a product manager know about design to be able to deliver a really good feature by themselves? I don't think that a PM has to be a designer, and a designer has to be an engineer. I think that as a product manager, you should be able to understand your user and your business really well. And say, this is the flow that I want, this is the experience that I want, this is the need, the job to be done from the user, the business logic. And be able to get, I'm gonna say in 90% of cases, just get out of the system a UI that makes sense for that.

And then the question becomes, is that the UX we want?

Noelle Lansford: Mm-hmm.

Elyse: Right? Does that feel right? Like, do you go through it linearly? Is it all on a page? Is it on a modal? Do we put that on, you know, this part of the flow, or do we put it, you know, down here? do you put it before this branching pathway or after that branching pathway? You know, do we, do we want them to have options? Do we wanna give them a default that they have to choose from? These other experiential design things. But they should be able to be like, here's a thing that I'm trying to convey, and even maybe though, the specific components, you know, maybe it shouldn't be a dropdown. That's a conversation you have with your designer about like, what's the right UX for this? Like actually a dropdown in a modal is a crappy UX for what you're trying to make that do. But if you make it with a dropdown, it should be the design system dropdown.

Noelle Lansford: Right.

Elyse: Coming from a design perspective, maybe it's actually a little bit different.

Maybe from a design perspective, you're like, I need to explore, this dropdown thing that we have needs to also be able to like do all these other things. And so I don't wanna just plop the dropdown in there, I need to actually evolve the dropdown. I need to evolve, the behavior and the interaction and the details of this thing.

And so I think like the ways that we access the system, and what we get out of it, and how we apply our roles, and our expertise, is going to have to evolve. And I really want the systems to be able to enable that. I think that's very, very interesting, and I think that it positions design systems as an extraordinarily powerful enabler of all the things that you need to do to have a really, really good product.

Noelle Lansford: Totally. I, I think, the thing that's gonna be hard is proving value. And I think that goes back into the narrative that you tell, right? Exactly what we're talking about. But it is gonna be hard, I think, for organizations to adopt that, because you basically have in-house consultants, right? Like that's your team, and you know, it is a riskier spot to be in, I think, where it's like, okay, well, do we need that many consultants? What are they actually doing? What is the output? This team has this output, this team is doing what? All this fluffy stuff. And the hard thing about fluffy stuff is you don't really know that it was important until it's not there.

Elyse: Yeah.

Noelle Lansford: And then you're gonna scramble to get it back. So I think that's gonna be the ongoing challenge with it. But I really like this direction a lot, and I think it is the meat and potatoes of what design systems teams are actually good at. 

Elyse: And that's why I think it's, it's narrative, right? It's story. And I think we need to be telling that story now. If you wait until you've done all of this enablement work, then it's like, well, why are you still here? Positioning design system and the design system team as critical elements of how your organization meets its goals, that's the story that we need to be able to tell.

It is a quality story, it is an efficiency story, but it is also a ways of working story. It is a, enabling all of the people on your team, enabling all of their roles. Right now you are tying that story into, you know, moving faster.

It's a speed story right now. What I'm saying is, it's a speed story today, and it's not gonna be a speed story in six to 12 to 18 months, when everybody's going, why is our brand look like a nothingburger? That is a quality story. And we gotta be thinking about that now and, and understanding that what a design system offers, is organizational behavior change and enablement of, of how we ship UI. And that's really, really critical. Because I think, again, design system truthers, we know that that's true. We know that that's real. And it's a matter of describing that story in a really compelling way that that gets everybody else bought into. And I think that that is some of the work that we have ahead of us.

Noelle Lansford: Now I want a sticker pack of nothingburger brands, spaghetti legacy code, and design system truthers. 

Elyse: Design system truthers. Yeah. I'll, I'll make, I think that's a good idea. I like that. Uh, if you would like a sticker, please comment, and maybe we'll make a sticker pack.

Alright.

I would love to hear from all of y'all, if you think that Noelle and I are spot on or totally off our rockers about our predictions, or our encapsulations of the chatter that we're seeing. If there's chatter that you think that we did not get here please tell me about it. I would love to hear your thoughts, your takes, as always. Really excited to be back for 2026 and Noelle, thank you so much for coming to give us some hot takes and some predictions.

Noelle Lansford: Thanks for having me. It's been a blast. Don't hold back, let us know if we were wrong. We wanna know.

Elyse: We do wanna know.

Thanks for listening to On Theme. 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!