Mocks Are Optional. Taste Isn't.

tl;dr When anyone can spin up a screen, the screen stops being the differentiator. Taste, a solid design system, and the discipline to productize raw R&D are what’s left. They matter more now, not less.

I spent the last two days interviewing product designers, and I kept hearing myself say the same things. By the end I figured I should write them down.

1. Every job description is blurring

PMs are designing. Designers are shipping PRs. Backend engineers are building front-ends. ML engineers are vibe-coding UI that actually works.

A few years ago I could write an onboarding doc for a new designer: here’s how we work. Today the honest version is: here are five ways, pick what fits, and expect it to change next month.

2. That makes design more valuable, not less

When anyone can spin up a screen, the screen isn’t the differentiator. Taste is.

Taste is years of usability calls. It’s sweating the animation, the loading state, the edge case nobody asked about. A model doesn’t hand you that.

3. Mocks are optional now. A design system isn’t.

On my team, I’m the only one who opens Figma. Devs don’t wait for mocks. We describe the problem, they build against the system, and I review in the PR.

The design system is what makes that speed safe.

A design system only gets you so far, though. It buys you consistency, not usability. That’s why I put my effort at both ends of the build.

Before the build, I don’t go straight to code. I use several different tools to get different perspectives and different flavors of the same problem, then pull the best of it together. A quick PRD is fine when you’re adding a feature on top of something that exists. When you’re adding something much bigger, treat it as bigger than it looks and take the extra step.

At the end, I run a final pass. It’s a skill I literally call final. It leans on a whole set of other skills, and each one gets its own agent that looks at exactly one thing: usability rules, design system usage, and so on. That’s where the standards actually get enforced. Done well, it’s portable. You can grab someone else’s vibe-coded work, point your skills at it and say run this over that.

That’s the kind of work I’d rather spend my time on than reviewing pixels one PR at a time.

4. The hardest work right now is productizing R&D

Someone brilliant builds something in an afternoon. It works. It doesn’t feel right.

Closing that gap is the job. It’s rarely a build problem. It’s a design call about what to cut, what to explain and what to make obvious. One reader described taking an automation product from thirty-plus setup decisions down to three required inputs. Going from thirty to three is design work, not build work.

5. The interface still closes the deal

Even if half your customers end up using you through an API or MCP, you won’t close without a top-shelf interface. You can’t demo an endpoint.

6. Going agentic doesn’t lower the bar for the UI

Even when a workflow runs 100% through MCP and works perfectly, the UI deserves the same level of craft. Humans are still in the loop. Make sure both paths work, and that both feel great.

Everyone is moving out of their lane

The pushback I hear most is stay in your lane. Developers say it about designers writing code, and others say it about anyone using AI outside their specialty.

I don’t agree. Everyone is moving outside their lane, and AI is helping us do it. We’re all graphic designers now. We’re all product managers. What I’m seeing is that we’re all doing better work for it, and the magic happens when we collaborate. The teams running into the most problems are the ones that aren’t collaborating and are only using AI.

One reader put a good frame on it: the shift isn’t from “ship fast” to “think slow.” It’s knowing where to slow down so you can move faster. Slow down on the outcome and the system. Go fast on everything downstream of that.

What’s shifted most on your team?