Designing for Intent: Why the Real Frontier of Enterprise AI Isn't the Agent — It's the Experience Around It

For sixty years, every leap forward in user experience was really a leap in compromise. Each generation of interaction got better at hiding the machine, but the machine still did what the machine did. The user still had to learn the levers. We just kept making the levers prettier.

That long pattern is finally breaking. Not because of AI hype. Because of what AI quietly makes possible: for the first time, the system can adapt to the person, the moment, and the intent that matters now — instead of asking the person to adapt to the system.

This piece is about the inversion that's now underway, and about a framework I call Intent-Driven Experience — what it is, what it isn't, and what must be true for it to actually work.

A Note on Vocabulary

When I say "conventional experience," I mean the way we interact with software today: dashboards, screens, navigation menus, applications you log into, structured pages a user has to read and act on — and, increasingly, conversational agents that respond when a user asks. It's shorthand for the inherited paradigm.

When I say "experience," I mean it broadly. The experience is whatever sits between a person and a system at a moment that matters — a traditional interface, a conversational agent, a voice surface, an inline component, an ambient prompt, a notification at the right second. The framework here is about the experience layer itself, regardless of how it's delivered.

Sixty Years of Levers

Every era of computing promised to make software more human. Each one stopped short.

The mainframe era — capability first. Interactions mirrored the machine. Forms echoed database tables. Commands mapped to functions. The user learned the system's language, or the system was useless.

The GUI breakthrough — control without knowing the engine. Xerox PARC and the original Macintosh replaced memorization with metaphor. Files lived in folders. You pointed and clicked. Real progress. But the interfaces still mirrored the system's internal structure. We surfaced the machine's capabilities — now with windows and toolbars — and still asked the user to navigate the machine's map.

The iPhone moment — proof of what user-centricity can be. When Steve Jobs removed the keyboard, he didn't just shrink the computer. He proved a principle: the surface should reshape itself for what the user is doing. Typing? Keyboard. Calling? Dial pad. Navigating? Map. One device, many surfaces, each fitted to the moment. It was the closest the pre-AI world came to true adaptation. But notice what the user still had to do: choose the app. The iPhone proved adaptation could work for one person doing one thing at a time. Enterprise complexity — many people, many roles, many systems — was beyond what the technology of that moment could deliver. Jobs proved the direction. AI is what makes finishing the journey possible.

The web and Information Architecture. When content exploded, IA gave us naming, grouping, wayfinding. We embraced the 80/20 rule: serve most needs with predictable structures, accept the rest will be harder. We got better at organizing the library. We still expected patrons to wander the stacks.

Business-driven enterprise software. Interactions became instruments of operational control: clean inputs, consistent process, measurable outputs. Usability mattered, but only after the metrics and approval gates were hard-wired. Users complied because they had to.

Human-Centered Design. Research, behavioral insight, friction reduction — all of it lowered errors and shortened learning curves. But the underlying model held: the organization set the goals, technology set the structure, design made it nicer to use. HCD optimized the surface. The foundation was unchanged. Design too often showed up arguing for fonts and research gates while the rest of the organization was negotiating outcomes — making design look like a blocker, not a multiplier.

Across every era, the same quiet truth: the machine did what the machine did. Every "experience" was a layer of compromise on top of capability. The user pulled the levers; we just made the levers more ergonomic.

That's the limit we've now reached.

The machine did what the machine did. We just kept making the levers prettier.

The Inversion Has a Name Now

In the last several months, the foundation moved.

ServiceNow shipped the Context Engine. Workday rebuilt its front door around an agentic surface called Sana. Google Research published Natively Adaptive Interfaces, where an agent becomes the primary interaction surface. SAP is calling it intent-driven user experience. Microsoft, Anthropic, and OpenAI all have variations.

The vocabulary differs. The architecture converges. What every major enterprise platform is now shipping, in some form, is a layer that orchestrates what each user sees and does, in each moment, based on what they're trying to accomplish. The technology layer has arrived.

The harder problem — the one this piece is about — is the one most organizations have not yet started: how do you design for it well?

Why AI Transformations Are Failing

The numbers on enterprise AI transformation are bad, and they are not getting better.

RAND reports 80% of AI implementations deliver no measurable business value. MIT NANDA found 95% of generative AI pilots never scale. Gartner projects 60% of AI projects without AI-ready data will be abandoned by end of 2026. McKinsey's November 2025 Global AI Survey found 88% of organizations using AI but only 39% seeing meaningful EBIT impact.

The instinct is to blame the technology, the data, or change management. All three are real factors. They are also symptoms.

The deeper failure is that organizations have been pouring AI into experiences that were never designed for AI. They added a model behind a dashboard, or a chatbot beside it, and called it transformation. The user still has to log in. The user still has to know what to look for. The user still has to interpret, decide, and act. The machine still does what the machine did — only now there's an LLM helping translate the user's request. The work of figuring out what to do next didn't move. It just changed shape.

