Back to writing

Two frames

May 10, 2026

Discuss with

We shipped Quartermaster last spring, and a few weeks after launch I went back to look at the Figma file. It had two frames in it. A task row and a task detail panel. That was it. The whole product.

I didn't plan that. I'd opened Figma twice during the entire build, both times for components I wanted to nail down before I touched code. The rest of it - the flows, the layout, the polish, every screen anyone has actually seen - happened somewhere else.

A few months earlier, building Ovii, I'd designed every screen. Onboarding, login, account setup, actor creation, scene generation, video output. Every shipped screen had a Figma counterpart, the way every shipped screen of mine had had a Figma counterpart for the previous decade. That was just how I worked. I was a designer. Figma was where I lived.

The thing that changed in between those two projects was that I started using Claude Code. Before that, I'd been bouncing between Cursor and the design file - designing something, watching it get rebuilt, going back to update the design to match what actually shipped. Once I could manipulate what was shipping directly, the design file got demoted fast. It was duplicate work, and I could feel it.

There's a specific moment from Quartermaster that captures the shift for me. We were trying to figure out how much information to put in a task row. Quartermaster is built for AI workflows, which means tasks have a lot of context attached - things the agent needs to know in order to do the work. The first version tried to surface most of it inline. You'd open the list and see a wall of metadata.

I sat with it for a while and the word that kept coming to mind was altitude. At a high level, you want to see where you are relative to the whole area. As you descend, things sharpen. You start picking out where you're landing. By the time you're close, you can read the billboards. A task list is the high view. A task detail is the descent. The billboards are the buttons - the link, the status, the thing you actually came to do.

In the old workflow, that insight would have lived in Figma for two days while I made variants. In the new one, I described it to Claude, looked at three layouts in the browser, picked one, and kept moving. Same thinking, different place to do it.

The day breaks down differently now. A year ago I was 90% in Figma, 5% in Linear, 5% in everything else - docs, Slack, the calendar. Today it's more like 70% terminal, 20% Claude, 10% Figma. The terminal part would have terrified me a year ago. I had some chops, but I wasn't shipping code. I just wasn't.

The thing I keep coming back to is what each part of the work used to be, and where it went. Wireframing went to Claude. Visual design went to code. Handoff disappeared, because Josh and I work in the same files - I'll prototype something, he'll make it functional, I'll come back and polish, or one of us will take it end to end. There's no Figma-to-PR pipeline because there's no Figma to hand off from. The only thing that didn't move is asset creation. Icons, marketing graphics, deck assets. That's still Figma, and it's probably the biggest role Figma plays in my work now, which is a sentence I would not have written two years ago.

I still sketch all the time. Paper, iPad, whatever's nearby. The sketch is where most of the design happens, honestly. What changed is what I do with the sketch. It used to translate into Figma frames. Now it translates into words.

There's one product we built where the shift wasn't a preference, it was the only way. Flagship is our mockup generator - you describe the environment you want a device to sit in, and it generates it. The core flow is models, image generations, loading states, previews. Things that are dynamic by definition. You can't design a generative tool in a static design tool. You can approximate it, but you're lying to yourself about what the experience actually feels like. Working in code is the only way to accurately design it.

That product would not have been the same product if I'd stayed in Figma.

I've been having a lot of conversations about this lately. Designer friends asking what my day looks like now, designers I used to manage checking in, a few people quietly worried that they're behind. The thing I keep telling them is that the design skills didn't stop mattering. The opposite, really. The skills that move the needle right now are the ones that always moved the needle: caring deeply about the user, being able to communicate what an interface is for, having an opinion about what good looks like. The vocabulary I built as a designer is the reason I can describe things to a model and get something usable back. A developer trying to prompt UI is going to write add more spacing. I'm going to say pt-24. That isn't better, exactly. It's a more developed vocabulary for the work.

There's a Cap Watkins post I've been thinking about for years called "The Boring Designer." One of the traits he names is designing the obvious over the inventive. That stuck. I've tried to design that way the whole time, and what AI has done is shorten the gap between the obvious design and the shipped product. If anything, it's let me be a more boring designer more of the time.

I guess this is all to say: I haven't gotten worse at any of the things I used to be good at. I've gotten faster at most of them, and a lot better at the ones that touch code. The designer in me is still doing the work. He just isn't doing it in Figma first.

If you're a designer reading this and you're nervous, I get it. The honest answer is that the shape of the work changed, and the people who'll do best are the ones who let their role widen instead of guarding what it used to be. Go widen it. The other side of this is more fun than I expected.

Explore
Writing
Email me