The short definition
An AI product designer designs products where the core experience is shaped by a probabilistic model.
Usually that model is an LLM. Sometimes it is a recommendation engine. Often it is both.
The defining feature is not that AI is present.
It is that AI shapes what the user sees, what the product says, what it recommends, what it asks, and how it changes after feedback.
That means the design surface is wider than the screen.
It includes:
- the system prompt
- the input data
- the output schema
- the retrieval context
- the ranking logic
- the confidence and uncertainty states
- the user correction path
- the interface that turns model output into action
The designer is not decorating the model.
The designer is shaping the conditions under which the model can produce a useful product experience.
How this differs from normal product design
Traditional product design assumes deterministic behaviour.
The user clicks. The system responds. The same input usually creates the same output.
AI products are not like that.
They produce distributions of better and worse outputs. They can be useful, wrong, vague, overconfident, slow, or surprising. They may need context the user did not explicitly provide. They may improve when corrected, or fail to learn anything at all.
That changes the job.
The designer still needs research, interaction design, information architecture, accessibility, visual judgement, and product strategy.
But those skills are now applied to a system that behaves probabilistically.
The work shifts from designing fixed flows to designing the conditions for good outcomes.
The prompt is part of the product
In conversational AI, the prompt is not implementation detail.
It determines tone, scope, role, reasoning style, refusal behaviour, recovery, response structure, and how the system handles uncertainty.
That is product design.
A useful system prompt reads like a design brief:
- role
- context
- user goal
- product goal
- constraints
- examples
- edge cases
- refusal rules
- output format
- escalation paths
If a designer never touches the prompt, they are not shaping the full experience.
They are designing the shell around the experience.
Day-to-day work
The day-to-day work falls into five buckets.
Prompt design and evaluation
Write prompts as design artifacts. Test them against real inputs, synthetic variants, edge cases, and failure modes.
This work often happens in model playgrounds before it appears in Figma.
Conversation and interaction design
Decide when the system should ask, act, suggest, confirm, refuse, or hand off.
Sometimes the right AI interface is a chat. Often it is not.
Schema and ontology work
Define what the system needs to know.
For job matching, that might include explicit preferences, inferred preferences, negative preferences, role taxonomy, skills, location, salary, seniority, and application state.
If the schema cannot represent the user's intent, the interface cannot rescue the product.
UX for probabilistic outputs
Design how the product shows confidence, uncertainty, missing context, hallucination risk, correction, latency, and generated content.
This is where trust is won or lost.
Closing the loop
Design what happens after the user corrects the system.
Does the next recommendation improve? Does the user see that improvement? Is the signal stored? Is it local to the session or durable?
Most AI products fail here.
What changed for me at SEEK
Working on AI-powered career discovery and recommendation products at SEEK made the role very concrete.
In GenAI Career Feed work, the design problem was not "put a chatbot in the feed."
The real problem was information gain.
How do we help candidates express richer intent with low friction? How do we collect hard preferences, soft preferences, and negative preferences? How do we turn that signal into better recommendations? How do we show candidates that the system understood them?
In the source measurement for that work, GenAI chat captured 21.4 preference entities per session compared with 2.3 per traditional search interaction: a 9x improvement in usable signal.
That result did not come from the model alone.
It came from designing the interaction, the questions, the schema, the prompt, and the feedback path together.
It is not the same as using AI
Using AI in your workflow is now table stakes.
A designer might use Claude for first drafts, v0 for UI generation, Cursor for prototypes, or an image model for concept exploration.
That is useful.
It does not make the product AI-native.
The distinction is simple:
If AI helps you do your work, AI is in your workflow.
If AI changes what the user experiences, AI is in your product.
An AI product designer works on the second problem.
The skills that matter
The core design skills still matter.
Research still matters. Accessibility still matters. Visual hierarchy still matters. Systems thinking matters more than ever.
The added skills are different:
- prompt design as a craft
- comfort working in model playgrounds
- data and schema fluency
- evaluation design
- understanding retrieval and ranking well enough to ask better questions
- designing for uncertainty
- designing correction loops
- cross-functional fluency with engineering, data science, legal, privacy, and risk
An AI product designer does not need to become an ML engineer.
But they do need to understand the material they are designing with.
Common mistakes
The mistakes are predictable.
Designing in Figma first
Figma is useful once the behaviour is understood. It is weak as the first tool for model behaviour.
Test the prompt and the model before polishing the screen.
Treating the LLM as a black box
If the designer cannot explain what the model sees, ignores, gets wrong, and needs help with, the design will be shallow.
Confusing chat with AI UX
A chatbot is one pattern.
Sometimes the better AI experience is a feed, a button, a ranked list, a short question, a generated summary, or a quiet background action.
Ignoring negative preferences
What the user does not want can be as important as what they do want.
If the product cannot remember negative preference, it will keep making the same mistake.
Collecting feedback that changes nothing
Decorative feedback damages trust.
If the user corrects the system, the product should use that correction or be honest about what it does.
How to become one
There are three practical paths.
First, ship an AI feature inside an existing product.
Do not stay at the concept level. Work with the prompt. Sit with the engineers. Look at outputs. Watch real users hit edge cases.
Second, build a small AI product yourself.
A small shipped product teaches more than a large deck. You will learn quickly where the model is weak, where the interface needs structure, and where users lose trust.
Third, learn to evaluate behaviour.
Create test sets. Score outputs. Compare prompt versions. Write down what "good" means before you ask the model to produce it.
That is the craft.
AI product design is not magic.
It is disciplined product judgement applied to probabilistic systems.
The role will probably disappear
The title may not last.
In a few years, product design may simply include AI-native craft by default, the way product design now includes responsive design without naming it every time.
But the underlying shift is real.
Models are now design materials.
Designers who can shape model behaviour, data context, evaluation, feedback, and interface expression will have more leverage than designers who only wrap AI output in a polished UI.
That is the job.
About the author
Richard Simms is Principal Product Designer at SEEK, where he leads design for the Career Discovery Agent and Career Feed. He also builds Sentiuma, a personal AI knowledge infrastructure layer.