One answer should change something
Conversation gives us a way to learn about intent in someone’s own words. But every question asks for time and effort. I want that effort to earn its place.
If someone says the commute is making their current job difficult, the next question should help clarify the constraint. Their answer should then affect what the product shows or explains. A conversation that politely collects information without improving the experience has added work for the candidate.
That connection between conversation and consequence is the design problem I keep coming back to. What did we learn? What changes because of it? Can the person see the connection?
Constructed candidate example
A preference in context“I’d like a shorter commute. I’d consider hybrid, but it isn’t essential.”
One useful follow-up
What would feel like a manageable journey?
What changes in this example?
Choose an answer to see its authored consequence.
No job search runs here. The example shows how one answer can change what the product knows.
Make understanding visible
An agent can sound confident while misunderstanding something quite ordinary. “I’d consider hybrid” is a possibility. It isn’t necessarily a requirement.
I want people to be able to inspect what an agent thinks it knows and correct it. A preference should remain something they can recognise and change, with a clear distinction between what they told us and what we inferred.
This also affects how recommendations are explained. The explanation needs to connect a suggestion to useful evidence. When information is missing, the experience needs to leave room for that uncertainty.
Constructed example · inspect and correct
Preference editorWhat the candidate said
“I’d consider hybrid, but it isn’t essential.”
Stated in conversationWhat changed?
The example treats hybrid as useful, while keeping it optional.
A correction changes the demonstration locally; it does not update a SEEK account.
The seams are part of the experience
My work sits across product strategy, conversation design, information design and the details of the interface. The agent needs to make sense in the context of the product around it: where someone starts, what they can inspect, how they move on, and how they return to what they were doing.
That calls for a shared understanding across product, engineering and design. A screen can describe a moment. A clear account of the behaviour helps a team make consistent decisions across the whole experience.
I use prototypes and explicit experience principles to make those decisions discussable. The important question is whether the person can understand the next step and retain control as they take it.
Give it a useful way back
Recovery is part of the design. If the agent has misunderstood a constraint, the person needs a straightforward way to correct it and see what changed. If it cannot help, it should explain the limit and offer a useful route forward.
These are also things we need to evaluate. Did the response answer the person’s question? Did it treat an inference as a fact? Did it suggest an action that needed permission?
My evaluation tooling explores how to turn those concerns into focused checks. Margin makes a criterion and the exchange it applies to inspectable, so a reviewer can examine the result.
Where the work stands
This is ongoing work. I’m sharing the design questions and principles here; the examples above are constructed demonstrations. They do not show an unreleased SEEK workflow or claim a measured outcome for the agent.
The direction I’m working towards is simple: useful understanding, visible progress and enough control for someone to make their own next move.