The dynamic on product teams shifted in early 2026 in a way I didn’t really see coming until it was already underway. Stakeholders, by which I mean PMs and engineers and the occasional founder, stopped asking designers for mockups. They started generating their own first drafts and bringing them to designers as a starting point for the conversation.

I was in a sync three Wednesdays ago where the PM opened the meeting by saying, “I had Claude make three versions of this. Which direction should we go?” Two years ago that sentence would have been a small insult, an implicit suggestion that the designer’s work could be replaced by a chatbot. In the meeting I was actually in, it was just how the meeting started. Nobody flinched. We looked at the three versions, picked apart what was working and what wasn’t, agreed on a direction, and the design work started from there.

That meeting wasn’t a one-off. I watched four more like it across two different product teams in the four weeks that followed, and at some point I stopped counting. It’s the new shape of the front half of a product cycle, and it changes what the design role looks like in ways I think are mostly good but worth being honest about. I’m a working product designer with a single vantage point, not a researcher with a survey, so if your team’s experience is different, please let me know.

The old dynamic

For most of my career, the front half of a feature looked like this. PM writes a brief. Designer reads the brief, asks clarifying questions, takes two or three days to produce a comp, brings the comp to a review meeting. Team reacts. Designer iterates, takes another day or two, brings v2. Team reacts again. By the end of the week or sometimes two, there’s a direction the team can commit to. Design work continues, engineering picks up specs, and the feature moves into production.

That cycle had a lot of friction baked in. The designer was the bottleneck not because designers are slow, but because the artifact the team needed to react to (a real-feeling visual) was something only the designer could produce. So everything queued behind their availability, their backlog, and their ability to context-switch. PMs got good at writing briefs that minimized round trips. Designers got good at producing v1s that were close enough to spark a real conversation. The whole apparatus assumed that producing a credible mockup was a hard, gated step.

It also assumed that the people in the room without design skills couldn’t really express what they had in mind. They could describe it in words, sometimes badly, and the designer’s job was partly translation. Hearing “I want it to feel more enterprise” and producing a screen that captured what the speaker actually meant by enterprise. The whole notion of the design double-diamond and most of the Nielsen Norman playbook was organized around this gap.

The new dynamic

What changed: the PM can produce a credible mockup in twenty minutes by typing a prompt at Claude Design, v0, Figma Make, or Lovable. The credibility threshold is the part that actually matters. Two years ago, when a non-designer brought a wireframe into a meeting, it usually got dismissed because the wireframe was so obviously not finished that the conversation defaulted back to “let’s wait for the designer.” The new generated comps are not finished, but they’re finished enough to function as a real reference point. They communicate intent. They show information density. They suggest a tone.

The new front half of a feature looks like this. PM writes a prompt instead of a brief. PM brings three or four generated alternatives to the meeting. Team and designer look at them together. Designer says, “this one is closest to right, here’s why, but the pattern in the second one is better for the empty state, and the information density of the third is wrong for our user.” The conversation that used to take a week starts in the first meeting. By the end of an hour, there’s a direction.

The design work that follows is still real design work. It’s not a click-through-the-options exercise. The generated alternatives almost always have something fundamentally wrong that requires actual design judgment to fix. The form fields are in the wrong order. The microcopy is glib. The error states are missing. The accessibility is sloppy. The pattern is inconsistent with three other places in the product. The designer’s job is to identify what’s wrong, decide what good looks like, and either correct the comp or, more often, write a more constrained prompt and regenerate.

But the role has shifted from producer to curator. From “make me one of these” to “tell us which of these is right and what to fix.”

It’s good.

I mean that. The producer role was always the part of the job I cared least about, and watching it move off my plate has, honestly, been a relief.

The skills that matter now

Three skills got more valuable in this shift, and they’re worth being explicit about because they’re not the skills design hiring used to optimize for.

The first is rapid evaluation. When you’re looking at five generated comps, you need to be able to say “two of these are non-starters, one is the right direction with a problem, and the other two are interesting but wrong” within about ninety seconds. That’s not a skill that comes naturally. It comes from having looked at thousands of pieces of design work and developed a fast pattern-match for what’s working and what isn’t. Designers who’ve spent years studying their own field, looking at what other companies ship on places like Mobbin and Page Flows, building a mental library of references, are great at this. Designers who’ve mostly executed on briefs without studying the broader space are slower at it, and I think the gap will widen as the year goes on.

The second is a strong opinion about information architecture and hierarchy. The generative tools are pretty good at making things look reasonable. They’re not as good at deciding what should be on the screen at all, what should be primary, what should be secondary, and what shouldn’t be there. That’s the layer where most generated work falls down. A designer who can quickly say, “this is too dense, the primary action should be the booking button, the trust signals belong below the fold, and the FAQ shouldn’t be on this page at all” is doing the part of the work the model can’t.

The third is the ability to write constraints a non-designer can understand. The new prompt is the new brief, and it has to be tight. “Make a settings page” produces garbage. “Make a settings page for a healthcare product where the primary user is a busy clinician, accessed mostly on mobile during shift transitions, where the most important controls are notification preferences and on-call status” produces something usable. Writing that prompt is design work. Teaching a PM to write that prompt themselves is meta-design work, and probably the most valuable thing a senior designer can do for their team in 2026.

The skills that matter less

What about pixel-perfect execution of an idea someone else had? It used to be a meaningful chunk of the design job. It still has a place, but the place is smaller and later in the cycle. The first 90 percent of the visual fidelity that a comp needs to function as a reference can be generated. The last 10 percent (the production-quality details, the accessibility checks, the responsive behavior, the hand-tuned spacing) is still designer work, but it’s a smaller portion of the total time.

Designers whose primary identity was “I am the person who makes things look right” are in a tougher position than designers whose primary identity was “I am the person who decides what should be on the screen and why.” Both groups have a future. The second group has a clearer one.

The mockup used to be the bottleneck. Now it’s the meeting agenda. Different artifact, different role, different skill mix.

A concrete example

I’m generalizing here, not pointing at any product I’ve actually worked on. The kind of feature where this shift is most visible is the front-end onboarding flow for a consumer health app. Account creation, eligibility check, intake questions, scheduling. The kind of flow that used to take a week of mockups, three rounds of stakeholder review, and a Loom walkthrough before engineering could even spec it out.

In the new pattern, the PM brings two or three generated versions to a kickoff meeting. The conversation that day covers, which intake questions are actually required, what order should they be in, where should we ask for payment versus where should we just collect insurance, how does the flow handle the case where eligibility comes back unclear. None of those are visual decisions. All of them are design decisions in the bigger sense. The visual layer of the comp is more or less right out of the gate, because the model knows what an onboarding flow looks like. The interesting work is everywhere else. The week of mockups doesn’t go away entirely. It compresses. There’s a day of rapid iteration to nail the pattern, then a couple of days of polish on the variants that emerged from the conversation. But the rhythm changes. The designer isn’t waiting in the queue producing the artifact the team needs to react to. The team is reacting the moment they meet, and the design work happens around the reactions.

What this means for design hiring

If I were hiring a product designer in 2026, the things I’d care about have shifted. I’d care less about portfolio polish, more about the writing in the case study. I’d care less about Figma fluency, more about the candidate’s ability to look at a generated comp and say something specific and useful within a minute. I’d care less about how many flows they’d shipped, more about how often they’d been the person who decided which way to go when the team was stuck.

That’s a different evaluation rubric than most design interviews use. The interviews will catch up. The work already has.

Jameson