Design Moves
Up the Stack
Design is moving from the artifact
to the decisions that shape it.
My first real experiment with an LLM as a design partner was at Bast, using Figma Make for the first time. I described an entire design system to a model and watched it appear in real time. Components, patterns, behaviors, tokens, the whole thing. A handful of sentences turned into something in less than 20 minutes that would have taken my team of seven seasoned experts at IBM eight weeks.
It blew me away, but it also felt strangely safe. I was still in Figma. I could make something impressive without touching the actual product. I couldn’t break anything important. There was still a comfortable separation between designing the thing and building the thing.
Then my CTO moved the design system into the real codebase. Suddenly I was in Claude Code, working directly against the backend and making changes to the actual product. Not a mockup or a prototype representing some future implementation. The thing itself.
I expected the revelation to be that I could “write” code now. That wasn’t it. The interesting part was how quickly I stopped thinking of the screen as what I was designing. I was making decisions about what existed in the product, how those things related to one another, what the system was allowed to do, what it should never do, and where it needed to stop and ask rather than make the call on its own.
Somewhere in there, the design surface moved.
I’ve spent more than 30 years watching the boundaries around design move. Desktop publishing collapsed the distance between the designer and print production. The web pulled us into behavior and interaction. Design systems took decisions we used to make one screen at a time and encoded them into reusable systems. Every one of those changes initially looked like a change in tools. In hindsight, each one changed where the design work happened.
I think we’re in the middle of a much bigger version of that now. We talk about AI generating interfaces, writing code, producing variations, running research, building prototypes. We tend to list each one as another capability to add to the pile. I’m starting to think that’s the wrong way to look at it. They’re all expressions of the same shift.
Design is moving up the stack.
The screen isn’t the whole surface anymore
Most of the software I’ve designed in my career could be understood as a collection of states connected by paths. This screen leads to that screen. This action produces that response. We explicitly designed most of the available interactions: what actions were present, what each one did, which state followed which, and where the person could go from there. We map the journey, account for the edge cases, and try very hard to make sure they never get somewhere we didn’t anticipate.
There’s comfort in that. We can’t control what a person does, but we can more or less control the world in which they do it. Agentic products change that model.
With an agentic product, the person might state an outcome instead of following a predefined flow. The system determines which capabilities to use, in what order, against which objects, subject to the permissions and rules we’ve established.
So the design problem changes from primarily:
“What screens and paths should I create?”
to something more like:
“What can this system understand, what can it do, what can it do to what, under which conditions, and where must it stop?”
You can still design the screens. You should. I still care whether something is six pixels off. But the screen is increasingly a view into the design rather than the whole of it.
The deeper design decisions are the objects the model understands, the relationships between them, the rules governing what can happen, and the boundaries around what can’t. If the product knows that this person is a customer, this document is evidence, this action requires permission, and this piece of information can never cross that boundary, those aren’t implementation details sitting underneath the experience. They are the experience.
Which means ontology becomes a design material. That’s a sentence I definitely wouldn’t have written a year ago.
It sounds architectural because it’s architectural. But it’s also deeply human. The way we define the world for the machine determines what the machine can understand about the person inside it. Get the relationships wrong, and the interaction eventually exposes it. Leave something important out, and no amount of interface polish puts it back.
Unlike the deterministic products most of us learned to design, variability isn’t something we can eliminate at the end. It’s part of the material itself. We aren’t designing every response anymore. We’re designing the conditions from which responses emerge.
That distinction gets even stranger when the human isn’t the only user. We’re starting to build products where a person asks an agent to do something, and the agent goes off and uses software on the person’s behalf. The relationship becomes person-to-agent-to-product. We’ve spent decades getting better at designing the two ends of that chain. We’ve barely started on the middle.
What does my product need to communicate so an agent understands what it can do? What does state look like when the user is an agent that doesn’t need a screen? How does the product expose enough meaning that an agent can act correctly without inventing the missing parts?
I don’t have clean answers yet. But I do know that designing better screens isn’t enough to answer those questions. The surface has moved underneath them.
The artifact stopped
being the job
Another change took me longer to see because, at first, it mostly felt like speed. I can generate an absurd number of potential solutions now at light speed.
A direction that once would have cost me a day can now cost me 15 minutes. I can follow an idea far enough to find out whether it’s any good instead of abandoning it because I don’t have three days to spare. I can get to working software early enough that somebody can actually use it instead of sitting through me explaining what it might eventually feel like.
For most of my career, making was expensive enough to impose its own discipline. If I had 20 ideas, I wasn’t taking all 20 to high fidelity. For most design teams, production costs still force those choices. That constraint is disappearing for me. When I can produce 100 plausible answers before lunch, the valuable skill isn’t producing answer number 101. It’s deciding which one deserves to survive.
That sounds obvious, but it’s changed where I spend my time. Everybody talks about prompting. I spend far more time on the spec.
The spec I’m talking about isn’t the document we used to hand engineering after we’d finished designing. It’s closer to a design brief with teeth. I want the outcome clear enough that we can tell from the outside whether it happened. I want the boundaries explicit, especially what we’re not doing. I want the system to know which previous decisions it inherits and which constraints it isn’t allowed to reinterpret. Before anything gets built, I also want to know what evidence will prove it works.
That last part matters more than I expected. If I tell a model to improve something, it can make a very convincing version of improvement. If I tell it what must be observably true when we’re finished, I have something I can actually judge.
Once those things are clear, I can let go of a surprising amount of the work. That’s new for me. For years, a big part of maintaining quality meant staying close to every artifact. Looking at the screen. Reviewing the interaction. Correcting whatever drifted between what I meant and what somebody downstream built.
Now I can put more of that intent into the system before the artifact exists. A strong spec lets multiple agents explore and build without me prescribing every move. A harness can evaluate work against the same outcome. I keep creation and evaluation separate. The agent that builds the work doesn’t review its own work. The work can spread outward without requiring every decision to come back through me.
The artifact still matters. Of course it does. People ultimately experience the product, not my beautifully crafted markdown file. But the artifact is becoming evidence of a larger design.
If the same system can generate one interface, then another, then another, what I own isn’t just the interface anymore. I own the logic that keeps producing it: the intent, the constraints, the quality bar, the definition of “done.” That changes the leverage of a design decision pretty dramatically.
A bad choice I make in one screen is a bad choice in one screen. A bad choice I encode into the system can come back a thousand times before I might even catch it. The reverse is true too.
For decades we judged designers largely by the quality of the deliverables they made. I think we’re going to judge more of the work by what happens when the designer isn’t there. That’s a very different way to look at this.
What doesn’t move up with it
An uncomfortable assumption is buried in all of this. If I can encode my judgment into a system, first I have to have judgment worth encoding.
AI is extremely good at filling gaps. Give it an incomplete direction and it will produce something plausible, often something polished. The language sounds finished. The interface looks right. The code runs. That polish is useful, but it’s also dangerous.
Something that looks finished has a way of convincing you (and your stakeholders) that the thinking underneath it must be finished too. I’ve caught myself doing it. The model hands me a perfectly competent answer and, for a moment, the fact that it exists becomes evidence that it should exist. That’s probably the part of this transition I worry about most.
Not that AI does the work, but that we stop doing the work.
Judgment is still a muscle. Taste is still something formed by looking closely, making things, getting them wrong, seeing somebody else’s better answer, arguing about it, trying again. 30 years of doing that changed what I notice. I can feel when something technically works and still isn’t right, even when it takes me a while to explain why.
The machine can imitate the evidence of that taste remarkably well. I’m less convinced it can form it, and I’m not sure what happens when we start removing the practice that formed ours. There’s a weird loop here. We’re becoming more dependent on judgment at exactly the moment we can outsource more of the activity that taught us how to judge.
There’s another cost hiding in that outsourcing that I’m starting to notice in myself. The more work I hand to an LLM, the easier it becomes to lose intimacy with my own thinking. I can ask for five approaches, choose the one I like, ask for five versions of that, and eventually arrive at a strong answer without ever having to understand the idea as deeply as I’d have if I’d worked my way through it myself.
That bothers me. Choosing an answer isn’t the same as forming one. There’s a kind of understanding that comes from wrestling with an idea long enough to know where it came from, what assumptions are holding it up, where it breaks, and why I believe it in the first place. If I’m not careful, AI can let me skip straight past that work. I can end up with something polished that sounds like me, looks like me, and may even be better than what I’d have made alone, while having surprisingly little connection to the thinking underneath it.
I don’t want to give that up. The point of working with AI, for me, isn’t to remove myself from the thinking. It’s to increase how far I can take the thinking while staying close enough to it that it remains mine.
I don’t think the answer is to romanticize the old craft. I’ve prepared enough production assets, annotated enough screens, and sat through enough handoff meetings to know that friction doesn’t magically make us wise. A lot of it was just friction.
Some of that proximity did matter. Not because making ten versions by hand was somehow better, but because it kept me inside the problem long enough to understand it. I had to notice what changed from one version to the next, figure out why something felt wrong, and work through the idea instead of simply choosing among finished options.
Taste introduces a different problem. If every model has been trained on the accumulated evidence of what people already considered good, then “make this tasteful” points backward, toward an average formed from culture that already happened.
Taste has always involved some willingness to go somewhere the evidence doesn’t fully support yet.
So what happens when thousands of us start using the same systems to “amplify” our taste? Do our individual points of view become stronger because we’re suddenly capable of expressing them at scale? Or do we slowly start performing the model’s idea of taste until we all become different versions of the same tasteful person?
I can see both futures.
This is why I don’t think design moving up the stack means designers become managers of machines while the machines do the creative work underneath them. That feels like another way of preserving the old hierarchy after the work has already changed. I think the job gets more entangled than that.
I still need to stay close enough to the work for the thinking to become mine. I need the system to carry my intent without freezing that intent in stone. I need enough distance to let the machine surprise me and enough presence to recognize when the surprise is actually better.
There are also some calls I don’t want to move away from. When being wrong has real consequences for somebody. When a decision is hard to reverse. When the business gets rewarded for something that may be bad for the person using it. When the choice says something about what we’re willing to stand behind. AI can absolutely be in those conversations, but the call still stays with us humans.
Maybe that’s the through-line I’ve been looking for here. The screen moves into a larger design surface. The artifact becomes an output of a system. More of my judgment gets encoded into that system so the work can travel farther than I can personally carry it.
Then, at the very top of the stack, I run into the same stubborn constraint again: me.
What do I think is good? What am I willing to let the system decide? Where did that judgment come from? Am I still doing enough of the work to keep it alive? What happens when my instincts are wrong, and the system is very good at multiplying them?
Those questions feel much closer to design than arguing over whether making a wireframe still counts.
The artifacts aren’t going away. Neither is craft. But I think both are becoming expressions of something more abstract that we’re increasingly responsible for shaping. What I used to make by hand is now something the system can produce, so I design the system. The better that system gets at producing its results, the more its quality depends on what I put into it.
Design is moving from the artifact to the decisions that shape it.