How I use AI in my work as a designer

What I use

Two families of tools, no more.

Claude and Claude Code. I use Claude to think, synthesize, and write. Claude Code goes further: it works directly in my files, whether that's code or a Figma file it's connected to. It creates, edits, tests, and checks.

Figma's built-in AI. I use it for tasks that happen inside the tool itself, when opening something else would take longer than staying on the canvas.

I don't stack tools. Every extra tool is one more context to re-explain and one more source of inconsistency.

How I work, in five stages

Whether I'm designing mockups, a website, or an app, I follow the same sequence. It looks a lot like a classic product method, and that's no accident.

1. Scope before producing

I never start with “make me this.” I start with a round of questions. The AI explores what already exists, then questions me: what scope, what constraints, what to keep, what to throw out. It proposes two or three approaches with their trade-offs, and I choose.

This step feels slow. It avoids AI's most expensive flaw: producing something coherent very quickly that answers the wrong question.

2. Write the spec

What was decided goes into a document: the goal, the scope, what's excluded, the rules to follow, and the criteria that will show the work succeeded. I review and approve it before anything gets built.

This document has two readers. Me, checking that we're talking about the same thing. And the AI, which refers to it for everything that follows. A conversation gets forgotten. A document stays.

3. Break it into a plan

The spec is then broken down into short tasks, each with its expected result and its check. Each task has to be something I can approve or reject on its own.

This breakdown is what makes the work manageable. I don't get a final result to take or leave. I get a series of small deliveries I can correct one at a time.

4. Execute in approved steps

Execution moves from checkpoint to checkpoint. At each important step, the work stops, the AI shows me what was done, and I approve or correct it before it continues.

I have one rule I apply everywhere: approve the first piece before rolling out ten. One page before the others. One component before the library. A correction made early costs a few minutes. The same correction made at the end means redoing everything.

5. Verify with checks, not trust

Nothing counts as done just because the AI says so. Every project has its own automated checks, suited to what it is:

• for code, tests that run on every change;
• for a website, performance and accessibility thresholds to meet;
• for a design file, an audit that counts hand-entered colors, unstyled text, and badly named layers.

An automated check has a quality a review doesn't: it never gets tired and it never makes exceptions.

Written rules, in every project

Each of my projects contains a context file the AI reads before it starts working. In it, I write down what shouldn't be debated again:

• key structural decisions, with the reasoning behind them. Not just “we do it this way,” but “we do it this way because”;
• constraints: the allowed spacing and type scales, the thresholds to meet, what's off-limits;
• conventions: the language used for names, the vocabulary to use, where the documentation lives.

A preference I keep in my head will be ignored. A written rule can be applied and checked. The whole point is to move as much as possible from the first category to the second.

I add one principle that matters a lot to me: nothing gets assumed silently. A color, a typeface, an effect, a structural choice: these are questions to ask me, not decisions to make for me. When AI fills a gap in information, it fills it with something plausible, which means often wrong.

Turning my method into a tool

This is the step that changed the way I work the most. When a method works, I don't re-explain it on every project: I write it down once, in a form the AI can load and follow.

That's how I formalized the way I design in Figma: the questions to ask before starting, the order of the phases, the non-negotiable rules, the approval points, the checks to pass before each step. I even listed the tempting shortcuts you need to learn to spot, like “I'll review everything at the end” or “I'll add a color, it'll make it richer.”

This work has two effects. The first is obvious: quality becomes repeatable. The second is less so: writing down your method forces you to clarify it. Rules I thought were clear weren't, until I had put them into words.

Every mistake I run into on a real project gets added to it: the symptom, the cause, the fix. The method improves with every project instead of starting from scratch.

What I hand off to it

Within this framework, AI comes in at four points.

Research and synthesis. Pulling themes out of a series of interviews, structuring a benchmark, mapping out a topic I don't know well. It tells me where to look. It doesn't tell me what matters.

The design system and files. Setting up variables, building components with their states, renaming, auditing, applying a change across an entire file. These are long, repetitive tasks, exactly the kind where a human ends up making exceptions.

Going from design to code. A file built with variables and components already describes the code to write. The AI reads that structure and translates it. Instead of handing developers an image to interpret, I bring them a working base we can discuss.

Writing. UI copy, content, specs, documentation. I provide the facts, it suggests the form.

Why AI rewards rigor

Here's what I've learned working this way: AI amplifies whatever method you give it. With a clear method, it saves an enormous amount of time. Without one, it creates a mess faster than any human could.

A clean file, written rules, work broken into steps, automated checks: these are exactly the habits of good design work without AI. AI didn't invent them. It made them pay off, and it makes you pay much more for skipping them.

That's also why wearing two hats, as a designer and a product manager, helps me here. Scoping a need, writing a spec, breaking down work, prioritizing, running QA: that's a product manager's everyday job. Working with AI means running a project.

The three limits I keep in mind

You have to review everything. AI is wrong with total confidence. It announces a task is done when a detail is missing, or presents an assumption as a fact. I verify with evidence: a test, an audit, a screenshot. Never on its word alone.

It doesn't know the user. It wasn't in the interviews, and it knows neither the field nor the constraints of the business. It can help me organize what I've learned. It can't learn it for me.

It flattens everything. Left to itself, it produces the average of what it has seen: interfaces that are fine and interchangeable. Art direction and taking a stance remain human decisions.

What I don't delegate

• Choosing the problem to solve. Knowing what matters for this client and these users is still my job.
• Trade-offs. Between two valid options, I'm the one who decides, and I own that decision.
• Art direction. AI executes a creative stance. It doesn't choose one.
• Relationships. An interview, a workshop, a disagreement with a client: none of that can be delegated.
• Final approval. Nothing goes out without me looking at it.

Where to start

If you want to bring AI into your practice, here's the order I recommend:

1. Write down your rules. Five or six sentences are enough: what's required, what's off-limits, and why.
2. Ask it for questions before answers. Let it scope the need with you before it produces anything.
3. Have it write down what was decided. Then review it before starting the work.
4. Move forward in small, approved steps. One first piece, then the rest.
5. Set up an automated check. Even a simple one. It's what will tell you the truth.
6. Log what went wrong. Next time, the rule will already exist.

AI doesn't replace method. It makes you pay more for lacking one, and pays you back faster for having one.