The most common question I hear right now, from designers and from just about everyone who builds product, is some version of this: "How can I put more AI into my process? My brain is the bottleneck. What else can I automate?"
There's a smarter version of the question too, about where in the workflow AI actually pays off. But most of the time it arrives in the blunt form above, and I understand why. Deadlines are short, the tools are impressive, and everybody is being told to use them. Of course you want the machine to carry some of the load.
It's still the wrong question, and I want to explain why.
What is AI actually good at?
If we're being honest, AI is good at making stuff up. I don't mean that as a knock. Run the same prompt twice and you'll get two different answers, and that quirk makes it genuinely good at one thing: variations. Hand it an idea and it will give you five more versions of it, each built on a different assumption, faster than you could sketch one. It's good at the flip side too: show it your work and it will say there's a hole here, this part doesn't add up, here are three ways you might fix it.
Notice what those have in common. They are the divergent half of thinking. Throwing options onto the table. Naming what might be wrong. That is the half AI is built for, and it's faster at it than any human.
What it can't do is the convergent half. Deciding which of those five variations is right for this product, this user, this moment. Deciding which of the three holes actually matters and which is noise. That is judgment, and judgment is the whole job. AI can widen the field of options; it cannot pick. The moment you let it pick, you've handed away the only part that was ever yours.
And you should keep that part even if the tools get good enough to pick well. Set aside whether AI could someday think like you. The more durable point is that you are accountable for the outcome, and the skill only grows in the person who does the reasoning. Outsource the thinking and you outsource the one thing that was building you. It's also true that today the machine doesn't carry your years of watching real users struggle, or your product's history, or your team's scar tissue. But lean on that and your argument expires the day the tools improve. Accountability and growth don't expire.
So the worst use of AI is, unfortunately, a common one: "Here's the PRD, give me a UI." That's outsourcing the thinking, and it fails in a specific way. People wind up presenting work they can't defend, because they never formed the opinion the work is supposed to express. The screen exists; the reasoning behind it doesn't, and the first hard question in the review exposes it.
The better move is the opposite one, and not everyone agrees with me here. Don't ask AI to think for you. Ask it to attack your thinking. Some of the best growth of my career came from building products next to other designers, day after day. Not once did I ask one of them to do my thinking for me. I asked for feedback on my thinking so I could make it better. AI deserves the same job description, with one warning I'll come back to: a good colleague pushes back, and AI, left alone, does the opposite.
I've turned this into a daily practice. I call it the Critique Loop.
The Critique Loop
The rule is simple. You think first. AI critiques second. Never ask AI to design something you haven't already formed an opinion about. If AI produces the first idea, you've outsourced the thinking. If AI attacks your idea, you've multiplied it.
You don't run this on every decision. A fifteen-minute loop on every button and margin would be its own kind of paralysis, and it would betray the deadline pressure that started this whole conversation. Run it on the decisions that are consequential or hard to reverse. Those are the ones worth the fifteen minutes.
Step 1: Write your JTBD statement (2 minutes)
One sentence: "When [situation], the user wants to [motivation], so they can [outcome]."
If jobs to be done is new to you, start with Clayton Christensen's Competing Against Luck. He made the framework famous, and the book earns its reputation.
If you're improving something that already exists and you can't write that sentence, you're not ready to design yet. Go back to the problem. That's not a failure, that's the step doing its job. If you're doing genuine zero-to-one work, the sentence may not come first, and that's fine. Sketching is sometimes how you find the job. Just arrive at the sentence before you hand anything to AI, because the loop needs it as the yardstick.
You can use AI in this step for one thing: gathering inputs. Prior art, existing patterns, what's already out there. Just don't let it hand you the opinion. Research feeds your judgment; it doesn't replace it.
Step 2: State your guardrails (2 minutes)
List three to five constraints your solution has to respect. Things like "must be learnable without a tutorial," "can't add a step to the core flow," "must work within the existing component library."
Don't skip this one. AI loves inventing from scratch and gets careless inside boundaries, and real product work is almost never blue sky. You're working inside an existing product, an existing system, an existing user's head. The guardrails keep the machine honest.
Step 3: Make your proposal
A sketch, a wireframe, a written description. Your first answer, from your own head. Rough is fine. This is the thing AI is going to attack.
Step 4: Feed it to AI with this prompt
"Here is the job to be done: [JTBD statement]. Here are my guardrails: [list]. Here is my proposal: [describe or attach].
- Critique this proposal. Where does it fail the job or violate a guardrail? What am I not seeing?
- Give me three alternative options that satisfy the same job and guardrails, each based on a different assumption than mine.
- For each alternative, tell me what it assumes about the user that my version doesn't."
Look at what you're asking for. Not "design this for me." You're pointing the machine at the two things it's built for, finding holes and generating variations, and making it do both against criteria you set.
One warning. These tools flatter by default. Left alone, most of them will tell you your proposal is strong and offer a few polite tweaks. That is useless, and it's the opposite of a colleague who disagrees. The prompt above is built to fight it, but you have to hold the line: if the critique comes back as mostly praise, reject it and tell the model to find the real holes.
Step 5: Decide, and write down why (3 minutes)
Keep, change, or replace your proposal. Then write two or three sentences on why. Something like "I kept my version because the alternatives all traded ease of use for density." That's critical thinking made visible, and it's what you show stakeholders.
Be honest at this step, because it's where the loop can quietly rot. If you keep your original every single time, you're not running the loop, you're staging it, generating alternatives you were always going to reject so you can feel rigorous. The test: can you steelman the best alternative, argue it as hard as its author would, and still choose yours? If you can't, the alternative just won, and the loop did its job.
This isn't just for designers
I wrote the loop in design terms because design is my discipline, but nothing about it is design-specific. Swap out the proposal and the loop works anywhere in product development.
A product manager can run it on a PRD before sharing it: here's the job, here are the business and technical constraints, here's my proposed scope, attack it. An engineer can run it on an architecture sketch or an API design. A researcher can run it on a discussion guide. A marketer can run it on positioning. The JTBD statement and the guardrails translate directly, because every discipline answers the same two questions: what is this for, and what are we not allowed to break?
The failure mode translates too. "Here's the PRD, give me a UI" has an equivalent in every role. "Here's the feature, write me a spec." "Here's the ticket, write the code." Same trap, same result: output you can't defend because the thinking never happened.
Why this grows your thinking instead of replacing it
Steps 1 through 3 force you to articulate. Vague thinking can't survive being written down. A lot of what we call intuition is really just assumption we've never examined, and writing the JTBD sentence and the guardrails drags it into the light.
Step 4 shows you your blind spots. Every alternative the AI generates is built on an assumption you didn't make. Do this for a few weeks and you start to learn the failure modes of your own instincts, which is exactly what sitting next to a stronger colleague used to teach you.
Step 5 is where judgment gets built, and judgment, remember, is the convergent half the machine can't do for you. Choosing between defended options is the whole skill. There's a flywheel in it too. Over time your Step 3 proposals get stronger, because you've internalized the critiques. You're not just shipping better work. You're becoming a better thinker, and that was the actual job you hired the AI to do.
One more thing. When a manager says "show me your critical thinking," they're saying what your algebra teacher used to say: show your work. Showing your work is a part of this craft that got lost long before AI came along. The loop produces the paper trail on its own. A JTBD statement, explicit constraints, a defended decision. About fifteen minutes on a decision that deserved it, and you walk into the review with your reasoning already written down.
You don't have to be Einstein
Here's the fear I think sits underneath the "how do I automate more of this" question. Plenty of us are comfortable improving something that already exists, but zero-to-one work feels different. It feels like it demands a kind of brilliance, like you have to conjure the whole answer out of nothing, alone.
You don't. But you can't hand the brain part to the machine either. Form your own answer first, however rough. Then use what I think is the best learning tool to come along in decades to pressure test it.
Never outsource the thinking. Multiply it.