The interface is becoming situational
Software used to show you features. Soon it will show you what matters right now.
There is a quiet history of interface design that nobody frames as a history. It goes like this: every decade or so, we change what software exposes to the user, and each time, we think we have arrived.
Menus exposed functions. You opened a program and it handed you a list of everything it could do. File, Edit, View, Insert, Format, Tools, Help. The assumption was clear: the user knows what they want, they just need to find the button. Software was a warehouse with labeled aisles.
Documents exposed content. The web shifted the unit of interaction from the function to the page. You didn't navigate capabilities, you navigated information. The interface receded. The content was the interface. This was genuinely better.
Feeds exposed relevance. Social platforms collapsed the document into a stream. You no longer chose what to look at. The system chose for you, based on signals — what you clicked, who you followed, what held your attention for an extra half second. The interface became a mirror that showed you a version of the world tuned to your patterns.
Chat exposed capability. The current era. You type what you want in natural language and the system attempts to do it. This felt like a revolution, and in many ways it is. But it introduced something that nobody talks about enough.
The hidden cost of the blank prompt
Chat interfaces require the user to initiate everything. They require you to know what to ask for. They require you to describe your situation before the system can respond to it. Every interaction begins with a cold start.
This is a regression.
A feed, whatever its problems, at least looked at you first. It observed your behavior and adapted. A chat window just sits there. It is the most capable and the most passive interface we have ever built. It can do almost anything, but it will do nothing until you explain, from scratch, what you need.
People describe chat as "natural." And it is, in the sense that conversation is natural. But consider the conversations you actually value. A good colleague doesn't wait for you to describe your problem from first principles. They see what you're working on, they notice the tension, they say: I think the issue is here. The conversation starts in the middle, not at the beginning.
Chat starts at the beginning every time.
What comes after chat
The next interface paradigm is not a new input method. It is the elimination of input as the primary interaction.
Situational interfaces sense where you are, what you're doing, and what tension you're likely experiencing — then surface only what's relevant. Not a menu of features. Not a feed of content. Not a prompt waiting for instructions. Just the right action, in the right context, at the right time.
This sounds abstract until you build it.
Imagine you're reading a technical document. A long one — architecture overview, system constraints, migration plan. You've scrolled to the section on database schema. A small overlay appears, not because you asked for it, but because the system detected what section is in your viewport. It offers three actions: extract the schema as a portable artifact, compare it against your current implementation, flag the constraints that conflict with your existing stack. You didn't type anything. You didn't switch contexts. The system read the room.
Now imagine you select a paragraph — a specific passage about rate limiting. The overlay changes. It's no longer offering page-level actions. It's offering selection-level actions: critique this approach, find prior art, rewrite for a different audience. The options shifted because your gesture shifted. You went from reading to focusing, and the system noticed.
Compare this to the alternative: a chat window in the sidebar that says "How can I help?" You would have to type: "I'm reading a technical document about database migration, specifically the section on schema design, and I want to extract the schema into a format I can use elsewhere." Everything the system could have inferred, you had to state.
Context detection is the new feature discovery
Building situational interfaces requires a fundamentally different kind of engineering. Traditional software engineering is about feature discovery — how do users find and invoke the things the software can do? You build menus, search bars, onboarding flows, tooltips, keyboard shortcuts. The entire UX discipline is organized around this question.
Situational software inverts it. The question is no longer "how does the user find the feature?" It is "how does the system detect the situation?"
This means parsing the page. Tracking which section is visible. Monitoring what the user has selected. Knowing the URL, the page type, the document structure. Building a context object — not from user input, but from environmental observation. And then generating actions dynamically based on that context. Not from a fixed menu. From what the system sees right now.
The engineering is closer to perception than construction. You are building a system that watches and interprets, rather than one that waits and responds.
The quiet implications
If you follow this line of thinking, certain artifacts of current software start to look like admissions of failure.
The homepage is an admission that the software doesn't know why you're here. If it knew, it would take you where you need to be.
The dashboard is an admission that the software doesn't know what matters to you right now. If it knew, it would show you only that.
The navigation menu is an admission that the software doesn't know where you are cognitively. If it knew, it would adjust its posture — not show you a map and ask you to find yourself on it.
This is not an argument for removing these things tomorrow. It is an observation about their nature. They are scaffolding for systems that cannot perceive.
Structure should support improvisation without announcing itself.
The best jazz musicians don't hand the audience a chart. The structure is there — changes, form, rhythm — but it operates beneath the surface. The audience experiences fluidity. The musician experiences support. The architecture is invisible because it is working.
Software has been handing users the chart. Here are your options. Here is your navigation. Here is your menu. Choose. The situational interface hides the chart. It reads the room, detects the key, and offers the next note.
What this requires us to give up
The hard part is not the technology. Parsing a page, tracking scroll position, detecting selection — these are solved problems. The hard part is giving up the assumption that users should navigate.
Navigation is control. It tells the user: you are in charge, you decide where to go. This feels respectful. But it is also a burden. Every navigation choice is a micro-decision, and micro-decisions accumulate into fatigue. People don't want to be in charge of the software. They want to be in charge of their work. The software should disappear.
A system that selects its own posture based on what it detects — that shifts from "thinking mode" to "execution mode" not because you clicked a tab, but because your behavior changed — feels different. It feels like the software is paying attention. Not managing you. Not constraining you. Just quietly keeping up.
People resist feeling managed. They resist feeling administrated. Chat is powerful precisely because it is permissive and improvisational. The opportunity is not to replace that fluidity with structure. It is to preserve the fluidity while stabilizing the execution underneath. The user improvises. The system holds the form.
We are not building smarter menus or better chat. We are building environmental awareness. The interface is becoming situational — not because we decided it should, but because every previous paradigm was a compromise with the fact that software could not see where you were.
Now it can.