The Expanding Designer

This is the post I have been most nervous to write. Parts 1 and 2 were about the shift happening around us. This one is about the shift happening inside us. What it means for our identity, our skills, our sense of purpose as designers. And if I am being honest, I have been avoiding it because I am still in the middle of it myself. I do not have a neat before-and-after story to tell. I have a messy, in-progress one. But I think that is exactly why it is worth writing. Because I suspect a lot of you are in the same messy middle.

Let me start with the thing that has been bothering me the most.

The Grief Nobody Talks About

There is a quiet grief that comes with professional change. Not the dramatic, LinkedIn-post kind. The kind that sits in the back of your chest when you realize that the version of your job you fell in love with is becoming a smaller part of what the job requires.

I fell in love with design because of the influence it gave me. You do the research, you talk to users, you understand the problem deeply enough to walk into a room of engineers and product managers with a clear point of view, and the conversation shifts. I spent years building that kind of credibility in companies that did not hand it to designers. Learning how to connect what users actually need with what the business is trying to do, and making that connection feel obvious in the product.

And now the nature of that work is changing. Understanding users, shaping how a product feels to use, making complex things feel simple, all of that is still there. Still valuable. But it is expanding into places that do not look like anything I was trained for. Invisible interactions. Decisions made by software at 3am. Trust that gets built or broken without a single screen involved.

I think a lot of design leaders are feeling this and not naming it. We talk about "upskilling" and "adapting," which are fine words. But underneath them there is often something quieter: the experience of watching your role grow faster than your confidence in the new parts of it.

If that is where you are, I just want to say: that is a completely reasonable place to be. And it does not mean you are falling behind. It means you are paying attention.

What the Job Is Becoming

Okay. Let me try to describe what I think is actually happening to the shape of our work. Not what LinkedIn thinks is happening. Not what the hype cycle says. What I am actually seeing in my own day-to-day and in the conversations I am having with designers across different companies and industries.

The job is not getting replaced. It is getting wider.

Two years ago, a typical week for me was maybe 60% hands-on product design (research, flows, design systems, shipping with engineering) and 40% the rest (stakeholder alignment, product strategy, team leadership). Today, those numbers look completely different. More of my time goes into questions that do not produce a Figma file. Questions like:

"What should the agent be allowed to do without asking?"

"When this process goes wrong at 2am, what does the user see at 8am?"

"How do we structure this data so an agent can actually use it?"

"What does this product's personality sound like when it is explaining a mistake?"

These are all design questions. They shape the experience more than any component ever will. But they do not look like the design work I was trained to do. They look like product strategy or content design or systems architecture. And that blurriness is, I think, what makes people anxious. It feels like the boundaries of "designer" are dissolving. But I think what is actually happening is that they are expanding.

The Four Directions of Expansion

Here is how I have been thinking about it. The designer's role is stretching in four directions simultaneously. You do not need to go deep in all four. But you need to be aware of all of them, and you probably need to develop real capability in at least one or two.

Direction 1: Down into the data layer

This is the one that feels most unfamiliar to product designers, and also the one I think matters most right now.

When an agent interacts with your product, it is not using your interface. It is using your data. The labels on your fields, the structure of your content model, the consistency of your API responses. If those things are messy, the agent experience is terrible, and by extension, the human experience is terrible too, because the agent is going to make bad decisions on bad data and the human is going to be the one dealing with the consequences.

You do not need to become an engineer. But you need to develop an opinion about data. You need to look at a content model and be able to say "this is confusing" or "these labels are ambiguous" or "an agent is not going to know the difference between these two fields." That used to be someone else's job. It is becoming ours too.

A practical place to start: next time you are in a design review, ask the engineer to show you the data structure behind the feature you are designing. Not the code. The model. The fields, the relationships, the labels. Start developing a feel for what "well-organized" versus "messy" looks like at that layer. You will be surprised how quickly your instincts kick in. Design thinking applies there too.

Direction 2: Into behavior design

This one is less about what the product looks like and more about how it acts. When an agent makes a decision, that decision was shaped by rules someone defined. "If the price drops below X, pause the order." "If the confidence level is below Y, ask the user." "If two data sources conflict, flag it instead of guessing."

Those rules are the product. Not the screen that displays the outcome of those rules. The rules themselves. And right now, in most organizations, those rules are being defined by product managers and engineers. Not because designers cannot do it, but because we have not claimed it yet.

I have started writing what I call "behavior specs" alongside my visual designs. They are simple documents that describe how the agent should behave in different scenarios. Not technical specs. More like personality guidelines. "In this situation, the agent should be cautious. In this situation, it can be confident. In this situation, it should stop and ask." It feels weird at first. It does not look like design. But it shapes the experience more directly than any screen I have ever shipped.

Direction 3: Into language and conversation

If the agent's primary interface with the human is language (and increasingly it is), then the quality of that language is the quality of the experience. Full stop.

This is not UX writing in the traditional sense. It is not label text and button copy. It is the full personality of an autonomous system. How it explains itself. How it admits uncertainty. How it asks for help. How it delivers bad news. How it sounds when everything is going well versus when something went wrong.

