Field note 01

Designing in Production

For a while now, the center of gravity in my design work has been moving. Figma is still on my desk. It's just no longer the only place the work happens. New tools are becoming accessible fast, and they're quietly changing what a product designer does day to day. This isn't a story about abandoning anything; it's an observation about where the role is heading.

The designer's job was never to make files. It's to drive outcomes and shape the experience. The artefacts are changing; the goal isn't.

I work at Ultralytics, a company obsessed with speed of delivery and open to rethinking how things get done. That culture is what's made this shift possible, and easy to watch up close.

Phase 1: Zero to One

The product doesn't exist yet.

The classic flow

Wireframes, high-fidelity mocks, hand-off documentation, then meetings to bring the dev team up to speed: context, expectations, open questions. It works, and it has carried our whole industry. But every handoff is a translation layer, and translation has a cost. What gets built is usually close to the intent, rarely exactly it. Some nuance gets rounded off along the way. That's not anyone's fault. It's just what happens when intent travels through layers of abstraction.

What's changing

The newer tools let me remove some of those layers. I can put something testable in front of people in hours, so the intent arrives more intact. There's simply less to misinterpret.

It's less about raw speed and more about fidelity of intent. I reach for whatever gets me to a real answer fastest. For early exploration, tools like Figma Make or Lovable are great for quick visual prototypes. When I need genuine validation, I work directly in the product repository.

Here's how it works: I create a branch, make frontend changes with Claude Code, and push. Vercel automatically deploys that branch as a live preview: a working product, connected to real data, in a real environment. Nothing is merged to production, so there's no risk, but it behaves like the real thing.

I can test it myself, share the link with the team, or put it in front of users: real interactions, real data, real context, not a clickable mock standing in for a product.

If the direction is wrong, I delete the branch and nothing is lost. If it's right, it's already built, ready to be refined and merged.

The priority is speed of validation, not pixel fidelity. If people can use it and react to it, the prototype has done its job.

Phase 2: The Continuous Loop

The product is live but still maturing. This is where most of the time goes.

In this phase the product itself becomes the source of truth. There's less need for separate documentation: want to understand how something works? Use it. Need to trace why a decision was made? Read the Linear task history.

Work lives as small, bite-sized tasks with precise expectations, instead of long “in progress” stretches. The team ships daily.

The loop

1. Experience the product daily, the way a user would.
2. Capture everything in the flow. I use MacWhisper to voice-record bugs, ideas, and improvements with full context, without stopping to write tickets.
3. Let AI synthesise. I feed those recordings into Claude Code in my IDE; it's set up to clean up my notes and create tasks directly in Linear via MCP. (Curious how? Search “how to use CLAUDE.md”. It's simpler than it sounds.)
4. Ship and repeat. When the team delivers, I test again. If something's off, it goes back into iteration or becomes a new task.

The context lives in the task itself, not a separate design file. I can write a task today and test the shipped result tomorrow morning, sometimes the same day.

Why this works: preview deployments

In environments like Vercel, every branch you push becomes a live preview: a working product on real data, reachable by link. That small thing changes a lot:

• Make a change in the repository.
• Get a live URL in minutes.
• Test it yourself on real data.
• Share the link with the team, customers, or users.
• Run an interview, watch someone use it, ask questions.

No mocks to upload, no separate prototype tool, no waiting on a staging build. You see how the real implementation behaves under real conditions. If it works, you move forward; if it doesn't, you change it or drop the branch. You risk little and lose less.

This is the feedback loop that makes a real “value handoff” possible: you're not describing what should be built, you're showing what exists.

When you need to go deeper

Sometimes a specific component needs exploration. I don't build a whole library; I use tools like designarena.ai, lmarena.ai, or claude.ai to build the component, test the interaction, and paste the link straight into the Linear task. That's the handoff.

We use Shadcn (one of the most popular component libraries around), but I keep my requirements generic and don't lock the team into specific components. The aim is something testable quickly, not settling in theory which component is best.

And when you can build and test something faster than you can describe it, the conversation naturally shifts: less debating approaches nobody can feel yet, more reacting to something real.

Show, then tell.

The Friction: Working with Development Teams

This is more than a tool change. It's a change in how teams work together, so some friction is normal. It helps to expect it.

What to expect

People adapt at different speeds. Some (often the more experienced engineers) see the value immediately: a designer delivering tested, working code means less ambiguity and faster iteration. They'll help refine the components, split them into maintainable pieces, and the collaboration gets better.

Others will be more cautious. You might see work rebuilt from scratch, or a UX decision changed without discussion. It's rarely malicious. It's unfamiliar. The classic pattern (designer sends mockups, developer interprets and builds) is deeply ingrained, and working code from a designer breaks it. Some read it as overstepping; others simply don't trust it yet.

Why this happens

It's not about skill or attitude. It's habits and expectations. People need time to see that this reduces their workload rather than threatening it.

What helps

• Align with dev leadership first. At Ultralytics, leadership backed this early; they understood what faster validation does for the product. Get that buy-in before changing the workflow.
• Communicate the value plainly: you're not replacing developers, you're handing over tested solutions that reduce ambiguity and rework.
• Work closely with the team, especially early. Show the quality; let them adapt the code to the architecture.
• Be patient. Habits take time to change.

The goal is a clean division of labour: designers deliver well-tested solutions in code, developers refine and maintain them. That takes trust, and trust takes coordination.

On Tools

I've named specific tools here, but they'll change. What lasts is the pattern: capture fast, synthesise with AI, ship to real environments, test on real data. The tools that enable this today won't be the exact ones a year from now, and part of the fun right now is watching which ones stick.

Adopt the workflow, not the toolset.

Is This Still Design?

If I'm making fewer mockups, am I still designing? I think so. Design isn't the process or the deliverable. It's the result. It lives in the product: in how it feels and what it lets people do.

That experience is built from thousands of small implementations adding up to something people can feel and get value from. Whether it's delivered through prototypes, mockups, words, code, or Linear tasks matters less than whether the final product is good.

The line between designer and builder is blurring. Increasingly, we're all product creators, and the toolbox is just getting bigger.