The prompt is part of the product
A conversational AI product is not only the chat window, input field, loading state, and message bubble.
The system prompt decides how the product behaves when the user says something messy, vague, emotional, contradictory, or outside the system's scope.
It controls things like:
- tone
- role
- constraints
- response length
- question style
- what the assistant should never say
- when to ask a follow-up question
- when to offer choices instead of open text
- how to recover from misunderstanding
- how to handle uncertainty
Those are design decisions.
If designers do not shape the prompt, they are not shaping the full experience. They are designing around the model instead of designing with it.
Start with the model, not the mock-up
The fastest way to design weak conversational AI is to start with an ideal transcript.
Ideal transcripts are too neat. They hide the real work.
Real users do not behave like prototype users. They say things like:
- "idk, something more creative maybe"
- "I hate my current job but I do not know what I want"
- "I want more money, less stress, and a startup vibe"
- "Can you just apply for me?"
The design work starts when the model has to respond to that.
Use a model playground early. Test the system prompt before the interface is polished. Watch where the model becomes vague, too verbose, overconfident, or unhelpful.
Then design the UI around the behaviour the model can reliably produce.
Write the system prompt like a design brief
A system prompt is a brief to the model.
It should include role, context, goal, constraints, examples, and recovery rules.
A weak prompt says:
You are a helpful job search assistant. Help users find jobs.
That gives the model almost no product judgement.
A stronger prompt gives it the product context:
You are a career advisor on SEEK.
Your role is to help candidates express what they are looking for in their next job,
so the product can show more relevant recommendations.
Your goal is to understand:
- role type, seniority, and function
- location and work type
- what the candidate wants to avoid
- whether they are actively applying, exploring, or just curious
Guidelines:
- Ask one question at a time.
- Keep responses short.
- If the candidate is uncertain, normalise that uncertainty.
- Do not make salary promises.
- If the request is outside scope, redirect to job preference discovery.
The second prompt is not just better writing.
It is clearer product design.
Test edge cases first
Happy paths are not enough.
Conversational AI fails in the long tail. That is where trust is lost.
For job-matching conversational AI, useful edge cases include:
- the candidate is burned out
- the candidate gives a very short answer
- the candidate gives contradictory preferences
- the candidate asks the system to do something it cannot do
- the candidate uses jargon or unclear language
- the candidate asks whether the assistant is a real person
- the candidate gives a negative preference, such as an industry they want to avoid
For each case, ask:
- Is the response honest?
- Is it useful?
- Is it too long?
- Does it move the conversation forward?
- Does it preserve user control?
- Does it ask for the right next signal?
This is UX QA for model behaviour.
Use synthetic variants
Prompt design gets better when designers stop testing one input at a time.
Use the model to generate variations of real user intent, then run those variations against the prompt.
For example:
Generate 15 different ways a job seeker might answer:
"What kind of role are you looking for?"
Include:
- confident candidates
- uncertain candidates
- frustrated candidates
- candidates changing career
- candidates who give too little information
- candidates who give too much information
Now you have a test set.
Run the same prompt against all of it. Score the responses. Look for repeated failure modes. Revise the prompt. Test again.
This turns prompt design from taste into evidence.
Conversation is not always the right pattern
One of the easiest mistakes is assuming that conversational AI needs a chatbot.
It does not.
Conversation is one interaction pattern. Sometimes the better experience is a structured feed, a short question, a set of suggested answers, a nudge, or a button that runs an LLM call quietly in the background.
In recommendation work, the useful pattern is often not open-ended chat. It is high-quality preference capture.
That can mean:
- ask one focused question
- offer structured answers
- keep free text available for nuance
- show what the system heard
- make correction easy
- feed the signal back into the product
The point is not to make the product feel like chat.
The point is to capture better intent with less effort.
Patterns that work
These patterns are useful when the conversational surface is the right choice.
Start broad, then get specific
Begin with the preference the user can answer easily. Then move toward details.
"What kind of role are you looking for?" usually comes before "Which industries do you want to avoid?"
Acknowledge and advance
After the user gives a signal, reflect it briefly and ask the next useful question.
Do not make the user wonder whether the system heard them.
Keep model responses short
Long assistant messages break the rhythm.
For turn-by-turn exchanges, two or three short sentences are usually enough.
Show what was captured
After a few turns, summarise the preference model and let the user correct it.
This is not just confirmation. It is a valuable feedback loop.
Never dead-end
If the user is stuck, offer options.
If they are uncertain, normalise uncertainty.
If the system cannot do something, say so and offer the next best path.
What designers should own
Designers do not need to own every technical detail of the LLM stack.
They do need to own the parts that shape the user experience.
That includes:
- the role of the assistant
- the tone of the system
- the questions it asks
- the order it asks them in
- the signals it captures
- the negative preferences it supports
- the recovery behaviour
- the explanation pattern
- the feedback loop
- the moments that require user confirmation
Prompt design sits next to conversation design, UX writing, information architecture, and service design.
It is not separate from product design.
It is where much of the product design now happens.
The practical rule
Do not wait for a finished UI before testing the prompt.
Work in the model first.
Find the behaviour. Stress-test it. Shape the constraints. Learn what the model can and cannot do. Then design the interface that makes that behaviour useful, legible, and safe.
The prompt is not the whole product.
But in conversational AI, it is one of the main places where the product gets decided.
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.
