One tool, present everywhere

1. Closing product quality tickets

A product quality ticket lives in Jira. The context lives in Figma. The fix lives in the codebase. Before, I was the glue between all three — copying specs, translating intent, hoping nothing drifted.

Now I point Claude Code at the Jira ticket and the Figma file, and it recommends solutions, suggests copy, and surfaces exactly what needs to change. I make those updates in Figma, then hand off to engineering to finish.

Closing a product quality ticket

Vincent van Gogh, Almond Blossom (1890)

2. Rewriting UX copy at scale

Every company writes a certain way. There's a voice, a set of principles, and an agent that reviews copy against them. I use that agent in two modes.

For quick feedback, I point it at whatever I'm working on in Figma and get recommendations in context — tighten this label, soften that error message, match this string to the glossary.

For larger sweeps, I point it at an entire codebase and it produces a Google Doc with every string that needs updating. I manually review that doc — the human-in-the-loop step matters here, because tone is judgment — and then point Claude Code at the approved changes and open a PR. That PR still gets reviewed by content designers and engineering. You can never have enough eyes.

Quick reviewFull sweep

Switch between tabs to see different examples

Vincent van Gogh, Orchard in Blossom (Plum Trees) (1888)

3. Building throwaway prototypes for research

The best research happens when you put something real in front of someone. Not a wireframe, not a screenshot — something they can touch. The problem was always time. By the time you've built something testable, the research window has moved.

Claude Code builds prototypes fast enough that I can have something tangible before the brief is even finished. Most of them get thrown away. That's the point.

Building a research prototype

Vincent van Gogh, Pink Peach Trees (Souvenir de Mauve) (1888)

Vibe-coding, much like designing, is judgment. No amount of Claude Code skill will save a prototype that's solving the wrong problem or asking the wrong question. The tool removes the cost of building — but the cost was never really the building.

It was knowing what to build, what to leave out, and when something feels off even though it technically works. You still need to train that instinct. Ship things, watch people use them, notice what you missed. The reps are the point.

4. Writing research briefs and scripts

Once a prototype exists, you need a plan for testing it. The research brief, the scripts, the screener — all of it takes time to draft from scratch.

I point Claude at the product brief, the prototype it just built, and our research brief template. It fills in the structure — objectives, hypotheses, tasks, screener criteria — and I review, refine, and polish. The thinking is still mine, but the first draft isn't blank anymore.

Drafting a research brief

Vincent van Gogh, The Harvest (1888)

5. Building personal software

I don't particularly enjoy reading design system documentation or hunting for answers in the product-design-team Slack channel. But I use both every day.

With Claude, I built a personal tool that lets me search both knowledge repositories at once — design system docs and Slack history in a single query. No context-switching, no scrolling through threads.

Building a design system search tool

Vincent van Gogh, The Bedroom (1889)

6. Deploying Minions for the small stuff

There's a category of work that's necessary but doesn't require deep creative judgment — small PRs that fix something obvious but would quietly rot in a backlog. Minions handle those. I describe the issue, point it at the repo, and it ships a PR that I review. The work gets done instead of waiting.

Deploying a Minion

Vincent van Gogh, Fishing Boats on the Beach at Les Saintes-Maries-de-la-Mer (1888)