UX writers hate him. He gave designers a writing tool and walked away.
I built a Figma plugin from scratch. It took me 60 days and 86 iterations. Literally zero JavaScript experience. Designers can now produce review-ready microcopy independently.
Context
The ratio was uncomfortable: 20+ designers, one UX writer — me. Most projects were UI-heavy and designers worked independently. But when copy mattered — when mockups needed real text before a client presentation — everyone came to me at once.
I knew I was a bottleneck. Not theoretically. I could feel it. And I had a second, more personal problem: I wanted to take a vacation without my phone ringing every few hours because a microcopy decision was stuck.
“The tool had to live where designers actually work. Asking them to leave Figma just to fix three words was never going to fly.”
Process
First attempt — and the insight that killed it
My first idea was a Claude agent — a simple chatbot where designers could paste text, get it improved, and move on. I was genuinely proud of it. It felt like a real systems solution.
I showed it to a designer I trusted and asked if he'd use it. His answer floored me: absolutely not. It was too far from his tools.
That single conversation changed everything. The tool had to be where designers already were. At the time, that meant Figma.
Learning from zero
I knew nothing about Figma plugins, JavaScript, or API integrations. Zero. I used Claude as my programming tutor — describing what I wanted, getting code back, testing it in Figma, breaking it, figuring out why, and going again. The loop was: describe → generate → test → break → learn. I repeated it until something worked, then I repeated it some more.
Solution
The first version was minimal: select a frame manually, send its text to Claude (Haiku model), get improved copy back. It worked. Then I kept going.
Over 86 iterations, the plugin grew into something I hadn't fully planned at the start. I added automatic frame detection so designers didn't have to select anything manually. The plugin also detects context from the interface itself — it reads layer names and structure to understand whether it's writing a button label, a form field title, or an error message, and adjusts the output accordingly. A button and a form field title aren't just different lengths. They're a different kind of language entirely. I added model selection — Sonnet gave much better results than Haiku but cost more, so giving users the choice mattered. I built a translation module supporting 12 languages.
Batch editing was another step up. Designers could update copy across an entire frame at once — 20 text layers simultaneously, in a single run.
One of the more impactful additions was project context. Each client project got its own set of content guidelines stored directly in the plugin. When a designer hit "Improve," the text didn't just go through Claude — it went through Claude with that project's guidelines as the system prompt. Output came back on-brand, consistent, and ready to use. Designers stopped having to remember tone-of-voice rules. The plugin remembered for them.
Security took a serious chunk of time.
I integrated Cloudflare Workers to route API calls safely, hid the API key from the plugin code entirely, and built in protection against prompt injection attacks.
.png)
.png)
Results
Five to ten designers started using the plugin regularly. Poor-quality drafts stopped making it to client presentations. The bottleneck I'd been worried about disappeared. The plugin's success led to four more content ops tools being built at the agency.
I handed the tool over to the design team when I left Flying Bisons. I'm now developing a similar tool independently.
What I learned
AI is a lever. Point it at technology, not people.
Working with AI requires patience and a lot of iterations. Especially when you're learning something from scratch. The high iteration count isn't a sign of failure — it's the cost of learning something you had no prior knowledge of. You have to love the process. But once you do — boy, the sky is the limit.
Some people assume a tool like this replaces the UX writer. I'd push back on that. Writing microcopy is maybe 20% of the job. The rest is tracking flows and finding communication pain points — places where copy is missing, where there's too much of it, or where what's there simply doesn't fit the moment. Should this label exist at all? Does this screen need any text, or would removing it solve the problem faster? Those are judgment calls, and they require someone accountable for the answer. When I asked designers whether they'd want to make them, the answer was consistent: no. Some were open to writing and willing to learn — but they weren't strong writers. And none of them wanted the responsibility that comes with owning content decisions.
UX writing isn't being replaced by AI. It might be squeezed by full-stack designers who pick up content skills — but the logic runs both ways: a UX writer who learns to design covers that ground too.
And for what it's worth — I'm still a little surprised by how well it turned out.
Technology scales better than heroics — and better than headcount.