How to AI: co-designing your work with AI in 5 modes

Starting is the hardest part of every task I get.

I can see the whole challenge. I just can’t see the first step. So I brainstorm, sketch, and write a long description of the work before any of the work happens. All of that just to get a clear picture in my head and catch the corner cases.

I’m a Lead Product Designer at Railsware, and design is only part of what I do. I also write documentation, draft tasks, build presentations, and answer a lot of emails.

AI helps with all of it. It started helping a lot more once I stopped thinking about tools and started thinking about modes.

Figma’s State of the Designer 2026 surveyed 906 designers. 72% of them now use generative AI in their workflows, and 98% increased their usage over the past year. So the question now is not about AI usage itself, but about the right organization of your work around it.

I use five: Think, Bird’s-eye, Get it done, Explain and hand off, and Control. The same five work for a design concept, a PRD, or a marketing page. None of them is exotic. The value is in knowing which one you’re in.

TL;DR

• Think: let AI interview you before you commit. Describe the rough idea, then ask it to find the weak spots and the corner cases you’ve missed. Voice input is faster than typing.
• Build a knowledge base before you need it. Call notes, decisions, and exported AI sessions in one folder per project. More context in, fewer hallucinations out.
• Bird’s-eye: turn your documents into a diagram. A visual shows you where you and the AI aren’t actually aligned, while it’s still cheap to fix.
• Get it done: split the boring work across agents. Write the brief, approve the plan, then run tasks in parallel and pick the model that fits each job.
• Explain and hand off: sandbox and guardrails first. Agents get an isolated environment and written rules before they start, not after.
• Control: you make the final call. AI gets you a strong draft. Review is fast when the context is there, and it’s never optional.

Why modes, not tools

Modes stay stable while tools don’t.

Every few months a new model or plugin changes what’s possible. If your process is built around one specific tool, you rebuild it every time something ships. Build it around modes and you just swap the tool underneath.

The second reason is that a task is the wrong unit of work. “Write the PRD” isn’t one job. It’s thinking, then structuring, then drafting, then reviewing. Each part needs different input from AI and different attention from you. Treating them as one block is why AI output so often comes back close but wrong.

Splitting by mode fixes that. You know what you’re asking for, and you know what you still have to check.

It also means none of this is designer-specific. Marketing, people team, development. The modes don’t change, only the work inside them does.

Mode 1. Think: let AI grill your idea

The first thing I do with a new task is ask AI to interview me about it.

I give it a rough description of the idea, then ask it to find the weak spots. Not to agree with me, and not to write anything yet. Just to cover every corner case and every small detail I haven’t thought about.

Matt Pocock built a skill for exactly this called grill-me. There’s also a newer batch-grill-me, which makes the interviewing more detailed. Both are worth installing, but the technique works without any skill at all. You can just ask.

Here’s the shape of the prompts I actually use:

Design. I’m working on a what-if mode for the app. The idea is to let a person toggle settings and see how it affects the final finances. Grill me on all the weak spots and the worst parts of this idea.

Documentation. I’m setting up a single repo for all project documents. Grill me so I get a clear picture of how to organize it.

Marketing. I’m thinking about starting a build-in-public campaign for my pet project. Grill me on how we should do it.

Two habits make this mode much faster.

The first is voice. I hate my own voice, but talking is quicker than typing, especially when several things are running at once. In Claude you hold the space bar. On a laptop, a tool like Whisper does the same across every app.

The second is admitting what you don’t know. A lot of people seem uncomfortable saying that to a model. I say it constantly. If something feels missing, or I have no real context on a topic, I tell it so and ask it to interview me as if I know nothing. It’s okay to know less than AI.

Build a knowledge base before you need it

Everything you know about a project lives in your head, and AI has none of it.

That’s why answers drift. The model offers branches and conditions, follows whichever direction your answers push it, and eventually starts inventing. The deeper you go into details, the worse it gets. At some point you restart the session and lose everything.

So I built a habit. Every project gets one folder that holds its memory.

project-x/
  call-notes/        every meeting, AI-noted
  granola/           auto notes from calls
  sessions/
    gpt-sessions/    threads that mattered
    gemini-sessions/

Call notes go in first. We already generate AI transcripts of our calls, so it costs nothing to keep them somewhere proper. Recordings and decisions go in too. Even the small talk is worth keeping, because good ideas often come out of it and nobody writes those down.

For calls I can’t capture any other way, I use Granola. It handles different languages and records things like phone or WhatsApp calls. You export the notes and drop them into the folder.

The part most people skip is exporting AI sessions. I work across Claude, ChatGPT, and Gemini, so I group conversations by project inside each tool and then export them into the same folder. Web chats, desktop chats, and Claude Code sessions all go in. Grouped that way, I can point at one specific past conversation instead of re-explaining it.

A few commands make this cheap to maintain: /compact, /export, /memory, and /recap. Recap in particular changed how I work. It keeps me and the tool on the same page without rebuilding context by hand.

