Intent first
A customer opens a banking application because they want to know whether they can afford a holiday.
The application opens on an accounts screen. The customer checks a balance, searches recent transactions, reviews upcoming payments, remembers that a credit-card bill is due, and perhaps opens a budgeting tool. The application provides every necessary fact. The customer supplies the plan that connects them.
Nothing in the first screen represents Can I afford this holiday? That question exists in the customer's mind, outside the interface. To answer it, the customer translates the question into the structure the product has made available.
This is the usual order of interaction:
predefined interface
↓
user learns its concepts and paths
↓
user translates a goal into operations
↓
application returns data and changes state
An intent-driven interface reverses the first half of that sequence. The customer begins with the holiday, not with the accounts screen. Software interprets the goal, determines what information and capabilities are relevant, and forms an interaction around the situation.
user intent
↓
interpretation and clarification
↓
relevant data, capabilities, and constraints
↓
situational interface
The reversal appears small. The user speaks before the screen appears. Its consequence is much larger:
The product's information architecture no longer has to be the user's starting point.
Work as a goal #
People rarely approach software wanting to use a feature. They want to send a document for approval, understand a rise in spending, arrange a journey, investigate an incident, or decide which supplier to choose.
Software exposes buttons, fields, objects, and workflows. The user converts one vocabulary into the other:
| The user thinks about | The application exposes |
|---|---|
| Can I afford a holiday? | Accounts, transactions, budgets, scheduled payments |
| Why did sales fall? | Reports, date filters, segments, comparison controls |
| Help the new employee get started | Users, roles, groups, licences, checklists |
| Move the meeting to a time everyone can attend | Calendars, attendees, availability, time zones |
This conversion is a form of work. Experienced users perform it so fluently that it becomes difficult to notice. They know which section contains a capability, which terminology the product uses, and which sequence will produce the desired state. New or occasional users must discover that mapping.
Menus and dashboards make the mapping visible. Search shortens it. Shortcuts, saved views, and automation preserve mappings that a user has already learned. None of them usually removes the need to begin from the application's model.
The current arrangement can be expressed as:
goal → product taxonomy → screen → controls → result
The user effectively compiles an intention into commands the application understands.
An intent-driven system takes responsibility for more of that compilation. It accepts a description of the desired outcome and maps it onto available data and actions. The user may still manipulate controls, but those controls can be selected and arranged after the goal is known.
Intent beyond the prompt #
Intent does not have to arrive as a sentence in a text box. It may be expressed through speech, a selection, an uploaded document, a highlighted anomaly, a repeated routine, or a combination of actions and context. Nor is an expression a complete intent merely because it is written in natural language.
Consider:
Can I afford a $3,000 holiday next month?
The sentence supplies a goal and two constraints. A useful interpretation may also require the destination currency, travel dates, the accounts that can be used, upcoming income and obligations, a desired cash reserve, and whether using credit is acceptable.
The system therefore needs to construct a working account of the task:
goal: assess holiday affordability
amount: $3,000
period: next month
include: available funds, expected income, known obligations
preserve: normal spending and preferred cash buffer
unknown: exact dates, acceptable use of savings
We are not talking about a specific screen yet. It is a task model: an interpretation of what the user is trying to accomplish, what is known, what remains uncertain, and what would count as a useful result.
The difference is substantial because the same words can imply different tasks. “Show me my subscriptions” may mean produce a list, explain a rise in monthly costs, find services that appear unused, or prepare cancellations. A system that jumps directly from a phrase to an attractive interface may represent the wrong problem with great confidence.
Intent-driven interaction therefore includes interpretation over generation.
Task formation #
In a conventional application, a route commonly selects a component tree. The component determines which data to request and which actions to expose.
route
↓
known screen
↓
known data requirements
↓
known controls
In the inverted model, the task determines the requirements:
intent and context
↓
task model
↓
information and capability needs
↓
appropriate representations and controls
For the holiday question, the system might gather account balances, scheduled bills, expected income, typical spending, and savings commitments. It could then present an affordability estimate, the assumptions behind it, a short cash-flow timeline, and controls for changing the budget or dates.
The interaction is organized around a decision rather than a product area.
Another intent over the same financial data would produce a different task model. “Prepare payroll for Friday” emphasizes operating cash, incoming invoices, scheduled transfers, employee payments, and authorization requirements. “Why was I charged an overseas fee?” needs a transaction explanation, the card's fee rules, and perhaps an option to compare travel products.
The underlying accounts have not changed. The relationship among them has.
Intent selects which facts belong together and why they matter now.
This goes beyond choosing a layout. A table, chart, timeline, explanation, simulator, or form each supports a different kind of thought. The representation follows the work:
| Task | Likely interaction |
|---|---|
| Scan many records | Sortable, filterable table |
| Understand change over time | Chart with comparisons and annotations |
| Evaluate a future decision | Scenario model with adjustable assumptions |
| Complete a consequential action | Review form with explicit confirmation |
| Resolve uncertainty | Explanation with evidence and follow-up choices |
A situational interface may combine several of these. Its organizing principle moves the user beyond an application segment and towards a particular outcome.
Language opens the task #
Reversing the order does not mean the user must fully specify a goal before seeing anything. People often discover what they want by looking, comparing, and manipulating.
The first generated surface can make the system's interpretation visible:
Holiday affordability
Estimated available after known obligations: $2,150
Assumptions
• Travel budget: $3,000
• Dates: 1–30 September
• Keep $1,500 as an emergency reserve
• Do not use the credit card
[Change assumptions] [Compare dates] [Build a savings plan]
This surface is both an answer and a question. It says, “Here is how I have understood the task; is this the problem you meant to solve?”
Controls let the user correct that understanding without restating everything. Moving a date, excluding an account, or changing a reserve gives the system more precise intent. The resulting interaction becomes iterative:
express → interpret → represent → adjust → act
The interface and the intent develop together. Language is useful for beginning with an incomplete goal, referring to things that do not yet have names in the interface, and changing direction without retracing a workflow. It is much less efficient for scanning many records, comparing alternatives, adjusting several values, or checking the exact state of a consequential action.
Conversation is therefore a command layer. It can open and redirect the task. Tables, charts, forms, simulations, and direct-manipulation controls can make the system's interpretation inspectable and carry the detailed work. A useful interaction moves between these modes instead of forcing every step through a prompt.
Personalization around a situation #
Traditional personalization usually begins with relatively durable attributes: role, preferences, history, device, or membership in a segment. Intent adds a temporary dimension.
The same person may need a compact answer while walking to a meeting, a detailed comparison while planning at a desk, and a stable recurring workspace while completing the same task every week. A useful interface can respond to all three without treating them as three different users.
Context helps determine how to serve the intent:
interface = f(intent, context, capabilities, constraints)
Context may include the user's data, expertise, recent actions, device, accessibility preferences, and current place in a longer task. Capabilities define what the system can actually retrieve, calculate, or do. Constraints define permissions, policy, risk, and required confirmation.
Intent gives these inputs direction. Without it, personalization can make content more relevant while leaving the user to decide what the relevance is for.
The aim is an appropriate fit between a situation and an interaction. Two users pursuing the same careful reconciliation may benefit from the same stable table. One user pursuing two different goals may need two very different views.
What remains explicit #
Not every interaction benefits from interpretation. A person who performs the same precise task every day may prefer a permanent, predictable workspace. A user may want to browse what is possible before forming a goal. A high-risk action may require a stable sequence whose wording and controls do not adapt.
Intent-driven software can preserve those modes. The inversion changes the available starting point; it does not require the removal of every existing one. Composing new surfaces without making its behavior arbitrary, is the central property of such inversion.
The practical model is likely to be layered:
stable interface for navigation, repetition, and recovery
+
situational interface for a present goal
Users can begin from either side. They might state a goal and receive a workspace, open a familiar screen and ask for help within it, or save a useful situational view until it becomes a stable part of their practice.
The important change is that the burden of translation can move. People no longer always have to decompose a goal into the product's predefined routes. Software can meet them at the level of the outcome, expose its interpretation, and provide the controls needed to correct it.
The inversion #
The document web began with a URL. The application web often begins with a route. Both assume that an interface structure exists before a particular intention enters it.
An intent-driven system can begin elsewhere:
What are you trying to accomplish?
That question changes what must be designed. The system needs ways to interpret goals, reveal assumptions, choose representations, request clarification, and expose valid actions. Those are requirements of an intent-first interaction; the mechanism that produces and constrains the resulting screen belongs to the runtime beneath it.
Today, intent is commonly the input a user must translate into an existing interface. In the inverted model, intent becomes an input to the production of the interface itself.
Once that happens, a screen can be assembled for the current task, revised as understanding changes, and retained only for as long as it remains useful.
The interface becomes a runtime artifact.