RAND's top root cause is misunderstood problem definition. Capgemini blames how AI is conceptualized, governed, and embedded. HBR calls it the micro-productivity trap. CIO names the readiness illusion.

Different vocabularies, same problem: AI transformations are failing because they were never designed around user intent in the first place. They were designed around capability — what the model can do — and bolted onto experiences already built around levers. A smarter model behind a screen the user still has to operate produces a smarter response to the user's request. It doesn't produce transformation. The user is still the one carrying the load.

Intent-Driven Experience is the operationalization of what every credible analysis is naming as the missing layer.

What This Is Not

Many companies are shipping conversational agents and labeling them intent-driven. A user types or speaks a prompt — "show me my open accounts," "summarize this case," "draft a follow-up" — and an agent responds. This is genuinely useful. It is also still the user pulling levers. The lever just moved from a click to a sentence.

In this pattern, the user still has to know what to ask. The user still has to know what the system can do. The user still has to initiate. Then, when the agent responds, the user has to read the summary, evaluate it, and decide what to do. The agent is responsive — but the user is doing the work of being responsive to themselves. The interaction model has barely changed; only the input method has.

This is conventional experience with a better front door. It is an improvement, sometimes a significant one. It is not the destination.

Intent-driven experience is something different. It is the system running alongside the user — not waiting to be asked. It anticipates what matters next based on context, the moment, and the work being done. It doesn't summarize for the user to interpret; it surfaces the small number of things the user actually needs to act on, frames them so the next move is obvious, and where appropriate, takes the next step itself with the user's confirmation.

A chatbot or voice agent that responds to user requests is a better lever. An intent-driven experience is a system that knows what lever needs to move next, and either moves it or makes moving it almost effortless — through whatever surface fits the moment. Hold this distinction loosely and you'll ship a smarter chatbot. Hold it tightly and you'll ship something that genuinely changes how work feels.

The Framework: Three Lenses on Intent

To make any intent-driven experience real — across any domain where complex enterprise work happens — the system has to be able to answer three questions about a user at any moment.

Where, What, Why.

Where — Context. The situation the person is operating in. Where are they in the broader flow of work? What came before, what comes next, what's possible from here. In a sales setting, this might be a stage in the customer relationship — early discovery versus active deal versus post-sale. In clinical care, it's where the patient is in their care path. In field operations, it's where the technician is in a service call. The vocabulary changes. The question is the same: where in the flow of work is this person right now?

What — The Moment. Inside any flow of work are specific points where intent meets capability — where a decision needs to be made, an action needs to be taken, or context needs to be delivered. Not every interaction is one of these moments. Identifying the real ones — the ones that change outcomes — is part of the work.

Why — The Mode. The same person, in the same moment, can have very different intent. A clinician may be triaging, diagnosing, or stabilizing. A sales professional may be pursuing new opportunity, coordinating internal approvals, or recovering an at-risk relationship. Each mode reconfigures what the system surfaces — whether through a dashboard layout, a proactive nudge in chat, or a question an agent decides to ask without being prompted.

These aren't three rigid boxes. They're three lenses the system must always be able to look through. The clearer the Where, What, Why, the closer the experience gets to designing itself.

The framework is intentionally domain-agnostic and modality-agnostic. To make it concrete, let's apply it to one setting.

The Concept In Action

It's 9:47 AM. A revenue professional opens whatever surface they use to start the day.

In a conventional experience, they see a list of 47 active accounts, sorted by close date.

In a conversational variation — the kind being labeled intent-driven by many vendors today — they ask an agent "what should I focus on this morning?" The agent answers. Better than scrolling. Still requires them to know to ask, to read the summary, and to decide what's actually next.

In an intent-driven experience, they don't have to ask.

Three accounts. Not forty-seven.

The renewal that triggered an early-warning signal overnight. The deal that's been stuck waiting on internal review for nine days. The prospect whose buying group just expanded yesterday. By the time they open anything, those three are surfaced — with the next action for each one ready to take in a single click or confirmation. The system did the noticing, the prioritizing, and the framing. The person does the deciding and the doing — which is what they're actually paid for.

Underneath that experience, Where is the customer relationship and where in that relationship each account sits — early discovery, active deal, post-sale, renewal, expansion. What are the moments where internal work touches the customer relationship and pushes it forward — proposals, approvals, service responses, renewal conversations. Why are the postures the person operates in across a day: monitoring for early signals, pursuing new opportunity, closing performance gaps, coordinating internal work, resolving post-sale issues, calibrating for the next cycle. Same person, different mode, different surface.

Now apply Where, What, Why to clinical care. Where becomes where the patient is in their care path. What becomes triage, imaging decisions, the admit or discharge call. Why becomes the postures the clinician is operating in: triaging, diagnosing, stabilizing, handing off. Different vocabulary. Same lenses. Same framework.