The payoff is simple. More context in, fewer hallucinations out.

Mode 2. Bird’s-eye: make the whole thing visible

Bird’s-eye is where you turn all that written context into something you can actually look at.

Because here’s what Think mode leaves you with. A knowledge base, yes. Also a pile of markdown files, HTML files, and exported sessions that nobody is going to reread. I’m not sure most people even open them again after the day they were created.

That pile has three problems. It’s hard to discuss with the team. It’s hard to navigate. And it’s impossible to get an overview from. Try coming back to it after a vacation and you’ll see what I mean.

None of this is new thinking. We’ve always used diagrams, user flows, and whiteboard sessions, for exactly this reason. They’re easier to operate with and easier to talk about.

What’s new is that it now takes about ten seconds.

Almost every tool has an MCP or some kind of integration. Figma MCP, Obsidian, Notion. Even PowerPoint connects to Claude Code now, which is how I built the deck this article comes from. So ask AI to move your documents into whichever format suits you and your team, and let it do the work.

The diagram shows you where you and the AI disagree

This is the part that saves weeks, and it’s why I call the mode bird’s-eye.

You can feel like you’re perfectly aligned with a model. Then you go into action, and it loses context somewhere. It misses corner cases that look obvious to you. You don’t find out until you’re already building.

A diagram surfaces that gap early. On one project, the visual made it clear we’d proposed a feature and then never touched it. Not in design, not in code. It had just quietly fallen out of work. Nobody would have caught that reading through documents.

It also shows you the difference between how AI understands the project and how you understand it. Those are rarely the same thing.

Edit the picture, not the documents

The other benefit is that a diagram is easy to change.

When you spot something wrong, or the team adjusts the plan during a session, you edit the diagram. Then you feed it back to AI and it updates every document you created earlier, in seconds.

That’s much faster than another long chat trying to explain what changed.

Mode 3. Get it done: clear the busywork in parallel

Get it done is where the work finally leaves the planning stage, and most of it goes to agents.

I hate boring things. Unfortunately, the interesting part of any job is rarely the biggest part of it. There are Jira tasks to prepare, documents to draft, updates to write, emails to answer, and Slack threads that have been waiting three days. If they all relate to the same project, most of that can be automated.

This is where the previous two modes pay off. With the documents written and the visualization done, it’s much easier for you and for AI to produce a real PRD and a real plan.

The flow I use has four steps:

1. Make a PRD. Turn the work into written requirements first.
2. Research the real thing. Send it to look at the market and the competitors. It regularly finds companies I’d never heard of and that turn out to be more relevant than the ones I had in mind.
3. Review and approve. You read the plan and the research before anything gets built. This step is yours.
4. Split across agents. Then the work runs in parallel.

Every job gets its own crew

Different tasks need different agent line-ups. Research, drafting, design system, copy, whatever the job needs.

Setting this up used to be the hard part. Now current models propose a solid agent set on their own, and sometimes split the work automatically. Your job is calling the right one and keeping track of what each is doing.

If you’re not sure what crew you need, go back to Think mode and brainstorm it. That applies whenever you feel unsure about direction. Loop back, grill one specific small thing, then keep moving. The sooner you do it, the better the results.

Pick the model that fits the job

Different models are good at different things, and you don’t have to commit to one.

One brief, the right model for each job. If you’re comfortable with APIs or other harnesses, you can run all three inside the same session.

What I actually hand over

Three categories, in practice.

Diagrams, in versions. User flows, project flows, content structure. I ask for several options with the pros and cons of each spelled out, then react to them.

Concepts when I’m stuck. Sometimes I can’t get my brain to start drawing. A new navigation, a document template, anything that gives me a starting point I can push against. That initial shove is worth a lot.

The boring stuff. Dev docs, deck design, copy sweeps, Figma component fixes, color updates everywhere. On one product I was updating the design system twice a week. Dozens of buttons, plus the tedium of checking nothing broke. I asked AI to build me a couple of Figma plugins instead, and I still use them for adjusting tokens and making screens feel more native.

Honestly, sometimes I hand over everything and see how it goes. When the output is bad, that’s when I step in.

Mode 4. Explain and hand off: make it usable by the next person

Explain and hand off runs in parallel with Get it done, and it decides whether the work survives contact with anyone else.

The next person might be an agent. It might be a teammate picking this up next week. It might be you, three months from now, with none of the context you have right now. The problem is the same in all three cases. Everything obvious to you is invisible to them.

to-prd as the bridge

For dev or UX tasks, turn the work into a PRD before anything else happens.

The to-prd skill does this well, but the format matters more than the tool. A written brief means nobody has to come back and ask you questions. Useful, though not mandatory. Some tasks are small enough to skip it.

Give agents a sandbox

Agents work in an isolated environment, never on production files.

You can ask AI to set the sandbox up if you don’t know how. What you get is a space where nothing can be broken, and you share the result once you’ve checked it. This isn’t paranoia. It’s the difference between a bad output you delete and a bad output you have to untangle.

