AI gave designers more leverage

There’s this moment when designers first get into production code. For the first week or two, it feels great. You finally fix that thing that’s been sitting on a Jira ticket for months. You close the gap between what you designed and what actually shipped. It feels like finishing a sentence you started ages ago.

Then you look up and six hours have passed. You’ve mostly been polishing stuff.

I watched a panel recently with Megan Choy, Dan Shipper, and Bradley Ziffer. They’re all at companies trying to figure out what design work should look like right now. They kept circling the same issue from different angles: designers have way more access and capability than before, and a lot of us are using it to polish things that didn’t really need it.

That stuck with me because I’ve done exactly this. And I think it’s a bigger pattern than most of us admit.

The case for letting designers into the real codebase makes sense.

• You see what users actually get.

• You fix things that never made it through handoff.

• You work with real data instead of a sandbox that’s always a bit behind.

So yes, getting into production is the right move.

But there was this unspoken assumption underneath it: that once designers had access, they’d naturally use it on the right things. That part was doing a lot of work. And it quietly fell apart for a lot of us.

One thing from the panel that stuck with me: AI can get most things to a seven out of ten pretty easily now. A rough feature can be up and running in an afternoon and it feels decent.

That should free up time. And it does. But what I keep seeing, in my own work and in what other designers describe, is that we use that extra time to push from seven to eight. Then eight to eight and a half. We polish because we can.

The gap between “I can do this” and “I should do this” gets smaller. The ticket gets done before anyone stops to ask if it was even the right one.

Dan Shipper said his engineering team actually pulled him aside and told him he was spending time on polish that wasn’t the best use of him. Most of us don’t get that kind of direct feedback. We have to catch it ourselves.

Here’s the part that’s harder to talk about.

If you’re the only thing stopping the product from looking bad, you’ve built something that doesn’t scale. A first version can match the system and be good enough without you reviewing every pixel. Some of those checks can even be automated.

That feels uncomfortable. Quality feels personal. Letting something ship without your sign off can feel like losing control.

But the designers I see handling this well aren’t doing more work. They’re getting better at choosing what deserves their full attention.

They get to seven quickly, decide if that’s enough, and move on. Or they decide it needs to be a nine and they know exactly why.

The difference is the decision is deliberate, not automatic.

I’m not going to pretend I’ve figured this out.

But a few things have helped me catch the pattern before I fall into it.

Before I pick up any task now, I do this:

1. Write down the one thing the product actually needs most. (Not the loudest ticket, but the real thing. Usually it’s a decision no one has made, or a place where users keep getting stuck.)

2. Check whether what I’m about to do connects to that.

3. If it doesn’t, ask if it even needs to happen today.

I’ve also started being more honest about what I should do myself versus what I can hand off.

The hardest part about having more capability isn't learning how to use it. It's deciding what actually deserves your full attention.

Thanks for reading :) If something in this issue resonated, please reply and tell me.

— Balint

What else I’m working on?