P003 · Point of view · 14 September 2026 · 20 min read
The Observable Experience
Designing what people experience after an AI agent acts
The industry shifted to intent. We designed for capture. We forgot to design for consequence.
Everyone is talking about intent.
The entire AI industry has converged on a single premise: the future of human-computer interaction is intent-driven. Instead of clicking buttons, filling forms, or navigating menus, humans will express what they want — in natural language, in context, in gesture — and intelligent systems will figure out how to deliver it.
This is correct. And the progress has been remarkable. Large language models interpret nuance. Multimodal systems read context across text, image, and voice. Agentic frameworks chain reasoning across tools and APIs. The capture side of intent — understanding what the human wants — is advancing rapidly.
But there's a problem.
Nobody is designing for what happens after the intent is understood.
When an AI agent rebooks your flight, cancels a meeting, places a procurement order, merges a pull request, or rolls back a failed deployment — you don't experience the intent capture. That already happened. You experience what the system did with it. The consequence. The outcome. The result.
Speed. Clarity. Trust. Confidence. Control. Or: confusion. Surprise. Friction. Dread.
That lived, perceived consequence — what the human actually experiences when a system acts on their behalf — has no name, no framework, no design discipline.
I'm calling it The Observable Experience. OX.
The Intent Stack
To understand why OX is needed, consider intent as a stack — four layers, each requiring its own design discipline:
Layer 1 — Intent Capture. How the system understands what you want. Natural language processing, context windows, multimodal input, conversation history. This is where the entire industry is focused.
Layer 2 — Intent Interpretation. How the system disambiguates, scopes, and confirms what it's about to do. Clarifying questions, assumption surfacing, scope negotiation. This is emerging in agentic UX patterns.
Layer 3 — Intent Execution. How the system acts — governed by policy, permission, and constraint. API calls, state changes, downstream triggers, physical-world effects. This is the domain of system architecture and governance.
Layer 4 — Intent Consequence. How the human perceives what happened. Whether they understand the outcome, trust the action, retain authority, and know what comes next. This is OX. And almost nobody is designing for it.
The industry has poured enormous energy into Layers 1 and 2. Billions of dollars into understanding what you mean. But the experience doesn't live in the understanding. The experience lives in the consequence.
You don't judge your AI assistant by how well it understood your request. You judge it by what happened next.
Why Now
And by the way — I don't just mean screens.
When I say "interface," I mean any sensory feedback loop between a human and a system. Visual, voice, touch, gesture, haptic. A screen is an interface. A voice assistant is an interface. A haptic controller is an interface. A chat window is an interface. All of them share the same structural assumption: the human perceives, the human acts, the system responds, and the loop closes within the interaction itself.
UX, as a discipline, was built to design that loop — regardless of modality. And it's been extraordinarily successful. Decades of research, pattern libraries, design systems, usability testing — all optimized for the closed loop between human and system.
But the loop is opening.
AI systems now:
- Interpret intent without explicit instruction
- Execute actions across multiple systems simultaneously
- Make judgment calls under uncertainty
- Trigger downstream consequences in the physical world
- Operate in the background, without entering any human sensory loop at all
When the system acts outside the interaction — when the consequence extends beyond what any interface, in any modality, can contain — we've crossed into new territory.
The interface is no longer the center of gravity. The outcome is.
And we have no discipline — no vocabulary, no framework, no quality standard — for designing outcomes that happen beyond the interaction loop.
That's the gap OX fills.
A note on terminology. "Observable" already carries meaning in engineering. In DevOps and SRE, observability means metrics, traces, and logs — the telemetry of systems. OX is fundamentally different. Observability measures systems. OX measures experience. Observability asks "is the system healthy?" OX asks "does the human understand what just happened, and do they trust it?"
OX Is Not a Replacement for UX
Let me be precise about this.
Observable Experience does not replace User Experience. UX remains essential for designing every interaction layer — screen, voice, touch, gesture, chat. OX extends the boundary of what "experience" means into the space where the interaction ends and the consequence begins.
UX governs the interaction layer — any sensory feedback loop between human and system:
- Interface design across modalities
- Flows and task completion
- Affordances and signifiers
- Information architecture
- Interaction patterns
OX governs the consequence layer — what happens after the system acts on intent:
- The perception of outcomes
- The behavioral posture of systems
- The psychological interpretation of system action
- The trustworthiness of execution
- The felt sense of autonomy or control
UX is interaction design. OX is consequence design. Where UX ends at the interaction, OX continues into the result.
A Worked Example: The Deployment That Failed
To make this concrete, consider a scenario familiar to anyone who operates software: a deployment fails.
The UX approach
A CI/CD pipeline fails. The dashboard shows a red badge: "Deploy Failed." The user clicks into a log viewer. Scrolls through hundreds of lines. Finds an error message. Googles it. Decides whether to retry, roll back, or escalate.
The UX here is functional. The interface exists. The affordances are present — badges, logs, retry buttons. A UX designer would evaluate: is the error message readable? Is the retry button findable? Is the log viewer scannable?
All valid questions. All focused on the interaction layer.
The OX reframe
An AI-powered deployment system detects the failure, identifies the root cause (a dependency version conflict), evaluates whether an automatic rollback is safe (it checks three governance policies), rolls back to the last stable version, and notifies the operator:
"Deploy failed. Root cause: dependency conflict in module X. Rolled back to v2.3.1. No user impact. Approval needed to retry with updated dependency."
The operator's intent was "deploy this update." The system understood that intent (Layer 1), executed it (Layer 3), encountered a failure, and managed the consequence (Layer 4). The operator experienced:
- Clarity — the root cause was identified, not just the symptom
- Trust — the system checked policies before acting on its own
- Control — the rollback was automated but the retry requires human approval
- Orientation — they know what happened, why, and what comes next
No interface was central to this experience. The consequence was.
That's OX. The quality of the experience is determined not by the interaction, but by whether the human understood the consequence, trusted the action, retained authority, and knew what comes next.
The Four Affordances of OX
In traditional design, affordances signal what the human can do to the interface. A button affords pressing. A slider affords dragging. A text field affords typing.
In intent-driven systems, a new set of affordances emerges. These are not about what the human can do to the interface. They are about what the system can do to the world — and how the human perceives, trusts, and controls that.
When a human expresses intent and an AI system executes it, four questions arise. Each one maps to an OX affordance.
1. Behavioral affordances
"What is the system allowed to do with my intent?"
A traditional affordance: a "Delete" button signals that deletion is possible. An OX behavioral affordance: the system's scope of autonomous action is visible and bounded. The human knows what the system can do before it does it.
Example: An AI scheduling assistant has permission to reschedule meetings under 30 minutes but must ask before touching anything longer. The user knows this boundary. When a 20-minute sync gets moved, they aren't surprised — the behavioral affordance was clear. Their intent ("optimize my calendar") was executed within understood limits.
Counter-example: The same assistant silently cancels a 2-hour strategy session because it "optimized the calendar." The user is blindsided. The behavioral affordance was absent — the user didn't know the system could do that with their intent. The intent was right. The scope was wrong. And the user had no way to know.
2. Transparency affordances
"What did the system do with my intent, and why?"
A traditional affordance: a progress bar signals that work is happening. An OX transparency affordance: the system's reasoning, confidence, and evidence basis are visible when appropriate. The human can see how their intent was interpreted and executed.
Example: An AI content moderation system flags a post for review. Instead of just "Flagged," it shows: "Flagged for potential policy violation. Confidence: 73%. Similar to 4 previously removed posts. Policy: Community Guidelines Section 3.2." The moderator has enough context to make a fast, informed decision. The system's interpretation of intent ("keep the community safe") is transparent.
Counter-example: The same system shows "Flagged." No reason. No confidence level. No reference. The moderator must re-read the entire post and guess why the system flagged it. The system acted on shared intent but made its reasoning invisible. Sensemaking collapses.
3. Escalation affordances
"When will the system stop and ask me before acting on my intent?"
A traditional affordance: an "Escalate to Manager" button in a support tool — human-initiated. An OX escalation affordance: the system knows when it has exceeded its authority or confidence and proactively involves a human. The system pulls the human in at the right moment, with the right context.
Example: An autonomous procurement system is about to place a $50,000 order. It pauses: "This order exceeds the auto-approval threshold ($10,000). Supplier: Acme Corp. Justification: quarterly restock based on consumption forecast. Approve / Modify / Reject." The human enters the loop at exactly the right moment, with exactly the right context. Their standing intent ("keep supplies stocked") is honored, but the escalation threshold is respected.
Counter-example: The system places the order silently. Or worse: it asks for approval on every order, including $12 ones, training the human to click "Approve" reflexively — until the $50,000 one slips through on autopilot. This is the alert fatigue trap: when escalation is imprecise, humans stop paying attention. The affordance exists but it's been rendered useless by overuse.
4. Override affordances
"If the system already acted on my intent, can I take it back?"
A traditional affordance: an "Undo" button. An OX override affordance: the ability to reverse, modify, or halt system actions after they've been initiated — with full awareness of what has already propagated and what can still be changed.
Example: An AI assistant has already sent a meeting invitation to 40 people. The user realizes the time is wrong. The system offers: "Recall invitation. 38 of 40 recipients haven't opened it yet. 2 have accepted. Options: Recall all / Recall unopened only / Send correction instead." The override affordance accounts for the state of the consequence, not just the action. The user can reclaim control with full awareness of what's reversible and what isn't.
Counter-example: The same system offers "Undo" — which silently deletes the calendar event without notifying anyone, leaving 40 people with a ghost invitation in their inbox. The override was technically available. But it was consequence-blind — it reversed the action without considering the propagation.
Progressive Disclosure of System Cognition
In traditional UX, progressive disclosure reduces cognitive load by revealing information gradually. Show the summary first. Let the user drill down into details on demand.
In OX, progressive disclosure takes on a different meaning. It governs how much of the system's thinking is revealed — and when.
This matters because intent-driven systems do more cognitive work than command-driven systems. When you clicked a button, the system did one thing. When you express intent, the system may interpret, disambiguate, plan, evaluate constraints, check policies, execute across multiple services, handle partial failures, and synthesize results — all before presenting an outcome. The question isn't whether to show this work. It's how much and when.
Consider an AI research assistant that has just synthesized a 50-page report from 200 sources.
- Level 1 — Action only: "Your report is ready."
- Level 2 — Action + summary: "Your report is ready. Key finding: market growth is decelerating in Q3."
- Level 3 — Action + reasoning: "Your report is ready. Key finding: market growth is decelerating in Q3, based on earnings data from 12 public companies and 3 analyst reports. Confidence: high for North America, moderate for APAC."
- Level 4 — Full cognitive chain: "Here's every source I consulted, every inference I made, every conflict I resolved, and every judgment call I made about source quality."
Too little disclosure and the human can't trust the output. Too much disclosure and they're buried alive.
OX progressive disclosure is the art of calibrated revelation of system cognition. The right level depends on the stakes, the user's expertise, and the cost of being wrong. A casual calendar optimization can get away with Level 1. A medical diagnosis recommendation needs Level 3 at minimum.
Wayfinding in the Intent Era
Wayfinding in traditional design means helping users orient within an interface. Breadcrumbs tell you where you are. Navigation tells you where you can go. Page titles tell you what you're looking at. It's spatial orientation — where am I in this information space?
In the intent era, wayfinding becomes situational orientation — understanding where you are in an outcome process, not a page hierarchy.
When you've expressed an intent and an AI system is executing it, you need to know:
- What is happening right now? Is the system working, waiting, or stuck?
- What has already happened? What actions were taken, and are they reversible?
- What will happen next? What's the next step, and does it require my involvement?
- What authority do I retain? Can I still change course, or has the point of no return passed?
This applies regardless of modality — chat, voice, API, or fully autonomous background execution. The interface might be a progress screen, a Slack notification, an email digest, or nothing at all. The modality doesn't matter. The orientation does.
Example: You've asked an AI legal assistant to draft a contract based on a term sheet. Good OX wayfinding looks like this:
Step 1 — completed. Parsed term sheet. Identified 14 key terms. Step 2 — in progress. Drafting contract sections. 8 of 12 complete. Step 3 — upcoming. Review required: 3 clauses need your judgment — liability cap, IP assignment, termination. Step 4 — blocked. Cannot proceed without jurisdiction selection.
The user knows where they are in the consequence chain, what the system has done autonomously, what's coming, and where their authority is required. That's OX wayfinding. No breadcrumbs needed. No page hierarchy. Just clear situational awareness of an intent being executed.
Sensemaking: Where AX Meets OX
Sensemaking is the human process of interpreting signals, forming mental models, and constructing understanding from incomplete information. It's how we make sense of what's happening around us.
In intent-driven systems, sensemaking has a new challenge. The human expressed an intent. The system did… something. Now the human must figure out: did the system do what I meant? Did it do it correctly? Did anything unexpected happen? Can I trust it to do it again?
Sensemaking in OX depends on:
- Explanation — Why did the system do that with my intent?
- Feedback loops — Did my input change the outcome? Does correcting the system actually work?
- State visibility — What is the system's current state? Is it still working, or done?
- Confidence signaling — How sure was the system about its interpretation?
- Behavioral consistency — Does the system behave the same way with similar intents?
If system behavior is inconsistent — if the same intent produces different actions, or if the system's confidence level doesn't correlate with its accuracy — sensemaking collapses. The human stops trusting. They start working around the system instead of with it. They revert to the old interface. The intent-driven promise dies not because the technology failed, but because the experience failed.
This is where we need a companion concept: Agentic Experience (AX).
AX describes how intelligent systems behave when acting on behalf of humans. It governs the internal conduct of the system: how it interprets intent, requests clarification, communicates uncertainty, respects permission, handles escalation, explains decisions, and enforces boundaries.
AX is the conduct of the system. OX is the consequence of that conduct.
If AX is inconsistent, opaque, or reckless — OX becomes distrust, confusion, and friction. If AX is principled, transparent, and measured — OX becomes clarity, confidence, and trust.
Sensemaking is the bridge. It's how humans translate system conduct (AX) into perceived experience (OX). Design one without the other and the whole thing falls apart.
Three Decision Contexts
Intent-driven systems don't always execute the same way. Sometimes the human decides. Sometimes the system decides. Sometimes they decide together. OX must account for all three.
1. Human decision — the system supports
The human expresses intent and retains full decision authority. The system provides information, options, and clarity — but the human makes the call.
Example: A doctor reviews an AI-generated diagnosis summary and decides on a treatment plan. The system interpreted the patient's data (intent capture) and synthesized findings (execution), but the decision belongs to the doctor. OX must ensure the evidence is clear, the reasoning is traceable, and the doctor feels supported rather than replaced. The system's job is to make the human smarter, not to make the human unnecessary.
2. AI decision — the system acts within governance
The system interprets intent and acts autonomously within defined boundaries.
Example: An email system automatically moves messages to spam based on trained filters. The user's standing intent is "keep my inbox clean." The system decides what's spam. OX must ensure the user can verify what was filtered, understand why, and override when the system is wrong. The automation serves the intent, but the human must be able to audit and correct.
3. Human in the loop — the system proposes, the human approves
The system interprets intent, formulates a plan, and presents it for human confirmation before acting.
Example: An AI financial advisor recommends rebalancing a portfolio. It shows the proposed trades, the reasoning, the expected impact, and the risk assessment. The human's intent was "optimize my portfolio." The system's proposal is its interpretation of that intent. OX must ensure the proposal is understandable, the risks are honestly communicated, and the approval is informed — not reflexive.
In each context, OX must answer four questions:
- Who decided? Is it clear whether the human, the system, or a policy made this happen?
- Why? Is the reasoning visible and honest?
- Can I change it? Is there an override, escalation, or appeal path?
- What happens next? Is the next state predictable from the current state?
These four questions form The OX Test — a simple quality gate that applies to any feature, any action, any system that executes on behalf of a human.
The Psychological Foundations
OX is not invented from nothing. It builds on established psychological science — but applies these principles beyond the interface, into the space where AI acts and humans perceive:
- Cognitive load theory — Humans have finite processing capacity. OX must calibrate how much system reasoning to reveal. Intent-driven systems do more invisible work, creating more potential disclosure — and more potential overload.
- Attribution theory — Humans need to assign causality. "Who caused this outcome?" When a system acts on intent, the line between "I decided" and "it decided" blurs. If the human can't attribute the action, anxiety rises.
- Trust formation — Trust is built through predictability, transparency, and perceived benevolent intent. One opaque or reckless action can destroy months of earned trust. Trust in intent-driven systems is harder to build and easier to lose than trust in command-driven ones.
- Control theory — Perceived control reduces stress and increases satisfaction, even when actual control is limited. OX must preserve the feeling of authority, even as the system takes on more autonomous execution. The intent was the human's. The outcome must still feel like theirs.
- Error recovery psychology — How a system handles failure shapes trust more than how it handles success. A system that fails gracefully, explains clearly, and recovers quickly builds more trust than one that never fails but can't explain itself.
- Decision fatigue — Too many decisions degrade quality. If the system escalates every minor action, the human becomes an approval rubber stamp. Escalation affordances must be selective, not exhaustive.
- Mental models — Humans construct simplified models of how systems work. Intent-driven systems are inherently harder to model than command-driven ones. If the system's actual behavior contradicts the user's mental model of how it interprets intent, the experience fractures.
OX does not discard these principles. It operationalizes them for a world where the interaction loop is open and the system acts beyond the screen.
The Measurement Mandate
Experience that cannot be measured cannot be governed.
If OX is going to be a real discipline — and not just a philosophy — it needs measurable criteria. Here's a starting framework:
| Dimension | What to measure | Example metric |
|---|---|---|
| Consequence latency | Time from system action to human awareness | The user knew within 3 seconds that the system had acted on their intent |
| Transparency coverage | Percentage of autonomous actions with visible reasoning | 92% of automated actions included an explanation |
| Trust recovery | Time to restore confidence after a system error | After the false positive, the user resumed trusting recommendations within 2 sessions |
| Escalation precision | Ratio of meaningful escalations to noise | Of 100 escalations, 87 required genuine human judgment |
| Override effectiveness | Percentage of overrides that achieved the intended correction | When users overrode the system, 94% got the result they wanted |
| Authority clarity | User's ability to correctly identify who decided | In testing, 96% of users correctly identified whether the system or they made each decision |
These are not vanity metrics. They are consequence quality indicators. Every one of them measures whether the human's experience of the system's action was clear, trustworthy, and controllable.
Why OX Is a New Category
A reasonable objection: isn't this just good product design? Isn't this just what thoughtful teams already do?
Partly, yes. The best teams already think about trust, transparency, and control. But they do it within frameworks that assume a closed interaction loop — some sensory channel through which the human perceives, acts, and receives feedback. They measure satisfaction with the interface. They test usability of the flow. They optimize the funnel.
OX is needed because:
- 01Intent has replaced commands, but experience design hasn't kept up. The industry invested billions in understanding what users mean. It has invested almost nothing in designing how users experience what the system does with that understanding. We designed the input. We forgot the output.
- 02The interaction loop is becoming optional. Screen, voice, touch, API, background agents, invisible automation — increasingly, the system acts without entering any human sensory loop at all. UX frameworks don't have vocabulary for experience that happens outside all modalities.
- 03The agent is a new actor. In command-driven software, the system does what the user tells it. In intent-driven systems, the system interprets, plans, decides, and acts. The relationship between human and system has fundamentally changed. We need a discipline that governs this new relationship.
- 04Consequences are becoming autonomous. When an AI system places an order, sends a message, modifies a record, or triggers a physical process — the consequences are real, immediate, and sometimes irreversible. The experience of those consequences deserves its own design discipline.
- 05Existing categories don't cover it. UX covers the interaction loop, in any modality. CX covers the customer relationship. Explainable AI covers model interpretability. Trust and safety covers content policy. None of them governs the holistic perceived experience of intent being executed autonomously, outside any sensory feedback loop.
OX is the discipline for the other half of intent. The half that happens after the understanding. The half that determines whether the human trusts the system enough to express intent again.
Designing for OX: A Practitioner's Checklist
For teams building intent-driven products today, here's how to start applying OX thinking.
Before shipping any feature, apply the OX Test:
- 01Who decided? Can the user tell whether they, the AI, or a policy triggered this action?
- 02Why? Is the reasoning visible — or is the action a black box?
- 03Can I change it? Is there an override, undo, or escalation path?
- 04What happens next? Is the next state predictable from the current state?
For each intent-driven action, classify the affordances:
- What are the behavioral boundaries? What can the system do with this intent without asking?
- What are the transparency levels? How much of the system's interpretation and reasoning is shown?
- What are the escalation triggers? When does the system pause and involve a human?
- What are the override mechanisms? How does the human reclaim control after the system has acted?
Measure OX, not just UX:
- Don't just measure task completion rate — measure whether the user understood what happened.
- Don't just measure time on task — measure time to situational awareness.
- Don't just measure error rate — measure trust recovery time after errors.
- Don't just measure user satisfaction — measure authority clarity.
Design the consequence, not just the capture. For every intent your system can receive, ask: "What does the human experience when this intent is executed?" Not the screen. Not the notification. The lived experience of the outcome. If you can't answer that question clearly, you've designed half a product.
The Future
As AI systems grow more capable, the gap between intent and consequence will widen. Systems will execute more complex intents, across more services, with more downstream effects, further from human oversight.
Interfaces — in every modality — will become thinner. The observable experience will become thicker.
People will judge products not by how beautifully they capture intent, but by how reliably, clearly, and ethically they execute it.
The companies that win will not be the ones with the best natural language understanding. They will be the ones whose systems act in ways that are principled, transparent, and measured — and whose users feel that in every consequence, whether or not an interface was involved.
The Declaration
The industry shifted to intent. We designed for capture. We forgot to design for consequence.
Observable Experience is the missing half. It governs what happens after the system understands what you want — the lived, perceived experience of your intent being executed in the world.
Design governs behavior. Behavior shapes perception. Perception defines trust. Trust determines whether the human expresses intent again.
Observable Experience is the design discipline for the intent era. It does not replace UX. It completes the stack. From this point forward, any system that acts on intent must be designed not only for how well it understands, but for what it becomes observable as.
Intent without consequence design is half a product. Design for the outcome, not just the input.