The near future: from screens to situations
The next interface may look familiar.
It may have navigation, a title, a table, several controls, and a button in the expected place. The visible elements already belong to today's software. The important change lies in why this particular set appears together.
A user may have asked why a project is late. The system gathered milestones from planning software, incidents from an operations service, absences from a calendar, and unresolved decisions from messages. It formed a temporary workspace with a timeline, three explanations, supporting evidence, and actions for revising the plan.
The interface looks like an application. Its organizing structure came from the present situation.
This is the restrained version of the forecast. Software keeps screens, applications, direct manipulation, stable workflows, and familiar controls. It gains another layer that can interpret a goal and compose those elements around it.
stable application
+
situational composition
=
software that can meet the user at the level of the task
The transition from screens to situations is therefore an expansion of the interface. The predefined screen remains a strong form. A runtime-produced workspace joins it.
The future arrives in fragments #
Large changes in interaction often begin as modest conveniences. Search reaches deeper into an application. A command palette exposes actions from anywhere. A recommendation links directly to the next useful step. An assistant explains the current screen. A generated summary appears above a familiar table.
Each feature reduces part of the translation between a goal and the product's structure. Together, they establish the parts of an intent-driven layer:
understand a request
find relevant information
identify valid actions
choose a representation
preserve context across steps
At first, the authored screen remains the centre. The assistant answers questions about it, fills its fields, or guides the user through it. The next stage allows local recomposition: a new comparison appears beside the existing report, an explanation becomes a review form, or a group of controls adapts to the current task.
Generated workspaces follow. The system assembles several representations around an intention and keeps the result alive across follow-up questions and actions. Cross-application composition extends that workspace with capabilities from other providers.
The progression can be gradual:
| Stage | Situational behavior |
|---|---|
| Assist | Explain the current screen and locate existing functions |
| Prepare | Fill forms, configure filters, and assemble drafts |
| Recompose | Add or rearrange regions around the current goal |
| Generate | Create a task-specific workspace from approved elements |
| Coordinate | Combine authorized capabilities across applications |
Products can enter this progression at different stages. A stable application can support an assistant long before its entire surface becomes composable. Each step can earn trust through useful behavior and visible control.
A situational layer #
The likely architecture contains two complementary layers.
The stable layer provides product identity, navigation, saved work, domain vocabulary, accessibility conventions, and reviewed workflows. It gives users familiar places to begin and return to. It also exposes the full capability map for browsing and learning.
The situational layer begins from an active goal. It interprets the task, selects relevant information, proposes actions, and forms a working surface. Its arrangement may last for a minute, a project, or a recurring practice.
stable layer
identity · capability map · conventions · history · recovery
situational layer
intent · interpretation · composition · adaptation · task context
The layers strengthen each other. The stable layer gives situational views consistent meaning. The situational layer makes the stable product more responsive to a user's immediate purpose. A generated workspace can link into a specialist screen, and a specialist screen can open a situational analysis around a selected object.
Users may move fluidly among several starting points:
- open a familiar workspace for repeated expert work;
- select an object and ask for an explanation;
- state a goal and receive a new working surface;
- browse capabilities before choosing a direction;
- reopen a saved situation and continue from its previous state.
The product becomes capable of both destination-oriented and intention-oriented interaction.
Where composition fits first #
Situational interfaces offer the greatest early value where tasks vary widely and information already spans several screens. Analysis, planning, investigation, support, coordination, and exception handling all fit this pattern.
A fixed report serves a known question efficiently. An investigation begins with uncertainty and develops as evidence appears. Runtime composition can add a timeline, comparison, map, explanation, or action panel as the inquiry takes shape.
Several properties favor early adoption:
| Property | Why composition helps |
|---|---|
| High variation among goals | The surface can follow the current task |
| Information spread across product areas | The workspace can bring relevant facts together |
| Exploratory work | Representations can develop with understanding |
| Reversible decisions | Users can inspect and refine proposals safely |
| Expensive navigation | Intent can shorten the route to a useful starting point |
| Strong domain capabilities | The composer has reliable facts and actions to work with |
Stable authored flows retain particular strength for frequent, precise, high-consequence actions. Repetition rewards learned layout. Regulation may require exact presentation. Safety may favor a narrow reviewed sequence. Expert tools often derive power from dense, persistent structure.
The practical question for a product team becomes:
Which parts benefit from situational composition?
Which parts benefit from durable structure?
How should users move between them?
This framing supports selective adoption. A banking application might generate an affordability workspace while preserving a stable payment authorization flow. A clinical system might compose a case summary while preserving a reviewed medication order. A development platform might assemble an incident investigation while preserving explicit deployment controls.
Conversation opens, interaction carries #
Natural language offers an unusually broad entrance to software. A person can describe an outcome using their own vocabulary, include unusual constraints, and change direction in a sentence. That makes conversation a powerful way to open a situation.
The work itself quickly benefits from other forms. People scan tables, compare charts, adjust values, select records, arrange objects, and review exact consequences. A generated interface turns an interpreted request into something visible and manipulable.
The near-future interaction therefore moves among modes:
say or select the goal
↓
inspect the system's interpretation
↓
work through generated representations and controls
↓
redirect through language or direct manipulation
↓
review and perform an authoritative action
Conversation provides breadth. Graphical interaction provides precision and overview. Stable controls provide learned behavior and confidence. The situational workspace combines them.
This also changes the role of the prompt. A blank text box asks the user to supply both a goal and knowledge of the system's possibilities. A richer starting surface can show recent work, available capabilities, relevant situations, examples, and familiar navigation. The user can speak, browse, select, or resume.
The future interface begins from many forms of intent. Language is one of them.
The machinery beneath the surface #
Generated HTML alone provides a weak foundation for this model. A dependable situational layer needs authoritative capabilities, semantic descriptions, deterministic rendering, explicit permissions, policy enforcement, and traceable composition.
Its structure may resemble:
intent and context
↓
task interpretation
↓
information and action planning
↓
semantic interface description
↓
validation against policy and interaction rules
↓
approved renderer
↓
authoritative domain capabilities
Models may contribute interpretation, planning, selection, explanation, and composition. Deterministic systems establish identity, permissions, values, transactions, required disclosures, and action execution. The visible workspace makes their relationship inspectable.
This architecture supports gradual improvement. A new model can improve task interpretation while the payment capability keeps the same contract. A renderer can improve accessibility across every generated workspace. A policy update can constrain all future compositions. A successful situational pattern can become a reusable template.
The system also needs memory at several timescales. Immediate interaction state preserves selections and edits. Task memory preserves decisions, evidence, and unfinished work. User preferences preserve accessibility choices and stable conventions. Organizational memory preserves policies and shared practices.
Memory turns a generated surface into a continuous working environment.
From release to operation #
In predefined software, release creates a relatively stable collection of experiences. Runtime composition continues producing arrangements in production. Product quality therefore becomes an ongoing operational practice.
Teams will need to observe more than clicks and conversion. They need evidence about the relationship between interpretation and outcome:
- which intentions the system recognizes well;
- where users correct its understanding;
- which assumptions change decisions;
- which compositions become saved workspaces;
- where users choose a stable screen;
- which capability combinations create confusion;
- how experience quality varies across languages, abilities, roles, and data conditions.
Evaluation joins conventional testing. Component behavior, schema validation, permissions, security, and accessibility remain deterministic concerns. Scenario suites assess relevance, clarity, continuity, and appropriate action. Production observation reveals situations beyond the team's initial examples.
Every generated artifact can carry a trace of its formation: the interpreted task, source data, selected capabilities, policy decisions, component versions, and user corrections. That trace supports explanation, support, audit, and improvement.
The runtime produces the interface; the organization retains responsibility for the system that produces it.
The pressure toward adaptation #
Once users experience software organized around a goal, traditional navigation can feel like avoidable translation. A customer who can ask, “Which subscription changed price, and what would I save by cancelling it?” gains a direct path across transactions, merchant history, recurring-payment detection, and forecasting.
This creates competitive pressure. Products with clear capability contracts become easier to include in assistants and cross-service workspaces. Products with strong semantic components can support richer composition. Products with reliable provenance and action boundaries can earn permission for more consequential tasks.
The pressure also reaches internal architecture. Data trapped behind screen-specific endpoints constrains composition. Actions coupled tightly to one frontend resist reuse. Ambiguous permissions and undocumented business rules make generated interaction fragile. Preparing for situational interfaces encourages products to separate domain capabilities from presentation while enriching the contracts between them.
The architectural shift can begin before a generated interface reaches customers. A product team that makes capabilities explicit gains clearer testing, stronger policy enforcement, and greater freedom across web, native, assistant, and embedded surfaces.
Interface evolution and software architecture move together, as they did when the web moved from documents to applications.
The risks shape the form #
Situational interfaces concentrate several forms of influence. The system interprets a goal, selects information, chooses a representation, ranks possible actions, and decides which capabilities enter the workspace. Personalization makes those choices feel especially relevant.
This influence will shape the stable protections around the runtime:
- visible separation among facts, estimates, assumptions, and recommendations;
- persistent identity for the providers behind data and actions;
- consistent treatment of consequential controls;
- user control over adaptation, history, and saved arrangements;
- clear disclosure of commercial influence and ranking criteria;
- accessible fallbacks and durable preferences;
- review and recourse for actions with material effects;
- evaluation across populations and contexts.
The strongest systems will treat these protections as part of their interaction grammar. Trust will emerge from inspectable behavior repeated across many situations.
Pressure for convenience will coexist with pressure for accountability. A seamless task can still reveal the seams that identify authority and responsibility. A personalized surface can still preserve common meanings. An adaptive workspace can still provide stable landmarks.
The quality of the future interface will depend on how well it holds these properties together.
What the near future feels like #
For the user, the transition may feel less dramatic than the architecture beneath it.
They open a product and see familiar recent work. They describe a goal, select a record, or accept a contextual suggestion. A workspace forms around the task. Its heading states the system's interpretation. Its values carry sources. Its estimates reveal assumptions. Its controls come from capabilities the user can inspect and authorize.
As the user works, the surface grows locally. A comparison becomes a plan. A plan becomes a set of prepared actions. Stable regions preserve orientation. The user can save the arrangement, share it, return to its history, or open a specialist application for deeper work.
Across applications, the same task can continue. A travel plan gathers calendar availability, company policy, provider offers, payment, and expense capture. Each service remains identifiable. The working artifact belongs to the situation.
The user gradually spends less effort translating goals into product taxonomies. Software assumes more responsibility for finding the relevant concepts and presenting their relationship.
That is the practical meaning of intent first.
From screens to situations #
The web began by delivering documents. It grew into a runtime for applications. Those applications filled predefined structures with dynamic data and gave users increasingly rich ways to manipulate state.
AI introduces a change at a different boundary. It allows software to interpret why a person has arrived before deciding which interaction should meet them.
The sequence becomes:
document
↓
interactive page
↓
client application
↓
intent-driven situational workspace
Each stage preserves much of the one before it. Documents remain inside applications. Server rendering remains beside client rendering. Forms, tables, charts, buttons, routes, and design systems continue to carry interaction. The new layer changes how these elements are selected, assembled, and connected to a goal.
The central inversion is simple:
today
interface first → user translates intent into its structure
emerging model
intent first → software forms an interface around the situation
The consequences reach design practice, testing, architecture, product boundaries, trust, and the shared experience of software. Their arrival will be uneven. Some tasks will remain anchored in stable screens. Some will gain generated regions. Others will begin from an intention and produce an entire workspace.
The defining interface of the near future is therefore a layered one: stable enough to learn, constrained enough to trust, expressive enough to adapt, and open enough to form around the work a person is actually trying to do.
The screen remains. The situation becomes its author.