Write the guardrails down before they start

When I can’t create an isolated environment, I write rules the agents can’t cross.

Maybe I am paranoid. I don’t like running in auto mode and accepting everything by default, so I review as I go. But sometimes I need to move faster and turn it on anyway. That’s when guardrails matter, because the real risk is an agent quietly changing something built by someone else.

For a personal project, mine cover git and remote access, secrets, filesystem scope, destructive operations, system integrity, network, and logging. Concrete rules, not principles. No pushing to the remote. No commits to main. Never ask for or store credentials. All writes are confined to one folder. Anything genuinely irreversible needs explicit human approval. Every meaningful action logged with a timestamp, so the whole run is reviewable afterwards.

Yours will look different. The point is that they exist in writing before the agents start, so nothing has to be guessed.

And once all of this is in place, you can hand the work to actual people too. That’s the same job.

Mode 5. Control: you own the final call

AI gets you a strong draft. It doesn’t get you a finished one.

This mode is obvious, which is exactly why people skip it. Even with a knowledge base, clean guardrails, and a well-written PRD, review is faster but never unnecessary. There will be leftovers. Corner cases handled badly. Tasks that look solved and aren’t. Confident nonsense, because models hallucinate and because nobody reads the PRD as carefully as they think they did.

So review the work. Every time.

Automate the review where you can

Reviewing everything by hand defeats the point of delegating.

For developers, the straightforward version is running several agents to review each other’s work. I do the same outside code. When I need to write ten or fifteen emails in a day rather than one, I have AI check the copy and the tone before anything goes out. It’s much easier than writing each one from scratch and rereading it yourself.

“I have weird feelings about this slide”

That sentence is a real prompt, and it works better than it should.

I used it while building the deck this article came from. That was the whole input. I couldn’t say what was wrong, only that something was.

AI diagnosed it. Half the slide duplicated other slides. It proposed cutting the noise and keeping the one genuinely new thing. I read the reasoning, agreed with it, and approved the fix.

That’s the shape of the mode. Say what you feel even when you can’t articulate it, let it find the actual issue, then read the explanation and decide for yourself. Don’t approve blindly.

Everything in that presentation was built this way. Grilled, outlined, reviewed, then approved. The only things I made by hand were the screenshots.

Taste stays human.

From PRD to Figma MCP: how I actually design

The five modes are role-agnostic, but the design question came up in the room, so here’s my actual flow.

I don’t start with a design tool. I start in code.

The sequence goes PRD, then prototype, then Figma. Once I have requirements, I build the concept in HTML or React with Claude and play with it there until it feels right. When I have a version I’m happy with, I move it into Figma through Figma MCP and adjust it there. Sometimes I let AI make those adjustments, sometimes I do them myself.

If a design system already exists, the whole thing goes considerably faster.

The reason I work this way is that code is easier to iterate in than a canvas. I can try several directions quickly and react to them, which is the same principle as asking for diagrams in versions.

On Claude Design

I try it about once a week, and I’ve done that since it launched. I still can’t use it for real work.

It makes junior-level design mistakes. Spacing, padding, heading hierarchy. The basics. And it does this even when you give it everything. A Figma file, a design system markdown file, a link to the Storybook. It still comes back with problems.

So for now it’s a no from me. I hope that changes, because the idea is right.

Claude Code with the flow above is faster and gives me better results.

What AI still doesn’t do

Everything above makes me faster. None of it makes me optional.

It doesn’t have your context, and it never will completely. Everything you know about a project is your experience, your vision, your domain knowledge. A knowledge base narrows that gap. It doesn’t close it.

It loses the thread during the long work. The deeper into details you go, the more it drifts. That’s the whole reason Bird’s-eye exists as a mode. You need a way to catch the drift before it costs you.

It’s confidently wrong. Output that looks finished often isn’t. Reviewing it is not a formality you can automate away entirely.

It’s weak at design fundamentals. See above. Spacing and hierarchy are still a human job, and I’d rather ship nothing than ship something with junior mistakes in it.

It doesn’t decide anything. It proposes. Which option ships, which idea is worth building, whether the result is good enough. Those are yours.

The gap between a strong draft and finished work is judgment, and that’s still the job.

Start Monday

You don’t need to adopt all five modes at once. Pick one thing and try it this week.

Split your work by mode rather than by task. Keep an eye on what you’re doing at each step. That’s the whole method.

Think. Bird’s-eye. Get it done. Explain and hand off. Control.

FAQ

Split the work by mode, not by task

Starting is still the hardest part. That hasn’t changed.

What changed is that I no longer sit with the whole task at once. I know which mode I’m in, what I’m asking AI for, and what I have to check before it goes anywhere. Think when I don’t have clarity. Bird’s-eye when I have too much text. Get it done when the plan is solid. Explain and hand off before anyone else touches it. Control at the end, always.

Five modes, any role, any tool. Try one this week.