The Quiet Death of the 'Just Designer' Role

I merged my first PR directly into the frontend repo this month. It was, I want to stress, not a flashy PR. A few CSS tweaks, some component scaffolding, a couple of prop names tidied up. It wouldn’t catch anyone’s eye on a commit log. But I felt weird about it for a week afterward, in a way that told me something had actually shifted.

The shift is this. The “just designer” role, the one where you draw interfaces in one tool and hand them to engineers who build them in another, is quietly dying. It’s not being killed by AI, or by a tool, or by a policy. It’s being ended by the accumulating cost of not knowing what’s on the other side of the handoff.

01. The PR, and why it felt big

The PR itself was almost boring. I adjusted the spacing tokens on a card component to match the updated system values. I renamed a prop from isActive to selected to match our convention for single-select UI. I fixed a hover state that shipped with a broken transition. Twenty lines, maybe.

What made it feel big was the realization that, five years ago, I would have written a Figma comment, pinged a frontend engineer, explained what I wanted, answered their follow-up questions, waited for the PR, reviewed it, asked for one more change, and closed the loop. That whole loop, for twenty lines, would have taken a week of calendar time and burned roughly two hours of someone else’s focus.

This time I just opened the code, made the change, pushed the branch, requested a review, and moved on. The engineer who reviewed it sent a thumbs-up and a one-liner suggestion on naming. That was it. The work was smaller than the conversation it would have required.

That disparity, between the size of the change and the size of the communication it used to demand, is the whole story. Every small fix I can make directly is a conversation I don’t have to have. Every conversation I don’t have to have is bandwidth returned to my engineering partners for work I genuinely can’t do.

02. Framer and real React components

The other thing that changed in the last year is how I prototype.

I’ve completely stopped using static Figma frames for complex interactions. For anything involving state, data, real responsive behavior, or a flow with more than a couple of branches, I build the prototype in Framer with real React components. The difference is not subtle.

A static frame is a picture of an interaction. A Framer prototype, at the level I’m building them now, is the interaction. When a user asks “what happens if I type three letters and hit enter,” I don’t say “let me mock that.” I say “try it.” When a product manager asks how the sort toggles feel together, they can actually feel them. The loop between “question about the design” and “experience of the design” shortens to zero.

There’s a cost, of course. Framer prototypes take longer to build than Figma frames, because you’re really building a small app. The trade becomes worth it the moment anyone asks a follow-up question, because in a static world, every follow-up is new mock work, and in a component world, the follow-up is usually just poking the existing thing.

I also find that the prototypes tend to survive longer. A static mockup gets archived. A component-based prototype often becomes the first draft of the real implementation, especially when the component library the prototype uses is the same one the product is built on. The boundary between “prototype” and “production” gets porous, which is either exciting or terrifying depending on how you feel about porous boundaries.

03. The continuous spectrum

For a long time I thought of UX, UI, and frontend as three adjacent disciplines. You could specialize in one and borrow from the others when you needed to. The borders were real. The handoffs between borders were real.

I don’t believe that anymore.

What I’ve come to believe, after a year of working across all three, is that UX, UI, and frontend are a continuous spectrum of the same underlying work: deciding what the product should do, deciding how it should look and behave, and getting that decision into a form the browser can render. The idea that those are three jobs was an artifact of the tools we had, not a truth about the work.

Figma used to force a boundary by being incapable of rendering real code. Zeplin used to force a boundary by being the place specs lived. Storybook used to force a boundary by being “the engineer’s thing.” In 2026, Figma reads tokens from code, Dev Mode renders real component references, and my prototyping tool outputs React. The boundaries were tool boundaries, and the tools got better.

What’s left, after the tool-imposed boundaries dissolve, is just the work. Define the problem, shape the solution, build it. Different people still specialize in different slices. But the slices overlap now, thickly, and the gaps between them are where the worst bugs used to live.

04. The rectangle versus the component

I want to put a concrete version of the shift on the page, because it’s easy to wave hands about “thinking in code” and harder to show what it looks like in practice.

