Requirements often came to me as rough notes, and every state and edge case was expected to be covered in Figma. While this expectation is not unusual, there was only one of me, so the influx of priorities made delivering it consistently unsustainable.

To save time, I sometimes handed off low-fidelity drafts with instructions to reuse existing states for simple things like settings pages. However, improvisations on these drafts and descriptions accumulated UX bugs.

Before

After

I hypothesized that designing inside of developers' medium of choice would unburden them from matching styles, thereby reducing the number of design bugs in staging. I tested this with a feature that required no new components to build.

I found it quite simple to get set up in the codebase and noticed a few unexpected things that felt better for me immediately:

When I handed off a branch instead of a static mockup, the developer and I were speaking the same language, so there was no splitting hairs over incorrect styling. To my delight, implementations began to look increasingly identical to what I built with Claude, requiring fewer rounds of review in staging.

2. Zero-to-one building

I find the fastest way to unblock a discovery session is to just put a design out there, even if I don't think it's very good. When someone presents a vision document, the crickets in the room can be deafening, but people loosen up when they have something visual to poke holes in.

Before

The problem with presenting visuals to spark discussion is that making them takes time.

Sometimes, energy in the room rises to such a level that everyone starts jamming out on color choices and animated effects like it's a free-for-all at the Casio warehouse. Unmoderated, we wouldn't find out we'd solved the wrong problem until seven effortful iterations in.

Other times, stress or decision fatigue prevented people from seeing the forest for the trees and they would home in on padding, font sizes, or even the dummy data itself.

The obvious answer to that is to abstract away the distractions by going lower fidelity. I tried Balsamiq, hoping the pencil sketch aesthetic would keep us in the problem definition phase, but still I would get questions like "The tooltip here looks different than what we have in the app. Are we changing that?"

After

Using Claude Code, I attempted to tackle this by building the prototype out of real components, realistic data, and working interactions. I hoped that without anything fake left to react to, we could focus on the "why."

For one wave of work, I had to create views for four conversational AI tasks, each with six or more states. I created a branch that laid out every task's state side by side, and, separately, showed how each would appear in the AI chat interface where users would encounter it.

Admittedly, the number of review rounds didn't decrease by much, though it did by a little. The more important thing was that I felt like my bandwidth as a designer increased because I could work on two or even three designs in tandem. While Claude fathomed and flibbetigibbetted, I switched tabs and worked on something else, rather than laboriously fiddling with layout idiosyncracies in Figma.

And, because we saw it live in the app so early, we proactively caught a lot of the "this feels weird" we'd experienced in staging. I had a lot more confidence that what I'd designed solved the correct problem before a developer wrote a line of code.

3. Pushing design bugfixes

Our engineers were fast, and their time was best spent on architecture, data flow, and wiring up new functionality. Funnily, tweaking styling until it looked right was the work they did most slowly, and I could do it more quickly with Claude than in Figma. After a short ramp-up, I was opening PRs alongside them.

I went after our table component because at least one was on every page, and our users worked in them all day. The problem was that somewhere along the line, many patches after it was built, all the tables drifted too far from their intended design.

After

I opened several PRs to address consistency and interaction issues, and before I knew it I had seven lined up in one day. The fixes were all reviewed and merged through the same process as any engineer's work.

Our VP of Product and Engineering called this type of work "super high value," and I believe it's because it rarely has a dedicated owner. Because interaction fixes can't be described in static images, you have to hope the front-end engineer has time to thoroughly program the animations. Otherwise, you have to know how the code works properly to describe the fix yourself, or spend hours making stop-motion with Figma frames.

Taking this over gave engineers back the time they'd been spending on visual polish, which I estimate at roughly 10–15% more front-end capacity at the same headcount, and gave me an increased sense of satisfaction over the ownership I now felt over the end product.

Closing thoughts

Thought #1

In design-mature organizations, the idea that good design increases a product's value is baked into the culture. A startup pursuing product-market fit, however, may find it secondary to developing customer relationships or proofs-of-concept because they never saw the user experience make or break a deal.

In an engineering-first culture which has not yet encountered a charismatic design evangelist, there may be some resistance to adopting traditional design processes which, by nature, are meant to slow down something as important to engineers as velocity.

At times, I feel like "Man, no one really cares about the UX. They just want it built." But, the user experience wasn't really important to the customers most of the time because they were trying to find a product that not only accomplished their essential tasks well enough, but also supported them.

Meeting my organization the way they needed to be met were helped me build a partnership that didn't disrupt the work in progress, which was most important.

Thought #2

When designers own only the Figma file, they barely own the outcome. What ships lives in the codebase, or in Storybook. Designers maintain a picture of the system while the engineer builds and demos it as their own creation. Designers are often expected to be the pixel-perfectionists, but unless we're in the code, we never get to take our own work the last mile.

Design can make innovation happen without slowing velocity if we reconsider the relationship between design and dev. As builder roles become commonplace, it's possible that the best collaboration happens between teammates who hate what the others loves to do and vice versa. I imagine with clear boundaries, design and dev can co-own the translation layer, with something like a shared token library or Claude Code skill keeping everyone speaking the same language.

Thought #3

I can only speculate about how this scales. At a larger company where there is more process and clear ownership, co-owning the middle could get messy, with friction over where one person's responsibility ends and another's begins.

All in all, this was more than an enjoyable way to work. It got to something that felt done, in less time, and with fewer design bugs and more feeling of ownership of the end product.