The Shifting Role of a Product Designer
This conversation is happening in design teams everywhere right now. Someone shares an article about AI replacing designers and someone else shares a counter-article about why it won't. And then everyone goes back to their Figma files and the conversation dissolves without anyone actually answering a more useful question: if AI isn't replacing designers, what exactly is it doing to the role?
I've spent the last year trying to answer that question — not theoretically, but practically. I have had countless conversations with my team, gauging where we think the industry is going in response to AI and building our predictions into a framework to change how we work so that we can be at the forefront of this change. What I've landed on isn't a job description. It's more like a map of how the role is shifting, and what it takes to move with it rather than against it.
Product design has always had an identity problem. The role goes by more names than almost any other in the industry — UX designer, UI designer, product designer, interaction designer, experience designer — and behind each title is potentially a slightly different set of expectations, a different scope of work, a different definition of what success looks like. Some designers spend months on a single project whereas others dream of having more than a week. Some are deep in research for months before they ever touch Figma while others are deep in pixel precision without any user research to back them up. Most designers are somewhere on a spectrum, without a clear map of where exactly the 'prime candidate' lands.
What we used to measure
The traditional design career ladder was built around craft and output. How polished were your mocks? How comprehensive were the variants you account for? How many screens did you own? How well did you handle feedback? Could you run a design review without it falling apart?
These weren't bad things to measure. They were genuinely hard, and getting them right took real skill and practice. But they were also, in the language of career ladders, the baseline. The things you were expected to do. The "nice to haves" — the things that appeared further up the ladder, the things that separated a good designer from a great one — were things like strategic thinking, cross-functional influence, outcome ownership, the ability to shape a product direction rather than just execute on one that had already been set.
Those things were aspirational. They were what you were building toward. Most designers spent years trying to earn the kind of organizational trust that would let them operate at that level.
AI has inverted this entirely.
Execution is no longer the hard part. AI has made it possible to generate mocks faster, explore more directions in less time, produce documentation that would have taken days in hours. The craft floor has risen — which sounds like good news, and in some ways it is — but it also means that craft alone is no longer a differentiator. It's table stakes. The things that used to live at the top of the career ladder, the strategic and cross-functional capabilities that took years to earn access to, are now the primary measure of whether a designer is operating at the level the role demands.
The nice to haves became the must haves. And that changes everything about how we define the role.
This isn't a tooling shift
The easiest and least accurate way to think about AI in design is as a set of new tools. Faster prototyping. Smarter search. Better copy suggestions. If that's the frame you're using, the prescription is simple: learn the tools, keep doing what you were doing, move on.
But that frame misses what's actually happening. AI isn't just adding capabilities and efficiency to the role of product designer — it's rewriting what the role is responsible for. The scope is expanding upstream, into strategy and problem definition. Downstream, into implementation and outcomes. And sideways, into engineering feasibility, data analysis, and cross-functional decision-making that designers were generally not expected to own.
The biggest shift isn't that designers need to use AI. It's that AI has removed the excuse to stay narrow. Things that were previously too time-consuming, too complex, or simply out of reach, now are. Which means the question of whether to reach for them is no longer about time capacity. It's about whether we're willing to redefine what we're here to do.
The four pillars
When I started building a framework for what this new version of the role looks like, I kept running into the same problem: most of what I was reading described skills. Use AI for rapid prototyping. Learn to read data. Understand the codebase. These are real and important, but they're capabilities — they don't tell you what kind of designer you're trying to become, or how to make decisions when the tools aren't enough.
So I started one level up. What are the orientations — the ways of thinking — that an AI product designer needs to hold?
For a long time, the design industry had one answer to that question: user-centered design. And look, it wasn't wrong. But it always felt a little like a chef announcing that their job is about food. Of course it is. Centering the user was never a philosophy — it was the minimum requirement. It told you who to design for, but nothing about how to think about strategy, or engineering, or organizational influence, or outcomes. It was a single pillar holding up a role that was always bigger than it looked.
The AI-era designer needs more to stand on. I landed on four pillars:
Systems thinking. This one isn't new — it's been on design career ladders for years, typically showing up somewhere around the senior level as something you were expected to grow into. Junior and mid-level designers were generally given a smaller world to operate in: own this flow, learn these patterns, get good at this pod. Systems thinking was the reward for having paid enough dues that someone trusted you to see the bigger picture.
What's changed is that the expectation has moved down the ladder. The AI-era designer — at any level — is responsible for how their work behaves over time, at scale, and across the organization. A component built today might touch dozens of product surfaces in ways you couldn't acurately predict. A pattern established in one pod might propagate across the entire platform. The siloed world that used to be a reasonable starting point is now a liability. Systems thinking isn't something you earn access to anymore, it's something you're expected to bring from day one.
And for the first time, we actually have the tools to do it. Previously, understanding the reach of a component meant tracking down an engineer and hoping they had the context to answer you — which, depending on their sprint load, could mean waiting days for an answer that might still be incomplete. Now you can point an AI tool at the repo and ask whether that component has been used in more than one place, what surfaces it touches, and what would break if it changed. The visibility that used to require institutional knowledge and a favor from engineering is now something any designer can access on their own. That's what gives this pillar real teeth — not just the expectation, but the agency to actually meet it.
Judgement. AI can generate acceptable designs endlessly. Which sounds like a good thing until you realize what "acceptable" actually means — close enough to not be obviously wrong, but not necessarily right.
If you're a designer who cares about the craft details, you already know what I'm talking about. I have a designer whose eye literally twitches at a margin set to 14px. Not because he's being OCD about it — but because he understands that spacing systems exist for a reason, and 14 isn't an integer of 4. He'll argue, correctly, that it should be 12 or 16. And even then, 12 would still bother him, because the universally accepted pattern is 4, 8, 16, 24, 32 and so on. You can write all of that into your documentation, feed it into your prompts, establish every rule you can think of — and the tool will still miss things sometimes. Just like people do.
But judgement in the AI era isn't just about catching spacing errors. It's about evaluating things like whether the tool made the right hierarchy decisions, whether the primary action is actually primary or whether the information architecture it chose serves the user or just looks plausible. A professor I had in design school said something I've never forgotten: your first idea is almost never your best. I've found that to be just as true of AI-generated designs as it is of human ones. They're useful — genuinely useful — for rapid prototyping, for getting buy-in on a concept, for exploring directions quickly. But I have never seen one come out the other end with every T crossed and every I dotted, ready to hand to engineering without a designer's eye on it first.
That's the new center of designer value — not the ability to produce, but the ability to discern. In an environment where execution is easy, judgement is the thing that's actually scarce. And it turns out that judgement is exactly the thing AI can't generate.
Influence. For a long time, the design team's main stage of influence was in a stakeholder session where they walked people through a prototype and hoped the right questions came up. And if you've run enough of those sessions, you know exactly how they go. If you're lucky enough to not get crickets, you have two or three vocal people in the room — the ones who always have questions, who generate conversation, who make the session feel alive. I still remember those people by name, even a decade later. They made having influence easy.
But they were never the whole room. The rest of the stakeholders — the ones who listened more than they spoke, who nodded along and left without saying much — those people were just as important, and much harder to reach. What I've learned is that the way to reach them is to come prepared with narrative, not just mocks. To walk in already thinking about the questions the implementation team might have during a specific flow. To say out loud: "We've noticed lately that customers are flagging how difficult the date dropdown is for older users, so we made this call intentionally." That kind of preparation draws out the people who would have otherwise stayed silent, and it signals to everyone in the room that design is listening and has done their due diligence and that our judgement can be trusted.
And for most designers, that was the extent of it. The primary place of influence were stakeholder sessions. But influence goes beyond the review session. It is shaping roadmaps, reframing problems with PMs, making the case to engineering for why a decision mattered — that was, again, senior territory.
With AI influencing every aspect of the role, stakeholder sessions now just become a single avenue that designers can leverage. Designers can now synthesizes user feedback into a problem statement that reshapes what a PM thought the solution needed to be. They can show up in roadmap conversations and make a compelling case for why a particular problem needs to move up the priority list — or pick up a UI bug fix ticket themselves rather than waiting for engineering to get to it. It shows up in engineering relationships, when a designer can articulate not just what they designed but why — connecting a decision back to the systems thinking and user insight behind it in a way that makes the engineering team feel like collaborators rather than implementers.
We are no longer a mock-making factory. The AI-era designer has to be able to articulate why a considered design decision is worth more than a cheaper alternative or an AI-generated shortcut — in the session room, in the planning doc, in the Slack thread, and in the PR comment. That's influence as a core function of the role. And the designers who are best at it aren't the ones with the most charisma. They're the ones who show up most prepared.
Champion for the user. This is the one pillar that was never missing from the role — it's the user-centered design principle that's been at the foundation of everything we do since before most of us entered the field. And it isn't going anywhere. In the same way ingredients will never stop being central to what a chef does, advocating for the user will never stop being central to what a designer does.
What's changed is how equipped we are to do it. For most of design's history, championing the user meant synthesizing what you'd observed in research sessions and translating it into a recommendation that was, if we're honest, at least partially subjective. You'd watched twenty user interviews, you'd formed a point of view, and you'd present it with as much conviction as you could muster and hope the room trusted your read. That process worked — designers with good instincts still made good calls — but it was easy to dismiss. Someone could always say "that's just your opinion" and the conversation would stall.
The designers who could push past that were the ones with years of accumulated domain knowledge — the kind of deep, pattern-recognized intuition that comes from having seen the same problem surface in fifteen different products across a decade of work. That gut instinct was real and it was founded, but it was almost impossible to use as proof. It was also, not coincidentally, one of the things that made seniority and industry background matter so much in a job interview. Experience was the closest thing designers had to evidence.
AI changes the equation significantly. Feeding twenty research sessions through an AI tool and having it surface patterns — by demographics, by phrasing, by frequency — used to take the better part of a week. Now it takes hours. The qualitative becomes quantifiable. The subjective gets backed by signal. All done quickly and efficiently to top it off! And suddenly the designer isn't just advocating for the user — they're arriving with evidence. The gut instinct that used to live only in the heads of the most experienced people in the room can now be validated, challenged, or confirmed in real time, even for those start up companies that have more ideas and dreams that the work week can fit.
This is the pillar that gives the others their backbone. It's what makes judgement credible, influence persuasive, and systems thinking purposeful. It's also the one that opens doors that don't always point back to monetary ROI — the decisions that are harder to justify on a spreadsheet but matter enormously to the people using the product every day. AI doesn't make those decisions for us. But it gives us the ammunition to make them stick.
These four pillars aren't a checklist. They're an orientation. They describe how an AI product designer thinks, not just what they do. Everything else — the tools, the workflows, the specific skills — sits in service of these.
The skills that put the pillars into practice
If the pillars describe the mindset, the skills describe the capabilities. And to be clear: these aren't the only things an AI designer does. They're the foundational buckets that everything else maps back to.
Technical fluency means understanding the system you're designing within — not just the interface, but the codebase, the components, the constraints. What's easy to implement versus hard, and the technical why behind it.
None of that is entirely new. Good designers have always tried to understand the technical context they were working in — it made for better decisions, fewer impossible handoffs, and more credible conversations with engineering. But understanding it used to require either years of accumulated knowledge or the willingness to ask someone else to explain it to you. Which meant adding to someone's already full plate, waiting for a window in their schedule, and hoping the answer you got was complete enough to actually move forward with. The knowledge existed. The access to it was the bottleneck.
That bottleneck is largely gone. A designer can now point an AI tool at a codebase and ask whether a component exists, how widely it's used, what it would take to adjust it, or what the likely implementation complexity of a new pattern might be — and get a meaningful answer without pulling an engineer away from their work. The agency to find those answers yourself, on your own timeline, changes the texture of the role in ways that are hard to overstate. Designers are no longer waiting to be informed. We're expected to be informed — and now we actually can be.
Data interpretation is less a skill and more a perspective shift — and it's one that requires being intentional in a way that the old design process rarely demanded.
In the linear model, design's job was largely finished by the time something shipped. You handed off the work, engineering built it, and whatever happened next was someone else's problem to measure. And for most of design's history, that someone else was the PM. Tracking engagement, interpreting behavior data, defining what success looked like in measurable terms — that lived on their shoulders, not ours. Designers got looped back in when something was clearly broken, when user complaints reached a threshold that warranted a revisit, or when a new project kicked off and the old work became context. We were user experience designers who, more often than not, never actually looked at how users experienced what we shipped. Which, when you say it out loud, sounds a little absurd.
The AI-era designer has to define success differently, and earlier. Before the design work starts, not after it ships. What does good actually look like for this feature — in numbers, in behavior, in something that Pendo or a data tool can surface six weeks after launch? What are the signals that would tell you it worked, and what would tell you it didn't? That intentionality changes how you design, because you're no longer just solving for a state — you're solving for an outcome you've committed to measuring.
It also changes what you're reading once the work is live. Not just "did users engage with it" but why, and where, and what they did instead when they didn't. What users actually do versus what they say they do. Where they drop off, what they ignore, what pulls their attention somewhere you didn't intend. The designer who can read those signals and translate them into the next decision is far more valuable than one who can only respond to signals someone else has already interpreted and packaged for them. This is where the role bleeds into territory it should have always occupied — and AI makes it possible to actually stay there.
Assisted coding is the one that changes the most about how design and engineering relate to each other. AI has made it possible for designers to generate real UI code, build functional prototypes that aren't just static mocks, and contribute directly to implementation. The line between design and engineering is blurring — and designers who are comfortable operating closer to that line are able to have fundamentally different conversations with the engineers they work with. The telephone game that used to define the handoff starts to disappear when the designer is already in the code.
Rapid prototype exploration used to be constrained by time. How many directions could you explore before the deadline? AI has largely dissolved that constraint. Dozens of UX directions in minutes. Instant variations of flows, copy, and layouts. The cost of exploring ideas has collapsed — which shifts the value from generating ideas to evaluating them. The best AI-era designers aren't the ones who produce the most. They're the ones who can filter, refine, and recognize what actually works.
But there's a tension here that's worth naming honestly. Rapid prototyping isn't exclusive to designers anymore. PMs, engineers, and stakeholders are spinning up AI-generated concepts and mockups on their own — and some of them are walking into rooms for multi-million dollar deals with those prototypes design has never seen and treating them as finished thinking. It has happened. A direction gets momentum before design has ever seen it, and suddenly you're not shaping the solution, you're reacting to one that's already half-decided.
This is where influence and rapid prototype exploration intersect. The answer isn't to slow everyone else down or to gatekeep the tools. It's to make sure design has enough presence in the process that we're in the room — or at least in the loop — before something gains traction it shouldn't. That means having the relationships, the processes, and the visibility to jump in where we see fit. Not as a checkpoint, but as a collaborator who gets there early enough to actually shape the direction. Designers who have built that kind of influence don't worry about being bypassed by a PM with Claude. They're already part of the conversation.
Facilitation ill needs to guide the room toward the right decision — and for a long time, that someone was rarely the designer.
We've all been in a stakeholder session when a difficult question lands and the instinct is to deflect. "Uh — [PM name], do you want to take that one?" That moment — and most of us have lived it — is a signal that the designer in the room isn't yet operating as a facilitator. They're operating as a presenter. And there's a meaningful difference.
Good facilitation comes from intimate knowledge of all the working pieces, and from understanding what information is most valuable to who you're speaking with. If you're in front of the CEO, the filter is the business — how does this decision affect growth, risk, or competitive position? If you're talking to someone on the sales team, the same information needs to be translated into how this shapes the conversation they're having with their customers. The content doesn't change. The frame does. And knowing how to shift that frame — in real time, without a script — is what separates a designer who presents from a designer who facilitates.
It's also about knowing enough to ask the right questions before anyone else does. Walking into a session having already anticipated what the engineering lead is going to push back on, or what the PM is going to need reassurance about, or what the executive is going to need translated into business terms — that preparation is what makes facilitation look effortless from the outside. AI can help with this too: using it live in working sessions to pull up data, generate options on the fly, or pressure-test a direction in real time changes what's possible in the room. Designers are not just makers. They're facilitators of decision-making. And facilitation, at its best, looks a lot like leadership.
Stewardship is where everything else comes together. It's the skill that only works if the others are already in place — you can't measure success if you haven't defined it upfront with data interpretation, can't understand what broke if you don't have technical fluency. Stewardship is the combination and extension of all of it, applied to the question that design has historically been hard pressed (at least in the start-up worlds that I have lived in) to answer: did this actually work?
For some, that question wasn't really ours to answer. By the time something shipped, we had moved on. The design had happened weeks or months ago, success was measured in someone else's dashboard, and tracing impact back to a design decision was more archaeology than accountability. We were too far removed from the outcome to own it.
That distance is closing. And with it comes something that feels genuinely new — agency. We are no longer operating in a bubble, handing work over a wall and hoping it lands. The AI-era designer can stay close to the outcome, track how real users interact with what was built, and make the case for what to do next based on actual evidence rather than intuition or proximity to the loudest voice in the room. All while being efficient with your time.
What that agency makes possible is exciting. It means designers can build the tools and systems to make their own impact legible — not just to themselves, but to the business. An internal tool that grades the health of your primary workflows. A way to connect design decisions to engagement metrics, to retention, to the numbers that leadership actually cares about. The kind of visibility that lets a design team walk into a conversation with the CEO and show, not just vaguely say, what their work has moved. That's not a nice-to-have. That's what it looks like when design stops being a service function and starts being a strategic one.
The workflow that reflects all of this
The traditional design process was linear by design. Product defined the problem. Design discovered the solution. Engineering built it. Someone checked if it worked (usually too late to do much about it in order to meet deadlines). Each phase had a clear owner and a clear handoff point. In a slower product environment, that structure made sense.
It doesn't anymore.
The process I've watched emerge — on my own team and in the broader industry — doesn't look like a pipeline. It looks more like a loop with four stages that overlap, feed into each other, and don't always happen in order.
Behavioral data, synthesis, and what success will mean — before a frame exists.
The cost of ideas collapses. The bottleneck moves to choosing between them.
Handoffs that include pull requests, not just files.
"Did it work?" stops being rhetorical and starts being answerable.
Understanding is about getting close to the problem before touching a frame. Gathering behavioral data. Synthesizing user feedback. Defining what success actually looks like before anyone has started designing. AI compresses this phase significantly — research that used to take days can happen in hours — but it doesn't replace the judgment required to know which signals matter.
Explore is where the cost collapse of AI does its most visible work. Rapid concepts. Instant variations. Pressure-testing directions before committing to any of them. The key shift here is that exploration is no longer constrained by execution time — which means the bottleneck moves from "how many ideas can we generate" to "how do we choose between them."
Build is where the designer's relationship with engineering changes most visibly. Figma designs alongside front-end code. Components built and merged before an engineering sprint starts. Handoffs that include pull requests, not just files. The designer who shows up to Build with something already constructed — not just imagined — changes the nature of the collaboration. And the translation problem that plagued the old handoff model starts to solve itself.
Measure is the stage that closes the loop. Real user behavior post-launch. AI-assisted data analysis. Findings fed directly back into Understand, so the next cycle starts with more signal than the last one. This is where stewardship becomes concrete — where "did it work?" stops being a rhetorical question and starts being an answerable one.
What this process makes possible that the old one didn't is flexibility. The process fits the problem, not the other way around. Some things take hours. Some take weeks. A designer can enter at any stage, push something forward, and hand it off — or carry it through to the end.
But here's what's worth sitting with: the four stages themselves aren't that different from what product teams have always done. Understand the problem, explore solutions, build something, measure whether it worked — that's not a new idea. What's actually changing is who does what, and when.
Any of these four stages can now be meaningfully executed by a designer, a PM, or an engineer — depending on the problem, the team, and what's already been set up to support them. A PM who has strong user research skills might lead Understanding. An engineer who's been given the right component library and documentation might handle significant portions of Build without waiting for design to hand something over. A designer might carry a feature all the way from Explore through to the first round of Measure data. The rigidity isn't just in the sequence — it's in the assumption that each stage belongs to a specific role. That assumption is dissolving.
What makes this work at scale is intentionality. When an organization invests in the right skills, documentation, and AI-assisted tooling, the gaps that used to require a handoff can be filled without one. Teams can move more autonomously, more fluidly, and with more consistency — because the system has been set up to carry the knowledge that used to live only in a person's head. The process becomes less about who owns which stage and more about who is best positioned to move it forward right now.
Where this is heading
The title that seems to sit at the intersection of all three is something along the lines of a Full Stack Product Engineer — someone whose scope genuinely spans the full lifecycle of a product decision, from understanding the problem through to design, building and measuring whether the solution actually worked. It's a compelling idea. But let's be honest about what it actually requires.
Think about the best PM you've ever worked with. There was a level of critical thinking, organization, and stakeholder management that you genuinely admired — the way they could hold a roadmap together while fielding competing priorities from every direction. Now think about the engineers you've wished you could take with you when you changed jobs. The ones with deep technical knowledge and a creative approach to problem solving that made collaboration feel like a genuine partnership rather than a handoff. And think about the designers you've aspired to be — the ones with a visual sensibility and an almost frustrating ability to turn messy, ugly problems into something elegant. Finding one person who is truly exceptional at all three of those things isn't just rare. It's a needle-in-a-haystack situation.
The more realistic near-term picture isn't a world full of Product Engineer unicorns. It's a world where converging two of the three starts to become the expectation. PMs who design. Engineers who design.
But designers — I'd argue — are actually the most naturally positioned to reach for all three.
Here's why. The PM work is already so ingrained in how designers think that most of us are more familiar with it than we give ourselves credit for. Understanding the problem, advocating for the user, shaping direction, making the case for prioritization — we've been doing that work for years, just at a smaller scope than a PM. It's a muscle we've already been using, it is just a muscle that needs strengthening. Even a world-class sprinter gets winded running four miles if they've never done it before. That doesn't mean they can't do it. It means they need to train differently.
The coding side is newer territory, but AI has already changed what's possible there. Designers are shipping front-end code. Component libraries are being built and maintained by design teams. That muscle is being worked in real time, on real products. It takes time and it takes discipline. Even though AI coding is getting better and more reliable every day, you can't just accept whatever AI outputs without developing the judgement to evaluate it — but the path is clearer than it's ever been.
The hardest part for designers reaching toward becoming a Product Engineer unicorn isn't the PM work or even the front-end code. It's the backend — the deep domain knowledge, the systems architecture, the parts of engineering that aren't learned by reading a codebase with an AI tool. That part will take longer, and it's worth being honest that not every designer will get there.
But the potential ahead of us is real and that future is exciting.
So will you start the shift yourself? If you do, I think you are setting yourself up for a successful career in a world where others are concerned that our place in the world is dissolving.