The interface doesn't have to exist before the user
Does it make sense to design the user's intent first and generate the interface that resolves it afterwards, instead of building every screen in advance?
By Pietro Fiorillo ·
In this article
For years we have designed for every possible path
We build software in a fairly predictable way. First we define the features, then we turn them into screens, then we add navigation, forms, tables, filters and settings to cover everything we think the user might do.
It works. It also has a cost: people have to learn how our software is organised before they can use it.
When an application serves thousands of different users, every new need adds another piece: permissions, states, dashboards, tutorials, exceptions. The interface ends up as a map of everything the software can do, while one particular user usually needs to get one thing done.
Two different ideas under the label "AI interface"
The first is teaching an AI to use an interface that already exists. OpenAI introduced Computer-Using Agent, a system that can interpret a graphical interface and operate buttons, menus and text fields the way a person would.
The second is the one I care about here: an interface that changes according to what the user is trying to accomplish. That is where generative UI and adaptive interfaces come in.
In December 2025 Google published A2UI, an open project where agents send declarative interface descriptions that the client renders with its own components. According to the post it is a data format, not executable code. The model does not write arbitrary code for each screen. It composes the interface from a catalogue of pre-approved components.
The design question changes. It stops being which screens my application needs and becomes what the user needs to see right now to complete their goal.
| AI uses an interface | The interface adapts | |
|---|---|---|
| Example | Computer-Using Agent (OpenAI) | A2UI (Google) |
| What the system does | Interprets an existing interface and operates buttons, menus and fields | Describes the interface it needs; the client renders it with approved components |
| Who decides the look | The interface already built | The client's component catalogue |
What was observed: a study with 72 participants
In 2026 Google Research published a within-subject comparative study (N=72) of a deterministic banking interface against an adaptive generative one, using a digital banking prototype. The adaptive version scored 84.38 on the System Usability Scale against 53.96 for the deterministic one, with an effect size of d=1.04. Figures from the publication abstract, as of September 2026.
| Measure | Deterministic interface | Adaptive generative interface |
|---|---|---|
| SUS score | 53.96 | 84.38 |
| Participants | 72 (same people in both) | 72 (same people in both) |
That is what was observed. What follows is my interpretation.
Interpretation: part of the complexity is anticipation
My reading is that part of an interface's complexity exists because we try to anticipate every possible future of the user. If the system knows the intent, it can show only what is needed.
Instead of user, navigation, feature, settings and result, the flow would become intent, reasoning, tools, result and the interface that is needed. The interface stops being the starting point and can become a consequence of context.
One thing doesn't fit the most enthusiastic version of this idea: the study measures perceived usability on a prototype. It says nothing about maintenance, testing, security or the cost of a generated interface in production.
Why I don't want an interface that invents anything
I don't think the answer is asking a model to generate free-form HTML every time someone opens an application. That would be hard to control, maintain, test and secure.
That is why the A2UI approach looks closer to a real architecture: the agent decides which components it needs and the client keeps control of how they are drawn. Design doesn't disappear, it changes object. We used to design every screen. Now we design the system's capabilities, the available components, the rules, the permissions, the states, the boundaries and the ways an agent may combine them.
Design doesn't disappear, it changes object.
Hypothesis: from feature software to intent software
A hypothesis, not a conclusion: we are moving from feature-centred software to intent-centred software. Buttons, tables and dashboards will stay wherever they are the best way to work.
In a few years many applications may not need to show their full complexity upfront. Showing what you need to do what you want to do could be enough. To me that is a bigger change than adding a chatbot to an existing product.
Limits and what I would test next
One study, one prototype, one domain. I can't claim generative interfaces are better, and I haven't replicated anything myself: this entry is a review of sources, not an experiment.
The next step would be to test a limited component catalogue on a real internal tool, for example one of the management systems we build at MANYA Digital, and measure time to complete a task against the current interface. Until then, it stays a hypothesis.
Sources
Frequently asked questions
What is a generative interface?
The interface changes according to what the user is trying to achieve, instead of being a fixed set of screens built in advance. In the A2UI approach, the agent describes the interface it needs and the client renders it with a component catalogue approved beforehand.
How is A2UI different from Computer-Using Agent?
OpenAI's Computer-Using Agent interprets an interface that already exists and operates buttons, menus and fields the way a person would. Google's A2UI goes the other way: the agent sends a declarative description of the interface and the client draws it with its own components.
What does the Google Research study show?
In a within-subject study with 72 participants, an adaptive generative banking interface scored 84.38 on the System Usability Scale against 53.96 for the deterministic version, with an effect size of d=1.04. It is one study, one prototype and one domain, and it measures perceived usability, not business results.
Does this mean screens will disappear?
I don't think so. Buttons, tables and dashboards will keep existing when they are the best way to work. What changes is the object of design: instead of every screen, you design capabilities, components, rules, permissions and boundaries.
What would I test next?
A limited component catalogue on a real internal tool, measuring time to complete a task against the current interface. Until then, the idea stays a hypothesis.