I Don't Use AI for Speed. I Use It to Buy Back Time.
I don't use AI just for speed. I use it to get my time back — time I can then put toward producing better quality work, both individually and with my team. On screen here is a research report generated by AI. This report gave me the opportunity to conduct more user interviews, because AI helped me process the data in a way that made it easy for me to understand quickly. You can do this too — I'll walk you through the report on screen. If I scroll down to a specific section, you can see this was generated with AI's help — a powerful result using far less time, through prompt engineering. I've also created a prompt-writing playbook for my team, which is open to everyone. You can check it out too, to learn how to write better prompts and get similarly structured, useful output.
Having Claude Inside Figma? Here's What Happened.
An AI-first approach gives me the ability to push further into AI implementation. One example: I've been experimenting inside Figma, where I built — or more accurately, heavily modified — a plugin that brings Claude directly into Figma. I can run the plugin right here. It's currently connected to the Claude terminal — I'll say hello, it syncs, and once that sync completes, we're ready to go. Let's ask: what's the color? You can see it confirms the hex value — 5F9 — which matches exactly what's already present in the file.
I Stopped Designing in Figma First. Here's My New Workflow.
I use AI prototyping to stay focused on the core aspects of design. Previously, if I wanted to redesign something — say, this download page — I'd go into Figma, design one variation, then a second, then bring in stakeholders and a project manager to discuss which version we wanted and why. With AI prototyping, this happens much faster. I don't need Figma at all — I can build directly in the codebase. I'm using Cursor here, and this is an actual working page, not a mockup. This is variant one, running on localhost right now — and here's a second variant, same page, different design, also running locally. This gives me a much stronger way to align with my team and stakeholders, because once they see something running rather than a static design, they often surface insights that wouldn't have come up in Figma. Here's how it looks in Cursor — currently running on my local machine.
My Design Tool Stack Changed Completely in 2 Years. Here's the Before/After.
I get asked constantly what tools I actually use — so here's my stack, and how much it's changed over the last two years. On the left is what I relied on most in 2024. By 2026, the stack looks completely different: Figma, Miro, and Codex are still part of it, but Open Code has become one of my favorites, because it lets me run multiple AI agents from a single interface instead of jumping between tools — Claude, Cursor, ChatGPT, Gemini, all in one place. I also use Paper Design, which I'll cover separately, and a database tool that helps me write queries even when I don't know the exact syntax — AI writes the query for me. The real value is being able to see exactly how data is being inserted into the database, which helps me ask sharper technical questions: what kind of data is flowing through, what are the limitations, what needs to change. It gives me clear boundaries to think through before jumping into a solution. Open Code in particular lets me switch models on the fly — including free-tier options — which is useful when I'm doing quick R&D and don't want to burn tokens unnecessarily.
I Shipped a Design Change Without Opening Figma.
When a user story is small enough, you don't need to open Figma at all. You can make the change locally, raise a PR, and ship straight to production. Here's a real example: I needed to update a headline on the website, and I skipped the design step entirely — no mockup, no Figma file. I made the change directly in the code, raised a PR, and someone on the team reviewed it. If an automated approval process is in place, it moves straight to the next stage. This is the shift from being limited to design work to actually contributing to the codebase as a design engineer — where the PRs you raise and get merged represent real, measurable value added to the product. It's a genuinely powerful way to work, and it mirrors how developers already operate.
The 4 Questions I Ask Before Burning an AI Token.
AI isn't free — using tokens wisely matters, both for me and for the company. Say I want to create a new variation of a design — a different color combination of the same layout. I could do this with an AI agent like Claude or ChatGPT, but before I do, I ask four questions. Is this solving a real user problem? Yes. Would delaying it cost the company money? No — whether I do it now or someone on my team does it in half an hour, there's no real cost to waiting. Can a simple rule-based approach solve this instead of AI? Yes. And can that process be automated? Yes. When the answers land this way, a simple automated approach beats spending AI tokens on it. In this case, I ran a plugin that does a find-and-replace on design variables — swapping one token value for another across the page. It takes about five repetitions and under five minutes total. That's a small time cost for me, but it saves meaningful token spend that can go toward work that actually needs AI.
