The designer’s new medium is not Figma. It’s the product.

A year ago, my design process looked pretty normal.

Depending on the project, I might interview users, review metrics, test prototypes, work through heuristics, run design critiques, or spend more time aligning with product and stakeholders.

The specifics changed. The ending usually didn’t.

I designed in Figma.

We iterated there. We reviewed there. We documented decisions there. Eventually, I walked product and engineering through the final design and handed it off.

That was more or less where my responsibility ended.

I knew the technical concepts a product designer was expected to know. I understood components and design systems. I knew Material UI, Bootstrap, Apple’s Human Interface Guidelines, and Storybook. I had taken HTML and CSS courses, which helped me understand responsiveness and how interfaces were structured.

But if you had asked me what a branch was, how a pull request worked, what CI was doing, or how the repository was organized, I wouldn’t have known.

Code belonged to developers.

That boundary felt completely normal.

Today, my workflow looks very different.

I still use Figma. I still sketch. I still work through the problem before jumping into a solution.

But once the direction is clear, I increasingly move into the product itself.

And that shift changed much more than the tool I use.

It changed how I design.

Figma was never the product

This sounds obvious, but it took working directly in production code for me to fully understand the consequences.

Figma is an incredibly useful representation of the product.

But it is still a representation.

Imagine we redesign a header.

The new header goes through the normal process. It gets reviewed, approved, documented, and added to the design system in Figma.

But engineering can’t migrate the entire application immediately.

Maybe parts of the existing header were hardcoded. Maybe there are technical constraints. Maybe the team decided to introduce the new version gradually over the next three months.

That is completely reasonable.

The problem is that Figma now represents a future state.

Production does not.

Another designer can open the file, see the approved header, and design an entirely new flow around it.

Stakeholders approve it. Product approves it. Maybe users even validate it.

Then engineering starts implementation and says:

We don’t actually have this yet.

Now there is a mismatch.

Maybe the team has to hardcode another version temporarily. Maybe the design has to change. Maybe engineering has to invent an intermediate solution. Maybe everyone spends another round discussing something that appeared settled weeks ago.

This is one reason developers sometimes say that designers “don’t know the product.”

They usually don’t mean that designers don’t understand the user journey.

They mean designers sometimes don’t know the exact state of what is implemented.

And that criticism is not entirely unreasonable.

Figma is often ahead of production because it has to be.

That creates a gap between the system we are designing and the system users are actually using.

Handoff is a lossy translation

Even when Figma and production are perfectly aligned, handoff introduces another problem.

Translation.

You can document everything.

Spacing. States. Interactions. Motion. Responsive behavior. Edge cases.

You can write notes.

You can record walkthroughs.

You can sit with engineering.

And still, people are people.

Something gets interpreted differently.

Something gets skipped because the deadline is tight.

Something gets classified as “visual polish” and moved into the backlog.

I saw this constantly with interaction details.

An accordion technically works whether it opens instantly or transitions smoothly.

A panel technically works whether content jumps across the screen or moves predictably.

Those details are easy to classify as aesthetic.

But I don’t think they are purely aesthetic.

A product can be technically functional and still fail experientially.

If I click an accordion and half the interface suddenly jumps downward, I have to reconstruct what just happened.

Where did the content go?

What moved?

Did I trigger the right thing?

A small transition communicates that change without requiring conscious thought.

I click.

I see the section expand.

I understand why everything below it moved.

The interaction explains itself.

That is feedback.

And feedback is part of usability.

In traditional handoff, details like these were often the first things to disappear when time got tight.

I understood why.

Engineering has constraints. Budgets exist. Deadlines exist. A team has to prioritize functionality.

But the person who ultimately experiences that tradeoff is the user.

Then I realized I could fix some of it myself

My first steps toward code actually started before coding agents became part of my workflow.

My team had been exploring a more Basecamp-like approach to product development, and I had started taking HTML and CSS more seriously.

Then AI accelerated everything.

Codex and Claude Code changed the cost of crossing the technical boundary.

Suddenly I could explore a repository, ask why something worked the way it did, make a change, run the application locally, and understand the consequences.

The beginning was not elegant.

The first time I tried to run a Rails project locally, it was painful.

I spent hours trying to understand error messages, copying terminal output into ChatGPT, trying things, failing, trying again.

I considered giving up.

And the timing was strange because I was already watching AI-generated interfaces improve incredibly quickly.

Tools were appearing everywhere.

For a while, I had a very uncomfortable thought:

Maybe this is it. Maybe designers are becoming unnecessary.

Instead, the opposite happened.

AI did not make me feel less valuable.

It expanded what I was capable of contributing.

The first time the prototype was real

There is a meaningful difference between building something that looks like the product and changing the actual product.

For me, that difference became real when I started opening pull requests.

I wasn’t creating a prototype that would eventually be interpreted by someone else.

I was making a contribution to the codebase that real users would eventually interact with.

That changed my relationship with design almost immediately.

Small things that had lived in the backlog for months suddenly became approachable.

Interaction polish.

Spacing issues.

Transitions.

Visual inconsistencies.

Details that had repeatedly been deprioritized because they were not blocking functionality.

With coding agents, many of those changes were surprisingly fast to explore.

I need to be careful here.

I am not claiming those changes were always technically trivial.

I am not an engineer.

An agent may solve something in a way I do not fully understand. It may introduce the wrong abstraction, add unnecessary dependencies, or solve the visible problem while creating a deeper one.

That is exactly why engineering review still matters.

But the conversation becomes very different when the starting point is no longer:

“Could we possibly add this interaction?”

It becomes:

“This interaction works. Is this the right implementation? If not, what is the safe way for us to support it?”

