What an AI Product Designer Actually Does
Somewhere in the last two years, my job changed without changing its name.
Most of the products I work on now have AI in them somewhere. And almost none of them are chatbots. A teaching app that uses AI to mark handwritten essays. Products where a model reads, judges, extracts or decides deep inside someone's working day. The founders who hire me don't say "I need a UX designer" anymore. They say "we built this thing on top of a model and people don't trust it," or "the demo is incredible and the retention is terrible."
That work has a name now: AI product design. Here's what it actually involves, because it's a genuinely different job, and most of the industry hasn't noticed yet.
The model is not the product
Every AI product starts with the same misconception: if the model is good enough, the product will work. It won't. The industry is spending trillions on capability and almost nothing on the moment a real person opens the product, can't tell what the AI just did, doesn't trust the result, and goes back to doing it manually.
An AI product designer works in exactly that gap. The model is a raw material, the way a database or a payment API is a raw material. The product is everything wrapped around it: the first-run experience, the trust signals, the failure states, the boundaries of what it will and won't do. Sora had the most impressive model on the planet and still wasn't a product. The difference between a demo and a product is design, and with AI that difference is wider than it has ever been.
Designing for a system that's sometimes wrong
This is the part that makes AI product design a different discipline, not just regular product design with a new subject.
Traditional software is deterministic. Same input, same output, every time. You design the happy path, you design the error states, and the boundary between them is crisp. AI products are probabilistic. Feed a model the same handwritten essay twice and it can return a careful, defensible mark, a mediocre one, or a confident misreading of what the student wrote, and the interface looks identical in all three cases.
So the design questions change. How does a teacher calibrate how much to trust the marking? What does the product show when the model's confidence is low, or the handwriting was barely legible? How does someone verify the AI's judgment without re-marking the essay themselves, which defeats the purpose? When the system decides on the user's behalf, how much of that decision is visible, and how easy is it to override?
None of these are model problems. All of them are design problems. And almost every AI product I audit has skipped all of them.
What the work looks like in practice
When I design an AI product, the visible interface is the last thing I touch. The real work happens in layers before it.
Scoping what the AI shouldn't do. The most important decision in an AI product is where the model stops and the human takes over. Ship it everywhere and you ship its failures everywhere. The discipline of deliberately not using the model is the same discipline as taste: knowing which of a thousand plausible options is actually right.
Fitting the AI into the workflow, not the other way around. The best AI products don't ask the user to operate the AI at all. The teacher doesn't prompt anything. They upload a stack of scanned essays, the marking appears inside the flow they already had, and the design question is where the AI's output enters that flow: before the teacher's own read, after it, or alongside it. Get that placement wrong and even a brilliant model feels like extra work.
Designing the review layer. When AI does the heavy lifting, the human's job shifts from doing to reviewing, and reviewing at speed is its own design problem. A teacher checking forty AI-marked essays needs to see the model's reasoning against the student's actual handwriting, skim the confident cases, slow down on the uncertain ones, and override without friction. Provenance, confidence, visibility into why the AI decided what it did. Trust is the currency of every AI interaction, and this layer is where it's earned. It's also where retention lives.
Designing the failure states. The wrong answer delivered confidently is the most dangerous screen in your product. An essay marked wrong isn't a bad chat reply someone can shrug off; it lands on a real student's work. What failure looks like, how it gets caught, how it gets corrected. Most teams design the demo path and leave the failure path to chance, which is why demos keep outrunning products.
What it isn't
AI product design isn't designing chatbots. Most of the AI products I work on don't have a chat interface at all, and the ones that lean on chat are usually hiding a workflow they haven't designed yet. It isn't bolting a chat window onto your existing app, it isn't prompt engineering with a Figma licence, and it isn't shipping AI features because the roadmap said AI, for a user who doesn't exist.
It also isn't hostile to the technology. I use AI tools daily and I've shipped a working app with them. The point isn't scepticism about the models. It's that the models were never the hard part.
When to bring one in
If you're building on top of a model, the honest checklist is short. Do users know what to do in their first session without instructions? Can they tell when the output is reliable? When the AI is wrong, does the product catch it or does the user? If any of those answers is "not really," you have a design problem wearing a technology costume.
That's the job. The vocabulary will keep shifting, the same way freelance designer became product design consultant. But the work underneath is stable: making probabilistic technology feel trustworthy, usable and worth returning to. That's what an AI product designer does.
---