This is what makes it durable. Get the three lenses right and the experience adapts. Get any one of them wrong and you collapse back to conventional interaction with a chatbot stapled on.

What Must Be True

The intent-driven experience is not magic. It depends on a set of enabling conditions. Without them, it doesn't fail loudly — it fails quietly, by reverting to looking like every other dashboard.

A useful property to name: the framework is also the assessment. The exercise of defining the Where, What, Why — and the signals required to power them — surfaces, early and before any build, exactly what foundational gaps exist. You cannot define a mode without naming what data tells the system the user is in it. You cannot identify a moment without knowing what signal makes it observable. The framework, by design, is a stress test of whether the foundation is ready.

1. Signal must exist, and it must be trustworthy.

This is the condition organizations underestimate most often, and it's the most expensive failure mode in the field.

Gartner predicts 60% of AI projects will be abandoned through 2026 due to lack of AI-ready data. A Cloudera and Harvard Business Review study found only 7% of enterprises say their data is fully ready; 73% report data preparation as a major struggle.

The pattern I see, repeatedly: leaders confidently say "we have the data, it's accessible, it's clean." Their own architects, data engineers, and platform teams quietly disagree. Six months in, the project hits the wall those experts tried to flag. As Workday's Joel Hellermark put it: "Everyone is ignoring the big boring problem of bad context."

If you take one thing from this article, take this: start the conversation with a frank, expert-led data and signal assessment, not with the design. The teams who keep raising their hand about data quality are not slowing the work down. They are protecting it. The framework itself — defining the Where, What, Why in detail before committing to a build — is the fastest way to surface, in concrete terms, exactly what data is required, what's missing, and what has to be built first.

2. The work must have identifiable moments. Not every interaction is a moment. Settings where everything is uniform — no transitions, no decisions, no consequence — get less from the framework. That's not a weakness. It's a clarification of where it applies.

3. Intent must be inferrable or declarable. Either the system reads intent from context, or the user signals it directly. The more the system can infer, the closer the experience gets to running alongside the user instead of waiting on them.

4. The underlying systems must be addressable. You can't orchestrate what you can't reach. The platforms shipping today are addressing this — but most organizations still have meaningful work to do on their foundations.

These four conditions are about whether the framework can work. Get them right and you have the foundation.

The Contract With the User

Once a system can choose what to surface, the relationship with the user changes.

The conventional experience was passive. It showed everything; the user did the work of choosing.

The intent-driven experience is active. It chooses. And the moment it chooses, it owes the user three things:

These aren't enabling conditions. They're guardrails. The framework can technically operate without them — and that is exactly the failure mode to avoid.

Get the conditions right and you can deploy. Get the contract right and the deployment compounds. The systems that earn trust are the ones users stop second-guessing, and the value of intelligent orchestration only shows up after that trust is in place.

Designing Intelligence, Not Layouts

For decades, design was a layout discipline. We arranged elements on a canvas. We made choices about hierarchy, color, density, navigation. The artifact was the screen.

Designing for intent is something different. It's a behavioral architecture discipline. We define the contexts the system serves. We identify the moments. We define the modes a user can be in, and what each prioritizes. We define the signals that move a user from one mode to another. We define the rules the system follows when it explains itself. And we do this knowing the experience may be delivered through any combination of interface, agent, voice, or ambient surface — and that the goal is for the system to act, where appropriate, before the user has to ask.

The artifact is no longer a layout. The artifact is a system of intent.

What This Means

If you build software, layout-first design is reaching its ceiling. The next decade of meaningful product work is in defining contexts, moments, modes, and the rules of explanation.

If you lead a transformation program, adoption metrics are about to mislead you. Logins and training-completion measure exposure. Even prompt counts measure how often the user asked, not how well the system anticipated. The intent-driven experience demands different measures: cycle time, decision confidence, throughput, the share of relevant action delivered without being requested. Effective use, not adoption.

If you're a user — and we are all users — the way you work with software five years from now will look almost nothing like the way you work with it today. Not because the screens got prettier. Because they got smarter about not being there when you don't need them, being exactly right when you do, and sometimes not being screens at all.

The Mindset Shift

The AI transformations failing at 70-80% rates today aren't failing because the model is wrong. They're failing because we kept building experiences that ask the user to do the work the AI was supposed to remove.

A smarter dashboard is not transformation. A faster lever is not an extension of the user. An agent that responds to a question is not a system running alongside you.

The shift is this: stop designing experiences around capability and start designing them around intent. Start with the data. Define the contexts. Identify the moments. Make intent something the system can read — or the user can declare. And commit, in writing, to the contract.

Done well, the experience stops feeling like an interface to a system and starts feeling like an extension of the user — barely noticeable when it's working, indispensable the moment it's gone.

A response, not a destination. An emergence, not a layout. A moment, not a product — sometimes a screen, sometimes an agent, sometimes nothing at all because the right thing already happened.

The job is no longer to design the building. It's to design what makes the right room appear at the right time.

That work is just beginning.