Two years ago, when I designed a card, I drew a rectangle. I set a fill, rounded the corners, added a drop shadow, placed some text inside, auto-layouted the padding, and gave it a name in the layers panel. The output was a picture of a card. Communicating that picture to an engineer meant screenshots, spec callouts, and a lot of implicit assumptions.

Now, when I design a card, I write something like this in the prototype repo:

type CardProps = {
  title: string;
  description?: string;
  href?: string;
  children?: React.ReactNode;
};

export function Card({ title, description, href, children }: CardProps) {
  const Wrapper = href ? "a" : "div";
  return (
    <Wrapper
      href={href}
      className="block rounded-lg border border-slate-200 bg-white p-5 transition hover:border-slate-300 hover:shadow-sm"
    >
      <h3 className="text-base font-semibold text-slate-900">{title}</h3>
      {description && (
        <p className="mt-1 text-sm text-slate-600">{description}</p>
      )}
      {children && <div className="mt-4">{children}</div>}
    </Wrapper>
  );
}

Notice the things this forces me to confront that the rectangle didn’t. Is the card interactive? If so, is it a link or a button, and what does each imply for focus and keyboard behavior? What’s optional? What’s a child? How does the spacing compose when description and children are both present? What does hover actually do?

The rectangle answered none of those questions. The component answers all of them, or at least forces me to answer them in writing. That’s not extra work, that’s the work, and it was being invisibly dumped on engineering every time I pretended the rectangle was a design.

05. What knowing how the DOM works actually buys you

The phrase I keep hearing in our industry is “designers who code.” It’s framed as a bonus, a multiplier, something nice to have. I don’t think that framing is accurate anymore. Here’s what knowing how the DOM works actually buys you, in 2026.

You stop designing interactions that browsers can’t natively produce. You stop suggesting layouts that fight the box model. You understand why “just put a modal here” isn’t the same as “just put a modal here.” You can read a component’s source and know, in two seconds, whether your proposed change is a one-line tweak or a week of refactor. You can distinguish between a system limitation and an engineering preference, which, uncomfortably, is sometimes the same distinction phrased differently.

Without that knowledge, you are, to use a phrase I now use too much, designing blind. You’re making decisions about a medium you don’t understand. You’re guessing at cost. Your engineering partners quietly absorb the cost of those guesses and smile at you in standups. Eventually they leave for teams where the designer didn’t cost them three extra PRs per quarter.

I don’t think every designer needs to ship production code. I do think every designer needs to understand the medium well enough that their proposals are legible as implementation, not just as pictures. That’s a different bar than “designer who codes.” It’s closer to “designer who is fluent in the material.”

06. The new baseline

The unicorn used to be the designer who could code. The expectation now is that you understand the runtime you’re designing for, well enough to make informed trade-offs about it.

That sounds heavier than it is. It doesn’t mean learning React from scratch. It doesn’t mean writing production code every day. It means knowing what the browser does with your layouts, what a component is, what state is, what a prop is, what the handoff actually consists of once the “handoff” itself is gone. The same way a print designer eventually has to understand bleeds and paper stock, the digital designer has to understand the DOM.

The trend line is clear to me now. The barrier between “designs the thing” and “ships the thing” is going to keep eroding, because every tool release is eroding it. Figma, Framer, v0, Storybook, the whole stack is converging on a shared artifact that is simultaneously a design and an implementation. The designers who thrive in that world will not be the ones with the best taste, though taste still matters. They’ll be the ones who can operate on the shared artifact without losing the taste.

---

07. Closing

My first merged PR is going to look quaint in a year. That’s fine. The point isn’t the PR, it’s that the path from “I notice a problem” to “I fix the problem” got short enough that I walked it without thinking.

The “just designer” role isn’t dead because designers are being replaced. It’s dead because the job grew underneath it. The work we call design now includes more of the material reality of the product than it used to, and I’d rather meet that reality than pretend the old boundary is still there.

If you’re a designer reading this and the thought of opening a pull request makes you twitchy, I’ll say what I wish someone had said to me a year ago. Start small. Change a token. Fix a hover. Rename a prop. The first PR isn’t the point. The point is the quiet realization, a month later, that the wall you used to throw designs over is no longer there, and the reason nobody told you is that everyone else had already walked through.