Key takeaways
- "AI UX designer" names two jobs: designing a product with a model inside, and designing any product with a model at your side.
- Both ask for what the model does not supply: judgement about trust, error and control, and the ability to defend it.
- Listings for the first job ask how the interface shows confidence, sources, limits, waiting and recovery; prompting appears as prototyping, not as the job.
- With a model at your side, the draft is the average of its genre and can rebuild the brief's problem exactly, so the decision stays yours.
- Show it with one feature or one brief: three short decisions on trust, error and control, plus what you kept and why.
An AI UX designer is two different jobs sharing one title. In some listings it means designing a product with a model inside it; in others, designing any product with a model at your side. If you came looking for a tool that generates screens, this is about the role instead. Both versions ask for the same thing, and it is not prompting: judgement about trust, error and control.
Prompting is the visible part, and every colleague can learn it from the same tutorials. Deciding how much a person should rely on a machine, what happens when it is wrong and what stays in human hands is harder, and it is what the better listings are hiring for. Here is how to read them and show you have it.
Two jobs behind one title
The first job is designing for a model. The product has a model inside it that writes, ranks, summarises or acts, and your work is the behaviour around it: what the person sees before, during and after the model does its part. Users never meet the prompt. They meet a screen that either earns their reliance or does not.
The second job is designing with a model. The product may have no AI in it at all, but the team expects you to draft, explore and prototype with one, and to move faster because of it. Here the model is your collaborator and the user never knows it was involved. What they meet is the decision you made after the model handed you its draft.
Some listings mean both, and plenty use the title loosely. Either way, the two jobs ask the same three questions, pointed in different directions: towards your user in the first, towards yourself in the second.
What the listings ask for, once you skip the tool names
Read a handful of current listings for the first job and the vocabulary repeats. They ask you to show the system's status, where an answer came from, how confident it is and what it cannot do. They ask for flows that survive the wait while the model responds, for error and recovery states, and for designs that keep the person in control. Prompting appears too, usually as prototyping with a model to test what it says.
Sort that list into three piles. Trust: how much the person is asked to rely on the output, and on what evidence. Error: what a wrong answer looks like when it arrives, and how the person gets back. Control: what the machine does alone, what it only proposes, and what the person decides. None of the three is a prompt, and each is decided before anyone writes one.
The listings for the second job are vaguer: AI tools in your workflow, faster iteration, rapid prototyping. Underneath, the same three questions point at you: how far you trust a draft, how you catch where it is wrong, and which decisions you refuse to hand over.
Trust, error and control with the model in the product
Take an assistant that triages a support queue. The model can read every ticket and propose a label in seconds; that part is solved. The design work is everything around the proposal. How sure does it look, and is that the truth? What does the lead see when it misroutes an outage ticket? Can they undo a whole batch in one move, or only one ticket at a time?
A chat box answers none of those questions, which is why designing for AI beyond the chat box starts from a contract instead: autonomy by moment, a preview before anything commits, visible provenance, an obvious undo and a failure shape decided in advance. Every clause in that contract is a trust, error or control decision.
The hardest version is a model that tells people something about themselves: a summary of their habits, a reading of their taste, a pattern in their data. A model will produce a confident pattern from three inputs. A real moment of insight needs enough input to say something true and outcomes that differ between people; if every path ends in the same conclusion, it is not a diagnostic. Deciding when the product knows enough to speak, and what it says when it does not, is trust and error in one call.
Trust, error and control with the model at your side
Now the second job. Plain Speech, one of the practice briefs on Quest, is a six-person brand voice agency whose service page is written in the language it claims to cure. Its visitors are marketing leads who already bought one beautiful deck that nobody used, and they arrive sceptical. The objective is a page that proves the promise by being the promise: the visitor should finish it knowing exactly what they get.
Ask a model for that page and you get what the brief describes as the starting design: a hero with an abstract headline about storytelling, three service cards for strategy, voice and messaging, a logo wall, a long manifesto and a "Let's talk" button in the footer. It is competent, the average of every agency page, and the brief's problem rebuilt exactly. Nothing in it looks wrong, which is the trap.
Trust here is how far you rely on that draft: as far as the layout, and not one word further. The error is not visual, so you only catch it by reading the draft against the brief. Control is the decision you keep: replace the abstract headline with what lands on Monday, and who has to be in the room. The brief also targets insight, and the opening is in plain sight: name the deck nobody used, the thing every visitor felt and nobody said.
Where prompting fits
None of this makes prompting useless. Writing a clear instruction for a model is the same skill as briefing a junior designer well: the context, the constraint and the standard you will judge the result against. It is worth learning, and it is learned fast, which is why it rarely decides who gets the job.
What a prompt cannot do is decide what the output is allowed to do. It can make the model sound confident or cautious; it cannot decide whether this product, at this moment, should ask for confidence at all. That call sits upstream of every prompt, and it is what the listings mean when they mention confidence, limits and control.
How to read an AI UX designer listing
Before you apply, work out which job the listing describes. Confidence, sources, failure states, waiting and recovery, or a seat next to a machine learning team: that is the first job, designing the behaviour of a model in front of users. AI tools, speed and output: that is the second, and the interview question is which decisions you will own. A role that only buys speed is buying the cheapest thing in the room.
If it asks you to ship interface changes in code, it is closer to a third role: a design engineer hands over the interface users actually get, not a file someone else rebuilds. And if the listing is only a row of tool names, with no mention of users, errors or decisions, it describes the tools, not the job.
How to show you have it
The question to prepare for the first job is the one every AI feature eventually meets: what happens when the model is wrong? Answer with a design, not a principle. Pick one AI feature, real or from a practice brief, and write three short paragraphs: what the person relies on and the evidence they see, what a wrong answer looks like and how they recover, and what stays in their hands. That page says more than ten generated screens, because no model wrote it.
For the second job, show the draft. Put the model's first version next to yours and write what you kept, what you changed and why, in the brief's terms. The vocabulary for that why is finite: the skills library names the mechanisms one at a time, from mental simplicity to authority, so your reason reads as a mechanism rather than a preference.
Where to start this week
Take one AI feature you use every day and answer the three questions for it in writing. Then take one brief, generate its plain draft and name, in a sentence, the decision that draft did not make. Both train the same muscle: deciding what a machine's output is allowed to do, and saying why in terms someone else can check. That is the job behind the title, whichever meaning the listing had in mind.
And if the question underneath this one is whether the job is still worth training for, the honest answer, without the reassurance and without the funeral, starts where this post ends.
You are a senior product designer who has shipped AI features, reviewing how I think about one of them. The feature: [describe the AI feature and what the model does]. The user and their moment: [who uses it, when, and what is at stake if the model is wrong]. Do not suggest prompts, models or new features. Answer three questions about the design, each with a verdict and one line of evidence taken from what I wrote: 1) Trust: what is the user asked to rely on, and is the evidence they see proportionate to the risk? 2) Error: what does a wrong answer look like when it arrives, and can the user recover in one move? 3) Control: what does the model do alone, what does it only propose, and what does the user alone decide? Then name the weakest of the three and write one sentence I could say in an interview to defend how I would fix it.
Frequently asked questions
What does an AI UX designer do?
It depends on which of two jobs the title means. Designing a product with a model inside, the work is the behaviour around the model: how much the user is asked to rely on it, what a wrong answer looks like and how they recover, and what stays in their hands. Designing with a model at your side, it is deciding what to keep and change in the model's draft, and why.
Do AI UX designers need to know how to code?
Not for most roles. The first job needs fluency in how models behave: they can be slow, they sound sure when they are not, and they are sometimes wrong. Prototyping with a model helps you test what it says. If a listing asks you to ship interface changes in code, it describes something closer to a design engineer.
Is prompting a design skill?
Partly. Writing a clear instruction for a model is the same skill as briefing a junior designer: the context, the constraint and the standard you will judge the result against. It is worth learning and it is learned fast. What it cannot do is decide what the output is allowed to do, and that decision is what AI UX roles are actually hiring for.
What does designing for trust in an AI product mean?
It means deciding how much the person is asked to rely on the model's output and giving them evidence in proportion: a short reason, the sources, a preview before anything commits. Trust is designed together with error and control, meaning what a wrong answer looks like, how the person recovers and what only they decide. The full contract is in designing for AI beyond the chat box.
How do I show AI UX skills in a portfolio?
Pick one AI feature, real or from a practice brief, and write three short paragraphs: what the person relies on and the evidence they see, what a wrong answer looks like and how they recover, and what stays in their hands. For work made with a model, show its first draft beside yours and explain what you kept, what you changed and why, in the brief's terms.
