When designers push to production

Not long ago, the design team I work with started pushing code to production as a standard practice. I want to be clear about what that means, because it is easy to misread it. This is not about prototyping or user testing. This is about code that lives in the product. Real components, real features, shipped.

We had already been using vibe coding for a while to explore ideas, run user testing, and quickly iterate. That was valuable. But this is a different conversation.

The problem we were trying to solve

Handoff friction. Planning cycles that ran too long. Prototypes that looked good in Figma but needed two or three rounds with developers before everyone was aligned on what we were actually building.

We lost a lot of time in this (even more in certain moments, when alignment across teams was harder or priorities shifted mid-sprint). A significant part of that time was spent on visual and interaction details that designers should own end-to-end.

What we actually did

Before drawing a single process or choosing a tool, I spent time understanding what would concern people about this change. Not just friction. Fear.

For management, the concern was scope. The worry was that we would start touching areas of the codebase none of us fully understood, back-end logic, security, architecture, etc. Things that had nothing to do with what we were trying to do. So the first real work was a conversation about what area we were going to touch, and what we were not. Defining that clearly made everything else easier.

For the design team, the message from my side was the opposite of restrictive. Do not feel limited by time anymore. We now have the control and the time to take full ownership of the visual and interaction layer. Move things to production when they are ready. Some components went directly into the design system from there, and that was intentional from the beginning.

Then I drew the process. With that clarity in place, it made sense to map it visually so everyone could see where each person sat in the new flow.

We brought people in one at a time. That was a deliberate choice. Some of us needed space to get familiar with concepts that were completely new (things like “git commit”, “pull request”, “push”) without the pressure of everyone watching. Each person came in when the previous one felt steady.

This is the process we presented to the dev team, defining who should do what and in what order.

The resistance

We had two different objections, coming from two different fears.

Management was concerned that us pushing code meant developers spending more time reviewing than building. A valid concern.

Developers were more direct: “If you are doing that now, what are we doing?”

We brought product managers in early as alignment bridges. Having PMs speak to both sides changed the tone of the conversation in a way that designers alone could not have done.

What we said to developers was straightforward. You no longer have to spend time on the pixel-perfect visual layer and interaction details. That is ours now. You can go deeper into logic, security, architecture, the parts that were always further from our side. We can also build the LLM context together, which means code reviews go faster because the expectations are already shared.

That landed better than I expected.

What changed

Two features and several design system components shipped this way. The full team is using these tools now, one person at a time, until everyone is on board. Planning cycles were shortened, and back-and-forth on visual details in development dropped significantly.

But the more honest change is harder to measure. The design team did not become design engineers. We are still designers. We just developed a more operational mind, and that closed a gap that had always been there.

The boundary between design and engineering is not disappearing. It is just moving. And I think the teams that figure out where to move it intentionally will have a real advantage over the ones waiting to see what happens.

If you are working through this or have done it differently, I would like to hear about it.