Human-centered and user-centered design are about to mean different things.
For most of my career, calling something “user-centered” meant putting a person at the center of the experience.
Someone with a goal, limited time, and very little interest in learning how our software works.
We used human-centered and user-centered almost interchangeably.
I believe that’s about to change.
As agents take on more of the work inside software, the person who wants an outcome and the user operating the system will increasingly be different entities.
The human is still the reason the work matters. But the human may no longer be the one using your product.
That distinction changes what we design—and who will do the designing.
One grocery order. Two very different experiences.
Imagine asking an assistant:
“Plan five easy dinners for two. Use my pantry list, keep the groceries under $100 including fees, and ask before buying.”
It responds:
“I’ve picked ingredients for chicken tacos, veggie stir-fry, spaghetti, salmon bowls, and lentil soup for $94. Do those sound good?”
For you, the experience is a conversation. You review the meals, change something if necessary, and approve the purchase.
Underneath that exchange, the assistant has a different experience.
It needs to find products, interpret quantities, check availability, calculate costs, and prepare an order. It might interact with several services or delegate parts of the task to other agents.
You need a clear recommendation.
The agent needs systems it can understand and operate reliably.
Both experiences require design.
Human-centered design follows the person
On the human side, the questions remain familiar.
Does the system understand what I want? Can I trust its recommendation? What am I approving? How do I correct it?
But the interaction changes when a person delegates the work instead of performing every step.
A grocery assistant shouldn’t require me to inspect dozens of product selections just to feel confident it followed my request. It should surface the decisions that matter and make the details available when I want them.
That takes judgment.
What belongs in the summary? What uncertainty needs to be disclosed? When does a substitution require permission? When should the assistant interrupt me?
Conversation, information design, and data visualization become central to this work.
The design challenge is helping someone delegate confidently while retaining meaningful control.
User-centered design has another user to consider
Now look at the same transaction from the agent’s perspective.
Does “quantity: 1” mean one banana, one bunch, or one pound?
Is the listed price current? Does the total include delivery fees? Has an item actually been reserved, or merely added to a cart?
If checkout times out, did the purchase fail—or did it succeed without returning confirmation?
These are usability questions with consequences.
A person might resolve an unclear quantity by looking at a product photo. An agent needs an explicit, dependable way to interpret it.
A person might notice an order confirmation email after a timeout. An agent needs a way to check the transaction before trying again.
A polished storefront can coexist with an experience that is confusing or unusable for the system trying to shop there.
If agents become a meaningful share of a product’s users, their ability to complete tasks becomes part of that product’s success.
The design surface moves under the hood
For agent users, the interface includes capabilities, instructions, data structures, permissions, responses, and recovery paths.
Can the agent discover what the system supports? Does it receive enough context to choose the right action? Can it distinguish a completed task from a pending one? Can it recover without duplicating a purchase?
This work overlaps with API design, engineering, and systems architecture. Those disciplines already address many of these concerns.
The UX contribution is to examine the whole journey: what the agent is trying to accomplish, where understanding breaks down, and how that breakdown affects the person it serves.
My prediction is that more experience design will happen at this level.
And much of it may eventually be performed by agents.
Agents may become their own experience designers
An agent could test variations of a task, identify ambiguous responses, find recurring failures, and propose changes to the interface it uses.
Another agent could evaluate whether those changes improve completion and recovery.
I expect that feedback loop to become increasingly automated.
But successful execution alone is an incomplete measure.
An agent could complete checkout while choosing meals the person dislikes. It could stay under budget by buying insufficient quantities. It could reduce interruptions by making decisions the person wanted to approve.
Humans still have to establish what a good outcome means, whose interests the system serves, and which decisions require human judgment.
An experience can work perfectly for an agent and still fail the person behind it.
Designers will need to choose where they go deeper
I see two connected areas of practice emerging.
Human-facing work will concentrate on expressing intent, understanding results, making decisions, and maintaining control.
Agent-facing work will concentrate on making capabilities understandable, actions predictable, and failures recoverable.
Some designers will work across both. Others will specialize. Either way, assuming every user is a person looking at a screen will become a limitation.
In my first article, I argued that the human interface will shrink as software takes on more coordination.
This is the other side of that prediction: the interactions underneath will expand.
We’ll need to ask two questions every time we design a system:
Who is using it?
And whose life is supposed to improve when they do?