I used to think of writing as a supporting skill. Something nice to have. Now I think it might be one of the most important tools in a designer's kit. Because in a world where agents generate their own interfaces, the one thing that stays consistent is the voice. The visuals might be dynamic and temporary, but the way the system talks to you is the through-line of the whole experience.

Direction 4: Into trust and ethics

This is the direction that sounds the most abstract but might be the most consequential for our careers long-term.

Somebody needs to decide the ethics of how AI agents behave. Not in a philosophical, academic way. In a practical, "we are shipping this on Thursday" way. When should the agent act without asking? How transparent should it be about its reasoning? What does it do with sensitive information? How do we prevent it from doing something the user would find creepy even if it is technically helpful?

Right now, these decisions are often made by whoever happens to be in the room. An engineer makes a judgment call. A PM picks a default. No one thinks about it holistically. But these are experience decisions. They shape how people feel about the product. They determine whether someone trusts it or uninstalls it.

Designers are uniquely qualified for this because we have always been the people who think about how things feel from the user's perspective. We have spent our careers building the muscle of "but what does this feel like for the person on the other end?" That muscle is exactly what is needed here. We just have to apply it to a new kind of question.

What Stays the Same

I have spent most of this post talking about what is changing. I want to spend a moment on what is not. Because I think this part gets lost in the noise, and it is actually the part that matters most.

Empathy has not changed. The ability to understand how another person experiences something, to feel what they feel, to anticipate what will confuse or reassure or frustrate them. That is the same skill it has always been. The context is different. The questions are different. But the core human capacity that makes a designer a designer? That is unchanged.

Taste has not changed. Knowing the difference between "this works" and "this feels right." Being able to look at a system's behavior and say "something is off here, I cannot articulate it yet, but the user is going to feel it." That instinct took years to develop and it transfers directly to designing for AI agents. An agent that behaves in a way that feels "off" is the same kind of problem as a product experience that feels "off." The sense that detects it, that instinct you built over years of watching real users struggle with something you thought was clear, that is the same sense.

Craft has not changed. It has expanded. The medium is wider now, but the commitment to doing the work with care and intention and precision? That is still the thing that separates good work from forgettable work. Whether you are perfecting a visual system or writing a behavior spec or defining the tone of an agent's error message, the standard is the same: does this feel like someone cared?

Practical Advice (From Someone Still Figuring It Out)

I want to share some things that have helped me navigate this transition. Not because I have it figured out, but because when I was feeling the most disoriented, the thing I wanted most was someone being specific instead of vague.

Start building things, even if they are small. AI tools have made it possible for designers to prototype functional products without being full-stack engineers. I started using tools like Cursor and Lovable not to replace engineers, but to feel less helpless. To be able to say "here is what I mean" in working code instead of a static mockup. It changes the conversation. And it gives you a visceral understanding of how data, logic, and interface connect in ways that Figma alone never will.

Write agent personas alongside user personas. This sounds strange but it has genuinely changed how I think. A user persona describes a human. An agent persona describes a behavior pattern. "This agent is cautious. It checks in before high-stakes actions. It speaks in plain language. It admits when it is unsure." Writing those down forces you to make the agent's personality a deliberate choice instead of an accidental one.

Sit in on engineering conversations you would normally skip. Not all of them. But the ones about data models, about API design, about how the agent layer connects to the rest of the system. You will not understand everything. That is fine. You are building context. And context is what lets you have an opinion about the invisible layer of the product instead of deferring to whoever else happens to be in the room.

Practice writing the way the agent talks. Open a document and write the agent's half of twenty different conversations. The routine ones. The tricky ones. The failure ones. What does it say when everything goes right? What does it say when it is confused? What does it say when it made a mistake and the user lost money? This exercise is weirdly powerful. It forces you to think about edge cases that never show up in a wireframe.

Give yourself permission to be bad at new things. I cannot stress this enough. You are going to feel clumsy with data models. Your behavior specs are going to be rough at first. Your first attempt at defining an agent's tone will probably sound robotic or try-hard. That is fine. That is what the beginning of learning always feels like. The discomfort is not a sign that you are in the wrong place. It is a sign that you are growing.

The Question I Keep Asking Myself

I want to end this series where I started it. With honesty.

I do not know exactly what "designer" is going to mean in five years. I do not think anyone does, no matter how confidently they say it on a podcast. The role is in motion. The edges are blurry. The job description has not caught up to the reality.

But here is the question I keep asking myself, and it is the one that keeps me grounded when the uncertainty gets loud:

"Am I still the person who cares about how this feels for the human on the other end?"

If yes, I am still a designer. Even if the deliverable is a behavior spec instead of a Figma file. Even if the surface is a data model instead of a screen. Even if the "interface" is a single sentence the agent says to a nervous user at 8am.

The medium changed. The empathy did not. And I think if you hold onto that, you can navigate the rest.

When I started this series, I said I was not a writer. I am still not sure I am. But I know this: writing it helped me think more clearly about what is happening. And the conversations it started made me feel less alone in the uncertainty.

That is all I was hoping for. If it did even a fraction of the same for you, then it was worth the discomfort of clicking publish.

We are expanding. The ground is unfamiliar. And we are going to figure this out the same way we always have: by caring deeply about the people we design for, even when "people" now includes software acting on their behalf.

Thank you for reading all three parts. I mean that. And if you want to keep this conversation going, you know where to find me.