The Future of User Interface Is Not Menus or Chat - It Is a Spectrum

The first AI feature in a product is usually a chat box.

It makes sense. Chat is the easiest interface to add when the model is the new thing. The user types what they want. The model streams an answer. Suddenly the product feels less like a set of menus and more like something that can listen.

Then the real work starts.

The user does not only ask for an explanation. They ask for a number, a table, a comparison, a form, a confirmation, a list of records, a next step, a risky action, a filter they cannot find, or a reason something changed.

And the chat box starts doing something strange.

It pretends text is an interface.

It writes a paragraph where a metric should be. It writes a markdown table where a browser should be. It says "I can help you refund this" where the product needed a confirmation step with real boundaries.

That is when the mistake becomes visible.

The future of UI is not "menus are dead."

It is also not "everything becomes chat."

The future is a spectrum.

The Old Model: Menus, Buttons, Dashboards

Traditional GUI is not dead. It is just being demoted from "the only interface" to "one important part of the interface."

Menus, buttons, dashboards, tables, forms, and fixed routes are still excellent for known workflows.

They are predictable. They are fast. They build muscle memory. They are easy to scan. They let a user repeat a task without negotiating with a model every time.

That matters.

A cashier should not have to ask an assistant how to close a receipt every time. A finance user should not have to wait for a model to decide what a date filter looks like. An admin should not watch the delete flow redesign itself based on the mood of a prompt.

Stable UI earns trust through repetition.

But the old model also has a cost.

It assumes the product team can predict the user's path ahead of time.

That works until the user's intent crosses several areas of the product:

• "Show me customers who ordered twice this month but have not ordered in the last week."
• "Why did revenue drop yesterday?"
• "Find suspicious orders and let me inspect them."
• "Create this customer, but I am missing the phone number."
• "Refund this order if it matches the duplicate charge."

In old UI, complex intent becomes a navigation problem.

The user has to know where the answer lives, which filters to combine, which screen owns the action, and which state matters.

That is where conversation helps.

The New Default Mistake: Everything Becomes Chat

Chat is genuinely useful.

It lets users express intent before they know the product structure. It handles ambiguity. It can explain, summarize, compare, translate, and reason across context.

For many tasks, language is the right starting point.

But chat has its own weakness: it turns every answer into a scroll.

Text is weak for structured work.

If the answer is a KPI, the user should not hunt for the number inside a sentence. If the answer is records, the user should not manually parse a markdown table. If the task requires confirmation, the user should not trust a friendly paragraph as the whole safety layer.

Chat also loses interaction density.

A table can sort. A browser can filter. A form can validate fields. A confirmation can disable buttons while an action is pending. A product card can show loading, empty, error, and disabled states without requiring the user to read a disclaimer.

Text can describe those states. UI can embody them.

That distinction matters.

The problem is not chat. The problem is forcing everything into chat because chat is the newest shape in the room.

That is just the old menu problem in reverse.

The Emerging Middle

The interesting layer is between fixed GUI and open-ended chat.

Sometimes the answer should be text.

Sometimes it should be a metric card.

Sometimes it should be a table or data browser.

Sometimes it should be a form.

Sometimes it should be a confirmation step.

Sometimes it should be a chart.

Sometimes it should be a set of suggested actions that continue the workflow.

The AI part is not that the model invents an entire interface from nothing every time. The AI part is that the model can understand the user's intent and route it to the right shape.

There are two broad ways to do this.

One is runtime-generated UI or code. The model creates a surface dynamically. This can be powerful for exploration, prototypes, or sandboxed contexts.

The other is trusted installed UI surfaces selected by the model. The product team owns the components, schemas, manifests, validation, data access, and actions. The model chooses from the surfaces the app explicitly allowed.

The second approach is less infinite.

It is also more production-shaped.

The UI Spectrum

A better mental model looks like this:

Static GUI
Conversational text
Trusted structured UI
Runtime-generated UI
Full app or code generation

Each part of the spectrum has a place.

Static GUI is best for known, repeated workflows. It is the checkout screen, the settings page, the dashboard the team uses every morning, the table with muscle memory.

Conversational text is best for explanation, ambiguity, synthesis, and asking before the user knows where to click.

Trusted structured UI is best when intent is dynamic but the output needs affordances. The user asks in language, and the product responds with a known surface: a metric, chart, data browser, form, confirmation, or suggested action list.

Runtime-generated UI is useful when the shape is not known ahead of time, but it needs stronger sandboxing, validation, and design constraints.

Full app or code generation is powerful for prototyping, internal tools, and exploratory software creation. It is not automatically the right model for trusted production workflows inside an existing app.

The mistake is treating one point on the spectrum as the future of everything.

The better question is:

What is the right shape for this intent?

Examples

Take a simple question:

What is today's revenue?

The right answer is probably a metric.

Not a paragraph. Not a table. Not an invented dashboard. A single number with context and maybe a trend.

Now change the prompt:

Show me all open orders.

The right answer is probably a data browser. The user needs rows, status, search, filters, sorting, pagination, and row detail.

Now:

Close table 7.

That is not just an answer. It is an action. The interface should probably include confirmation before the host app changes real state.

Now:

Create a new customer, but I am missing the phone number.

The right shape is a small form. The assistant can ask for the missing structured value, but the server still validates the result.

Now:

What should I do next?

That might become suggested actions: prompt-only options the user can choose to continue the workflow safely.

Now:

Explain why revenue dropped yesterday.

That might be text plus supporting UI: a chart, a metric, a table of source rows, or a data browser for inspection.

The product should not ask "How do we force this into chat?"

It should ask "What shape helps the user do the work?"

The Design Principle

AI does not remove interface design.

It makes interface orchestration more important.

The product team is no longer only designing screens. It is designing the rules for when each screen, component, or surface should appear.

That includes:

• what surfaces exist
• what each surface is for
• what each surface is not for
• what payload is valid
• what data the model may see
• what the host app must keep private
• what actions require confirmation
• what failures should look like
• what should remain fixed and boring

This is not less design. It is design at a different layer.

The best AI product interfaces will probably feel simple to users because the routing is good.

The user says what they want. The product chooses the right shape. The UI feels obvious after it appears.

That is the standard.

Where Fable UI Fits

Fable UI is one implementation direction for the trusted structured UI part of the spectrum.

The idea is to make AI-selectable product surfaces installable:

React component
tool schema
AI SDK tool definition
model-facing manifest
examples
eval prompts
docs

The model does not generate arbitrary UI code. It chooses from trusted surfaces the developer installed.

The host app still owns data access, authorization, validation, side effects, and business logic.

That is not the whole future of UI. It is one practical wedge into the middle layer.

Closing

The future is not menus versus chat.

That framing is too small.

Static GUI still matters because repeated work needs stability. Chat matters because intent is often messy before it becomes a workflow. Structured trusted UI matters because product work needs affordances. Runtime generation matters when exploration is the point.

The future interface is a spectrum because human intent is a spectrum.

AI does not kill UI.

It makes the shape of UI more important.

The durable question is not:

Should this be chat?

It is:

What is the right interface for this intent?