Rebuild your UI for AI with a two-second rule

In January I wrote that your software’s interface was about to become irrelevant. The screens would collapse into a conversation. You would say what you wanted and the model would do the rest.

Ten months on, we have built two products with AI at the centre. One went almost entirely to conversation. The other kept a traditional screen and added an assistant you can summon. Both were the right call.

So January was half right. AI has changed what an interface should look like. It has not turned every interface into a chat box. The hard part is knowing which parts of your product go which way, and this post gives you a rule for deciding.

The designer nobody could learn

Our old analytics platform had a dashboard designer with 39 object types. Each type had its own screen, and each screen had hundreds of options. A day of training told you what was possible. Learning to use it properly took months, and most people never got there.

Studio replaced that designer. You say “build me a sales dashboard for the north region this quarter” and it builds one. There is no screen of options to hunt through because there are no screens.

What makes that work is not the chat box. It is what sits behind it. We tried letting the model generate the dashboard freely and it produced something different every time, so we gave it a vocabulary instead. Twelve object types, four kinds of filter, three widths, all expressed in a defined YAML format. The model composes a dashboard from that vocabulary once, at design time. Displaying it and refreshing it is deterministic code that never calls a model.

Google has now shipped the same shape as an open standard. In its A2UI protocol an agent can only request components from a catalogue the client application owns, and the client draws them. The model chooses, the code renders. That is the architecture that survived contact with real users, at Google and here.

Not everything wants a conversation

Now take a different task in a different product. You need to create an API key and set its permissions.

I do not want to talk to anything to do that. I want a form, a dropdown for the role, and a switch for each permission. A switch shows me the current state without my asking. I can see it is off, I can flip it, and I can see it is on. That is the whole job, and a sentence would make it slower.

Ben Shneiderman named this in 1983. Direct manipulation, visible objects, rapid reversible actions, immediate feedback. Forty years of software design built on it, and a chat box throws most of it away. Amelia Wattenberger has been arguing since 2023 that a blank text field has no affordances, and more recently that chat is AI’s command line, good for a coarse instruction and poor at the small corrections that follow.

Both camps are right about their own examples. Neither tells you where the line falls.

The two-second rule

Here is the rule we have arrived at. If a person can see the current state and reach the control in two seconds, draw the control. If they cannot, let them say what they want.

The API key screen passes. The old dashboard designer fails badly, not because any one screen was too big, but because the option you needed was three screens away and you did not know which three. A cluttered screen that technically fits everything fails too. If you are hunting, you are past two seconds.

I think there is a number underneath this. Some count of options above which a screen stops working and a sentence starts winning. I do not have it yet, so treat the two seconds as a hypothesis with a test attached rather than a law. The test is cheap. Sit someone unfamiliar with the screen in front of it, give them a task, and time it.

Why the model never moves the furniture

The strongest objection comes from the people who say generative UI makes fixed pages obsolete. If the model can draw a dashboard, it can draw the API key form too. When the state fits on a screen, let the model draw that screen. Why keep a fixed one at all?

Because we have run that experiment, and it failed. Office 2000 shipped personalised menus that reordered themselves around what you used. Microsoft’s own usability work found they slowed people down. Later studies found the same thing, static menus were significantly faster than adaptive ones, and moving an item broke the user’s memory of where it lived, with slower selection and more errors. By 2007 Microsoft had replaced the whole scheme with the ribbon, a layout that is fixed, visible and the same for everyone.

A control that can move is a control you relearn every time you open the product. The model is good at deciding what matters most right now. It is bad at being the same tomorrow, and habit needs sameness. So the model decides what to show first. It never decides where the controls live.

That still leaves the model a place on a fixed screen, and it is a different one. It guides the person who does not yet know where the switch is. The console we are building has an assistant you can summon, and its job is to route, not to answer. Ask it how you create an API key and it opens that screen, with the entry in the navigation rail highlighted so you can see how to get there yourself next time. The sentence replaces the path, but the path stays visible. That is how someone who starts in chat becomes someone who no longer needs it.

The one screen where the model gets a say

There is one deliberate exception to never moving the furniture. A landing page that lists what needs attention, most urgent first. Here the order is supposed to change every time you open it, because what matters changes, and the order is a judgement. Judgement is what models are for, so this looked like the one place the model should decide what goes where.

That console is a monitoring tool for a long-standing client. It has a fixed shell, and that list is its landing page. The first draft let a small, cheap model order it. The next day it was gone. A fixed severity ladder and a hand-weighted score, built from the warning signs the client’s senior engineers already use, order the list well, and every position can be explained. Ranking turned out to be easy to do deterministically, so there was no job left for a model’s judgement.

So even on the one screen built to move, the model does not decide the order. Its share shrank to a single sentence beside each item, explaining why it is where it is.

Start with the two seconds

AI has changed what a good interface looks like, and the change is not one chat box bolted onto the old maze. It is a split. Some parts of your product become a sentence. Some parts stay a switch. The job is working out which is which.

Walk your screens with a stopwatch. Where a new user can see the state and reach the control in two seconds, keep the control and let the model explain or route to it. Where they cannot, give them a sentence, a fixed vocabulary for the model to build from, and deterministic code to render the result.

Then keep the path visible. Where a control exists, the sentence should take people to it and show them how they could have got there alone. Do that and the novice who needs the chat and the expert who hates it are the same person, a few weeks apart.

This is a journey, and the balance will move. A screen that passes the two-second test today still passes it next year, because the test measures a person and a screen. What changes is the other side. As models get faster and better at reading intent and acting on it, the sentence loses friction, and more of the tasks that sit near the line will be easier to say than to click.

The number behind the two seconds is still to be found. The rule is not. Draw what people can see and reach. Let them say the rest.