There's a specific tiredness that comes from opening software you don't use often. You know exactly what you want to do, export a report, change a permission, compare two plans but you don't know where the product keeps that option. You click around. You scan a settings page for a label that might mean what you think it means. Eventually you find it, but you didn't feel capable while looking. You felt like a guest hunting for the bathroom in someone else's house.
That feeling is the quiet cost of screen-based design, and it's why a growing number of product teams are rethinking what an interface is actually for.
Why are products moving from screens to intent?
For most of the software era, the working assumption was simple: users learn the product's internal structure, and the interface's job is to make that structure legible. Dashboards, tabs, menus, forms, all of it is scaffolding built around navigation. You don't tell the system what you want; you tell it where to go, one click at a time.
That works fine when a task is predictable and repeated often enough to become muscle memory. It works far less well when the tool is unfamiliar, the task is rare, or the product has grown so many features that even experienced users can't hold the whole map in their heads. Configuring a deployment, building a report, comparing account settings, these often mean navigating structure that reflects how the engineering team organized the system, not how a person actually thinks about the task.
Traditional interfaces ask users to learn where things are. What's changing is that products are increasingly asking what people want done instead, and handling the "where" themselves.
What does intent-driven design actually change?
Intent-driven design treats the user's goal, not their familiarity with a menu tree, as the starting point. Someone describes an outcome, in a search bar, a command palette, or plain language and the system determines which actions, screens, or data are relevant.
Side by side, a traditional flow for pulling a report looks like: open reports, pick a date range, choose a team, add filters, export. An intent-driven version compresses that into something closer to "show me the teams whose deployment failures went up this month, and export it as a CSV." The steps didn't disappear, the system still performs all of them, the person just no longer has to know or care about the order.
This isn't a hypothetical preference. Research on adaptive UX published in 2026 found that 71% of users now expect digital experiences to adapt to their intent, and 76% notice and feel frustrated by, friction when a product doesn't (source). People are starting to expect systems to do the interpreting, not just tolerate it when they do.
Does intent-driven design mean getting rid of the interface?
No, and this is where a lot of "AI-first" product talk gets it wrong. Replacing every visual control with a chat box tends to make products worse for tasks that need precision, comparing numbers, confirming an irreversible action, editing something exactly the way you meant it.
What's actually emerging is a division of labor. Natural language suits open-ended or multi-step requests, where the outcome is clear but the shortest path isn't. Visual interfaces remain better for confirmation, comparison, and fine editing, because a table or a form lets you see what you're about to change in a way a sentence can't.
The strongest version of this pattern lets someone state what they want, then hands them a visual surface to check the system's interpretation before anything happens, reviewing filters, adjusting parameters, approving the plan.
8080.ai's build process is a useful, concrete example of this pattern. A project there starts as a plain-language description. That gets turned into a requirements document and a set of proposed screens before any code is generated. Later changes arrive as diffs a person accepts or rejects, and a guided walkthrough pauses for approval before a build actually starts (source). It's a small but telling illustration of intent handling the interpretation while a visible surface handles the confirmation, the same underlying pattern showing up in a specific product rather than as an abstract design principle.
How should a system behave when it isn't sure what someone means?
This is the part of intent-driven design that's easy to get wrong, because ambiguity is unavoidable. "Show me last quarter's numbers" can mean three different things depending on fiscal calendar, region, or which "numbers" someone means. A system that guesses silently and acts on the wrong guess doesn't feel efficient, it feels untrustworthy, and untrustworthy software gets abandoned quickly.
Microsoft Research's widely referenced guidelines for human-AI interaction, developed and validated through research presented at CHI 2019, address this directly. Among the eighteen guidelines: make clear why the system did what it did, scope services when the system is uncertain rather than guessing confidently, and support efficient correction so a mistake doesn't mean starting over (source). In practice, that means surfacing the interpretation before an irreversible action runs, asking a focused clarifying question instead of a vague one, and letting someone edit a single step instead of restarting the whole task.
A well-behaved intent-driven system doesn't say "Done." It says something closer to: I found three inactive workspaces. Two still have active members, review the list before I archive anything. That single sentence does more for trust than a flawless guess would, because it shows its work.
What does this mean for the people building these products?
The designer's job shifts from arranging screens to defining behavior. Instead of only mapping a happy path, the work becomes mapping explicit intent, inferred intent, and the ways a request can be misread, then designing what the system does in each case.
Where a traditional interface asked the user to provide a sequence of clicks, an intent-driven one asks for a goal or a desired outcome. Where the old model handed back fixed screens, the new one offers contextual actions and surfaces built for the task at hand. The designer's job shifts from defining layouts and flows to defining behaviors, rules, states, and boundaries. When intent is unclear, the old pattern left the user to search or start over; the new one has the system ask a focused clarifying question. And trust itself is earned differently, not by faithfully following a visible flow, but by being able to inspect, confirm, and correct what the system proposes.
None of this points toward screenless software. It points toward software that hides unnecessary complexity while keeping the decisions that matter visible and correctable. The interfaces that get this right won't feel like magic, they'll feel like something that finally stopped asking you to think in its terms instead of your own.
Top comments (0)