That distinction has been incredibly important for me.

I can advocate for the experience with something tangible.

Engineering can challenge the implementation rather than the existence of the experience.

Designing in code changed what I notice

I still believe the design process should begin before high fidelity.

Understand the problem.

Explore.

Sketch.

Validate the direction while changing it is still cheap.

Talk to users when appropriate. Review the idea with product. Check feasibility with engineering. Run critique.

I do not want to spend hours polishing something we should never build.

That part has not changed.

What changed is what happens after the direction is clear.

I used to move from rough exploration into polished Figma screens.

Now I often move from rough exploration into the actual application.

And the moment I do, the design problem becomes different.

Real content changes the interface

In Figma, it is very easy to accidentally design the perfect dataset.

Short company names.

Beautiful one-line descriptions.

Predictable numbers.

Real products are not that polite.

Users create absurdly long names.

Descriptions overflow.

Records have missing information.

Data behaves in ways that mockups rarely anticipate.

Designing against the real system exposes those assumptions immediately.

Responsiveness stops being theoretical

We have always designed around breakpoints.

But there is a difference between designing a mobile frame and physically resizing the interface while the real content responds.

You start making decisions based on behavior, not screenshots.

Interaction becomes part of the design earlier

Parallax.

Transitions.

Scrolling behavior.

Panels.

Focus states.

Hover.

Loading.

Things that are possible to represent in Figma but often cumbersome to evaluate there become much easier to judge in the environment where they will actually exist.

You stop asking:

“Does this screen look right?”

and start asking:

“Does this behavior feel right?”

Edge cases become harder to ignore

Designers and developers have argued about missing edge cases forever.

Fairly.

I have missed them too.

Working with agents can help because those edge cases can become part of the implementation workflow.

You can instruct the system to check empty states, long content, loading behavior, responsive breakpoints, accessibility, and other recurring conditions.

That does not remove responsibility from the designer.

It makes those conditions easier to repeatedly test.

Figma still matters

None of this is an argument that Figma is dead.

I use it constantly.

Visual exploration is often much faster there.

Brand direction.

Typography.

Composition.

UI kit exploration.

Finding the personality of an interface.

FigJam is still one of my favorite spaces for thinking collaboratively.

And sometimes the code looks terrible.

An agent can misunderstand the layout or make an aesthetic decision I would never make.

When that happens, I still take the problem back into Figma, solve the composition visually, and then return to the product.

The workflow is no longer linear.

It might look like:

sketch → code → Figma → code

instead of:

Figma → handoff → code

The important difference is that Figma is no longer my source of truth.

The product is.

The collaboration problem doesn’t disappear

Figma solved more than visual design.

It became a collaboration layer.

Product could review a flow.

Stakeholders could comment.

Marketing could grab screenshots.

Engineering could inspect the system.

If design moves closer to code, you have to replace those collaboration affordances.

A pull request works well for engineering.

It does not necessarily work for a product manager or a stakeholder who has never opened one.

I ran into this quickly.

So I started experimenting with ways of creating a non-technical handoff alongside the technical one.

My engineering handoff might be a PR, patch, or bundle depending on the access I have to the repository.

For everyone else, I built a handoff workflow that generates an HTML walkthrough with screenshots, notes, explanations, and the context needed to review the experience.

I usually include a video of the working flow as well.

And when someone still needs screenshots in Figma, I can generate the screenshots from the actual application and put them there.

The goal is not to force everybody into GitHub.

The goal is to stop requiring the designer to maintain a parallel fictional version of the product just so collaboration can happen.

I am not trying to become an engineer

This distinction matters to me.

I do not suddenly believe every product designer should become a frontend developer.

I do not believe engineers are unnecessary.

And I definitely do not believe that because an AI agent can make something work, the implementation is automatically good.

Engineering judgment still matters.

Architecture matters.

Security matters.

Maintainability matters.

Performance matters.

Knowing what not to introduce into a codebase matters.

I have more respect for those constraints now because I can actually see them.

What changed is that technical systems no longer feel completely inaccessible to me.

A year ago, if something required touching the repository, my instinct was:

That belongs to development.

Now my instinct is closer to:

Can I explore this safely?

That is a very different boundary.

AI did not turn me into an engineer

It reduced the cost of interacting with engineering systems.

That may be the most important change.

Codex and Claude Code can help me locate the relevant files.

They can explain unfamiliar code.

They can implement a direction.

They can help me run the product.

They can surface errors.

They can iterate.

But they cannot decide what experience should exist.

They cannot automatically understand which compromise is acceptable for this product, for these users, in this context.

And they definitely do not remove the need for review.

What they changed was access.

Things that once required enough technical knowledge to stop many designers before they started are now explorable.

That changes who can participate in implementation conversations.

My limits moved

When I first saw AI building interfaces, I worried that my value was shrinking.

Working closer to code had the opposite effect.

It made me understand my value more clearly.

I can contribute further into the product than I thought I could.

Not because I suddenly became an engineer.

Because the boundary that defined what a designer was allowed to touch turned out to be much more flexible than I assumed.

The biggest thing that changed when I started designing in code was my sense of possibility and my sense of where my limits actually were.

My limit was not:

I don't code.

The more useful question became:

What can I contribute while still understanding where I need engineering judgment?

That is a much larger space.

And it has changed how I think about the medium of product design.

For years, I treated Figma as the place where design happened and the product as the place where design was implemented.

I no longer see them as two separate stages.

The interface users experience is the design.

The behavior is the design.

The real content is the design.

The responsive state is the design.

The implementation constraints shape the design.

So increasingly, I want to work where all of those things actually meet.

Not only in the representation of the product.

In the product itself.