For the last 30+ years, user experience has steadily evolved around one major problem: how do we help people navigate increasing complexity?

As applications became larger, data became richer, and business processes became more interconnected, we created user experience patterns to help users cope. Screens separated work into manageable contexts. Menus created maps through the application. Toolbars exposed actions. Tabs, accordions, filters, dashboards, and grids helped users manage large volumes of data.

These patterns were not accidental. They emerged because users needed structure.

But we are now entering a different phase.

The next major shift in user experience is not simply about making screens cleaner or adding chatbots to existing applications. The deeper change is this:

The user experience is moving from data-first to intelligence-first.

In a data-first user experience, the application shows users records, lists, fields, filters, dashboards, and forms. The user is responsible for interpreting the data and deciding what matters.

In an intelligence-first user experience, the application starts with intent, context, insight, explanation, and action. The system extracts meaning from the data, presents what matters first, explains why it matters, suggests what can happen next, and still allows the user to drill into the underlying records when needed.

That distinction is important.

The future of UX is not “AI replaces UI.”

The future of UX is that UI becomes more contextual, adaptive, explainable, and action-oriented.

The Traditional UX Model: Helping Users Navigate Data

Most enterprise and productivity applications today are still built around a familiar model:

1. The user opens a screen.
2. The user searches or filters.
3. The user reviews a list of records.
4. The user opens a record.
5. The user interprets the data.
6. The user decides what action to take.
7. The user clicks a button, submits a form, or starts a workflow.

This model has served us well. It gave users a predictable structure for working with large systems.

The most common UI patterns exist because they solve specific complexity problems.

Screens

Screens separate data and actions into specialized areas of the application. A customer screen, asset screen, order screen, project screen, approval screen, report screen, or task screen gives the user a place to work.

Screens answer the question:

“Where am I?”

They create boundaries and context.

But screens also create friction. The user needs to know which screen to open, which related data matters, and how the current screen connects to other parts of the business process.

As systems become more connected, a single user decision may depend on information spread across multiple screens, records, documents, events, rules, and workflows.

Traditional screens can display this information, but they often struggle to decide what is relevant right now.

Menus

Menus exist because applications contain many screens and features. They provide a discoverable map of the application structure.

Menus answer the question:

“Where can I go?”

They are useful, but they also require users to understand the application’s structure. The user must translate their intent into navigation.

The user may think:

“I need to know what needs attention today.”

But the application may expect them to know:

“Open this module, go to this screen, apply these filters, group by this field, sort by this date, and inspect the result.”

That translation cost is a major UX burden.

Toolbars

Toolbars expose actions. They tell users what they can do in the current context.

Toolbars answer the question:

“What can I do here?”

But actions are often context-sensitive. Some actions require a selected record. Some require permission. Some are only valid in a certain state. Some are dangerous if performed at the wrong time.

The user needs to understand not only what action exists, but whether it is relevant, safe, and correct.

Tabs, Accordions, Groups, and Panels

Tabs and accordions help hide complexity. They group information into manageable sections.

They answer the question:

“What information belongs together?”

This is useful, but it has a downside. Hiding information reduces noise, but it can also hide relevance.

In complex systems with many fields, users often do not know which tab, collapsed group, or panel contains the information they need. This creates a strong reliance on training, help files, tribal knowledge, and repeated usage just to learn where data is located. That is a significant usability issue because the user’s success depends less on the clarity of the interface and more on their memory of how the application is organized.

An important detail may exist somewhere in the interface, but still be practically invisible because the user does not know which tab to open or which section matters right now.

That is one of the key weaknesses of traditional UX:

Traditional UX organizes complexity, but it does not always understand relevance.

Tiny spicy take: tabs are civilized hiding places. Useful, yes. But also excellent at making important information disappear politely.

The Problem With Data-First UX

Data-first UX assumes that the user knows what they are looking for.

It assumes the user can:

• find the correct screen,
• understand the application structure,
• apply the correct filters,
• interpret the correct records,
• identify exceptions,
• understand relationships,
• decide which action is appropriate,
• know when supporting evidence is missing.

That assumption breaks down when systems become deeply connected.

Modern work is rarely isolated to one record or one screen. A single decision may depend on related records, historical patterns, policies, permissions, documents, events, risk signals, availability, timing, and business rules.

Traditional UX can display all of that data, but it often leaves the user to connect the dots manually.

This is where intelligence-first UX becomes important.

What Is Intelligence-First UX?

Intelligence-first user experience is a design approach where the system prioritizes user intent, contextual understanding, insight extraction, guided exploration, and safe action over raw data presentation.

Instead of starting with a list of records, the system starts with what matters.
Instead of asking the user to find the insight, the system surfaces the insight first.
Instead of making the user manually inspect every detail, the system explains why something matters and provides a path to the supporting evidence.

A simple structure for intelligence-first UX is:

Insight ↓ Explanation ↓ Recommended action ↓ Supporting evidence ↓ Detailed records

This does not remove the need for records, grids, forms, or dashboards. It changes their role.

• The grid becomes the evidence layer.
• The dashboard becomes the question-driven view.
• The form becomes the action surface.
• The screen becomes a context container.
• The menu becomes less central because intent routing becomes more important.

Intelligence-first UX also changes how applications collect and update information. Relevance is not only about what data the system fetches or displays; it is also about what information the system asks the user to provide.

In traditional applications, creating a new record often means presenting a large form with every possible field, even when many of those fields are not relevant to the user’s current intent.

In an intelligence-first experience, the form should start with the information that matters for the task at hand, while still allowing the user to opt into additional fields when needed.

For example, when creating a new work order, the user should not be forced through every field in the system. The application should ask for the details required to create a useful work order, then suggest additional fields based on context, history, role, asset type, risk, or organizational rules. If a user consistently adds notes when creating work orders, the notes field can become part of their default experience.

If the user explicitly says, “Always include the notes field when I create work orders,” that preference can become personal memory. If an organization decides that notes should always be captured for certain work types, that becomes organizational memory or policy. The goal is to keep the experience relevant not only when retrieving information, but also when deciding what should be captured, updated, suggested, or required.

From Records to Insights

The biggest shift is this:

The default unit of interaction changes from the record to the intent.

In traditional UX, the default view is often a list:

• all orders,
• all tasks,
• all assets,
• all documents,
• all approvals,
• all tickets,
• all customers,
• all transactions.

In intelligence-first UX, the default view should be closer to:

• items likely to miss a deadline,
• records requiring attention,
• risks that changed today,
• approvals blocked by missing evidence,
• anomalies in recent activity,
• tasks that can be automated,
• entities with deteriorating performance,
• decisions that need human confirmation.

The user can still drill into the list of records, but the first experience is no longer “here is everything.”

The first experience becomes:

“Here is what matters, why it matters, and what you can do next.”

That is the heart of intelligence-first UX.

Search Is Becoming an Intent Interface

One of the clearest signs of this shift is the evolution of search.

Traditional search returns links or records. The user then opens results and evaluates them.

AI-enhanced search is moving toward synthesis, follow-up, context, and dynamic presentation. Recent Google Search updates point in this direction, with AI Mode supporting longer conversational queries, multimodal inputs such as files and images, context-preserving follow-ups, and generative UI patterns such as custom widgets and dynamic views. (The Verge)

That matters because search is no longer only a retrieval tool.
Search is becoming an intent interface.
The user does not only search for a record. The user expresses a goal:

“What changed since yesterday?”
“What should I look at first?”
“Why did performance drop?”
“Which items are blocked?”
“What are the biggest risks this week?”
“Prepare a summary for review.”

The result should not always be a list. Sometimes it should be a summary, chart, timeline, comparison, recommendation, or workflow panel.

This is one of the most important UX changes post-2026:

Search becomes less about finding data and more about turning intent into information.

Micro UI: The Bridge Between Chat and Applications

A second emerging pattern is what we can call micro UI.

A micro UI is a small, context-specific interface that appears inside a conversational, agentic, or intent-driven experience.

It is not a full application screen. It is also not just a text answer.

It may be:

• a chart,
• a mini dashboard,
• a comparison card,
• a record preview,
• an approval panel,
• a form,
• a timeline,
• a map,
• a checklist,
• a simulation,
• a drill-down table,
• a workflow step.

This pattern is already visible in emerging assistant-based platforms. OpenAI’s Apps SDK lets developers design both the logic and interface of an app that runs inside ChatGPT, and it is built on the Model Context Protocol as a standard for connecting external tools and data. (OpenAI Help Center) OpenAI’s MCP apps documentation also describes internal MCP-powered apps that can include interactive UI and support write or modify actions after organizational review and publishing. (OpenAI Help Center)

MCP Apps follow the same wider pattern. The official MCP Apps documentation describes interactive UI applications that render inside MCP hosts, including data visualizations, forms, dashboards, rich media viewers, real-time monitoring, and multi-step workflows. It also highlights context preservation, bidirectional data flow, host integration, and sandboxed security as reasons to render UI inside the conversation instead of sending users to a separate web app. (Model Context Protocol)

Claude Artifacts show a related direction. Anthropic describes artifacts as substantial, self-contained outputs such as apps, tools, visualizations, or documents that appear in a dedicated space separate from the main conversation, making them easier to edit, iterate on, reuse, or refer back to later. (Claude Help Center)

The pattern is clear:

Conversation captures intent.
Tools connect to data and actions.
Micro UI provides the right interaction surface.

This is not “chat replaces applications.”

It is more accurate to say:

Chat becomes a coordination layer for contextual UI.

That is a much stronger and more realistic design model.

Dynamic UI Does Not Have to Mean Runtime Code Generation

There is an important architectural distinction here.

Some emerging AI experiences are moving toward generative UI, where the interface is assembled dynamically based on the user’s query. Google’s recent Search direction points toward this kind of experience, with AI-generated or dynamically composed result views, interactive components, and agentic capabilities. (The Verge)

That is exciting, but enterprise and business applications need to be careful.

Letting AI generate arbitrary UI code at runtime creates serious concerns:

• security,
• accessibility,
• testing,
• consistency,
• auditability,
• performance,
• permission handling,
• supportability,
• regulatory compliance.
• token cost

A safer enterprise pattern is:

Generate UI composition, not UI code.

Instead of allowing an AI model to invent a screen from scratch, the system should select and compose approved components from a trusted registry.

For example:

• RiskSummaryCard
• EvidenceGrid
• TrendChart
• ComparisonPanel
• ApprovalPanel
• RecommendedActionsPanel
• DocumentViewer
• TimelinePanel
• FilterPerspectivePanel
  

The intelligence layer can decide:

“For this user intent, show a risk summary, a trend chart, supporting records, quick perspective filters, and recommended actions.”

But the components themselves are prebuilt, tested, accessible, secure, and governed.

This gives us dynamic, context-sensitive UX without turning the product into a runtime code-generation casino. Fun at a hackathon, scary in production.

The enterprise-safe principle is:

The intelligence layer should choose the experience. It should not be allowed to invent unrestricted interface code.

Screens Become Context Containers

Screens will not disappear. That is too simplistic.

Instead, their role changes.

In traditional UX, a screen is usually tied to an entity or module:

“This is the customer screen.”
“This is the project screen.”
“This is the order screen.”
“This is the approval screen.”

In intelligence-first UX, a screen becomes a context container.

The same entity may need a different interface depending on what the user is trying to do.

For example, the user may interact with the same record in different contexts:

Intent	UI should prioritize
Create	required fields, validation, defaults
Review	summary, changes, exceptions
Approve	risk, evidence, policy, impact
Investigate	history, relationships, anomalies
Plan	dependencies, availability, constraints
Execute	instructions, status, next steps
Close	outcome, evidence, completion checks

The entity is the same.
The intent is different.
Therefore, the UI should adapt.

This is one of the core ideas behind intelligence-first UX:

Context is not just where the user is. Context is what the user is trying to accomplish.

Menus Become Intent Routing

Menus will also not disappear, but they become less dominant.

Traditional menus are a map of the application.

Intent-first systems need something more powerful: a semantic map of capabilities.

The user should not always need to know where a feature lives. They should be able to express what they want to achieve, and the system should route that intent to the correct capability.

The flow changes from this:

Menu – Select a menu item from the main navigation.
↓
Screen – Open the screen or module linked to that menu item.
↓
Filter – Apply filters, searches, sorting, or saved views to reduce the data set.
↓
Record – Select a specific record from the list or result set.
↓
Action – Perform an action on the selected record, such as edit, approve, assign, export, or close.

To this:

Intent – The user expresses what they want to know or do.
↓
Classification – The system identifies the type of request and expected outcome.
↓
Context retrieval – The system gathers relevant data, rules, permissions, history, and current context.
↓
Relevant capability – The system routes the intent to the correct tool, workflow, service, or component.
↓
Micro UI – The system presents the focused interface needed for the task.
↓
Action or drill-down – The user acts, refines the request, or inspects the supporting evidence.

This is why modern AI application architectures increasingly emphasize tools, connectors, apps, workflows, and protocols.

The application menu is no longer only a visual navigation structure. It becomes a capability registry that intelligent systems can route to.

Toolbars Become Recommended Action Surfaces

Toolbars traditionally show what actions are available.
Intelligence-first UX should show which actions are relevant.
That is a meaningful difference.

A traditional toolbar says:

Create | Edit | Delete | Export | Approve | Reject | Assign | Close

An intelligence-first action surface says:

Recommended next steps: 1. Approve these low-risk items. 2. Review these exceptions before approving. 3. Request missing evidence for these records. 4. Escalate this item because it is blocked.

The action surface becomes a decision-support area.
But there is a catch: recommendations must be explainable.

The system should not simply say:

“Do this.”

It should say:

“This action is recommended because…”

That explanation should include enough evidence for the user to verify the recommendation.

This leads to a design rule:

Never show recommended actions without showing the reason and supporting evidence.

Suggested actions should not mean hidden actions.
Even when the system prioritizes the most relevant next steps, the full set of available actions still needs to remain discoverable.
The difference is that discovery no longer has to depend only on visible toolbar buttons.

Users should be able to express the action they want through intent or a chat-style interface, such as “export these records,” “assign this to my team,” “show approval options,” or “what else can I do here?”

The system can then resolve that request against the user’s permissions, the current context, and the available capabilities. This keeps the interface clean without removing power.

Recommended actions become the default path, while intent-based discovery allows users to access less common actions when needed.

Grids Become Evidence Layers

Grids are not going away.

Anyone who says enterprise applications will not need grids anymore has probably not worked with real operational data. Grids are still essential for comparison, bulk review, filtering, export, inspection, and audit.

But their default role changes.

In data-first UX, the grid is often the starting point.
In intelligence-first UX, the grid is the evidence layer beneath an insight.

For example:

Insight:
23 records require attention today.

Why:
– 8 are blocked by missing information.
– 6 have deadline risk.
– 5 have approval conflicts.
– 4 have unusual activity.

Evidence:
[Open supporting records]

The grid should not always be visible by default. In an intelligence-first experience, the user should first see the insight, summary, explanation, and recommended actions. The underlying records should become visible when the user opts into the evidence, for example by selecting “show supporting records,” “view evidence,” or “open details” from the summary.

When the user chooses to inspect the underlying data, the grid should appear in a way that matches the current intent. The grid is still valuable, but it should not default to showing every field on every record. If the user is looking at records with deadline risk, the grid should show the columns that explain that risk, such as due date, current status, responsible owner, delay reason, priority, and recommended next step.

This creates a healthier relationship between insight and data. The system does not hide the records; it makes them available at the point where the user wants to validate, inspect, or act on the evidence. It also avoids forcing the user to start with a generic, overloaded table before they understand what matters.

The user should still be able to opt into more detail. They may expand a row, open the full record, add additional columns, switch to a full-field view, or ask for more information through intent, such as “show me the full details for this record” or “add the approval status and last modified date.” The default experience should show what the user needs to understand the insight, while still allowing deeper inspection when needed.

These statements of intent does not have to be defined using chat but actionable items on the UI. As long as it is discoverable.

What Happens to Filters and Query Builders?

One of the important questions in intelligence-first UX is what happens to advanced filtering, custom query builders, saved searches, and complex grid configuration.

These features exist for a reason.

In traditional applications, users often need to reshape large data sets to match the work they are trying to do. A user may start with thousands of records and then apply filters to create the context they need.

For example:

Status = In Progress
Assigned Team = My Team
Due Date = This Week
Priority = High
Location = Current Site

This is a very common pattern in business applications. The application gives the user a large data set, and the user uses filters to reduce it into something meaningful.

The problem is that the user is doing a lot of work to express intent through fields, operators, values, and relationships.

The user is not really trying to say:

“Show me records where status equals in progress and planned date is less than today.”

The user is trying to say:

“Show me the work currently being handled.”

Or:

“Show me what changed in the last 24 hours.”

Or:

“Show me what needs my attention.”

In other words, traditional filters are often a technical expression of a human intent.

Intelligence-first UX should make that intent explicit.

Users Should Not Need to Understand the Application Ontology

One of the hidden problems with traditional filters and query builders is that they require users to understand the internal ontology of the application.

To build a useful filter, the user often needs to know:

• which entities exist,
• what those entities are called,
• how entities relate to each other,
• which fields exist on each entity,
• which fields are searchable,
• which field values are valid,
• which date field matters,
• which status field reflects the real business state,
• whether the data they need is on the main record or a related record.

That is a lot of hidden knowledge.

A user may simply want to know:

“What work is currently blocked?”

But the application may expect them to understand that “blocked” is not a single field. It may depend on status, assignment, approval state, dependency records, missing documents, unavailable resources, external responses, workflow state, or policy rules.

The user is not trying to understand the database model.
The user is trying to answer a business question or complete a task.
Traditional query builders often make users think like the application’s data model.

Intelligence-first UX should allow users to think in terms of their own intent.
The system should understand the ontology.
The user should not be forced to.

The System Should Translate Intent Into Ontology

In an intelligence-first experience, the application should act as a translation layer between human intent and the underlying data model.

The user expresses what they need:

Show me what is blocked.

The system translates that into the relevant entities, fields, relationships, and rules:

Blocked may include:
– records waiting for approval,
– records missing required information,
– records waiting for resources,
– records with unresolved dependencies,
– records assigned to unavailable people,
– records stopped by policy or compliance checks.

The system can then present the result in a way the user understands:

Blocked work:
– 8 waiting for approval
– 5 missing required information
– 3 waiting for resources
– 2 blocked by policy checks

The user does not need to know the schema behind that result. They only need to know what the result means and how to act on it.

This is one of the most important differences between traditional UX and intelligence-first UX.

Traditional UX exposes the ontology to the user.
Intelligence-first UX uses the ontology on behalf of the user.

From Filters to Perspectives

Instead of making users build every view manually, intelligence-first applications should provide context-aware perspectives.

A perspective is a meaningful view of the data based on intent, persona, and current context.

For example, a user may want to switch between:

• Currently being worked on
• Finished in the last 24 hours
• At risk of delay
• Waiting for approval
• Blocked by missing information
• Assigned to my team
• Requires my attention
• Recently changed

These are still filters underneath, but the user does not need to think in raw query terms.

The interface changes from: Field + operator + value
To: Intent + context + perspective

That is a better user experience because it matches how people think about their work.

Intelligent Filters Should Be Persona-Aware

Not every user needs the same filters.

A planner, supervisor, technician, manager, auditor, analyst, or administrator may all look at the same underlying data, but their most useful perspectives are different.

A technician may care about:

• My active work
• Work near me
• Work blocked by access
• Work requiring safety checks
• Work completed today

A manager may care about:

• Team workload
• Deadline risk
• Work completed in the last 24 hours
• Escalations
• High-impact delays

An auditor may care about:

• Records missing evidence
• Recently modified records
• Policy exceptions
• Approval history
• Compliance gaps

This means intelligent filters should be based on persona and context.

The application should not show every possible filter by default. It should show the quick filters that are most relevant to the current user, current task, and current data set.

This reduces noise without removing power.

Quick Filters Become Contextual

In many current applications, quick filters are static. They are configured once and shown to everyone.

In intelligence-first UX, quick filters should become contextual.

For example, if the user is viewing active work, the quick filters may be:

• Assigned to me
• Overdue
• Blocked
• High priority
• Due today

But if the user changes perspective to recently completed work, the quick filters should change:

• Completed in last 24 hours
• Completed by my team
• Completed with exceptions
• Completed late
• Requires review

The data set changed, so the relevant filters changed.
This is a subtle but important shift.

The application should not ask the user to manually rebuild the context every time. It should understand the current perspective and offer the most useful refinements for that perspective.

Natural Language Becomes the Advanced Query Builder

This does not mean advanced filtering disappears.

Some users will still need detailed control.
There will always be cases where a user wants to express a more specific query.

The difference is that the advanced query builder no longer has to be only a complex form full of fields, operators, joins, and nested conditions.

The user should be able to say:

Show me completed work from the last 24 hours where the priority was high and the completion notes mention a delay.

Or:

Show me active records assigned to my team, excluding anything waiting for resources.

Or:

Show me items that were closed this week but reopened within 48 hours.

The system can translate the natural language intent into a structured query, then show the user what it understood before applying it.

For example:

I understood this as:
– Status: Completed
– Completed Date: Last 24 hours
– Priority: High
– Completion Notes: Contains “delay”

Apply this filter?

That confirmation step is important.
It keeps the experience safe, understandable, and auditable.

Filtering Becomes a Conversation About Context

In traditional applications, filtering is mechanical.

The user adds conditions until the result looks right.

In intelligence-first UX, filtering becomes a conversation about context.

The user may start with:

“Show me current work.”

Then refine:

“Only show work assigned to my team.”

Then change perspective:

“Now show what was completed in the last 24 hours.”

Then ask:

“Which of those had issues?”

Each step changes the context, but the user should not have to start over.

The system should preserve the conversation, explain the active perspective, and make it clear what data is currently being shown.

A good intelligence-first interface should always answer:

What am I looking at?
Why am I seeing this?
Which filters or assumptions are active?
How can I change the perspective?
How do I drill into the records?

This becomes especially important when the user moves between different intents in the same session.

Intelligent Suggestions Should Nudge the User Forward

Once the system understands the user’s intent, persona, and current context, it should not only return data. It should help the user move forward.

For example, after showing blocked work, the system might suggest:

Suggested next steps:

• Review items waiting for your approval.
• Request missing information from the responsible owner.
• Escalate items blocked for more than 48 hours.
• View the records with the highest deadline risk.

These suggestions should be based on:

• the user’s role,
• the current task,
• the selected data,
• business rules,
• permissions,
• urgency,
• historical behaviour,
• organizational policy.

This is where persona-aware UX becomes important.

A supervisor, analyst, auditor, field worker, manager, or administrator may all ask similar questions, but the appropriate next steps may differ.

The same insight can produce different suggestions depending on who is looking at it and why.

That is the difference between a system that merely displays information and one that supports the user’s work.

Default Filters Should Be Designed, Not Generated Randomly

The safest approach is not to let AI invent filters freely.

Instead, applications should define common intent-based filters for each persona and context.

For example:

Persona: Supervisor Context: Active Work Default perspectives: – Currently in progress – At risk – Blocked – Due today – Recently completed

Persona: Auditor
Context: Review

Default perspectives:
– Missing evidence
– Modified after approval
– Policy exceptions
– Incomplete close-out
– High-risk changes

These default filters can be configured and governed like any other part of the application.

The intelligence layer can help select the most relevant filter, explain it, and allow the user to refine it using natural language.

That gives us a practical middle ground:

• Predefined intelligent filters for common use cases.
• Natural language refinement for advanced cases.
• Structured queries underneath for reliability.

The New Role of Query Builders

Query builders still have a place, especially for advanced users, administrators, analysts, and reporting scenarios.

But they should no longer be the primary experience for most users.

Their role changes from:

“Everyone must build the view they need.”

To:

“Advanced users can inspect, refine, save, and govern complex views.”

A good intelligence-first system may still expose the structured query behind an intent.

For example:

Perspective: Finished in the last 24 hours

Underlying query:
Status = Completed
Completed Date >= Now – 24 hours

This gives power users transparency and control.
It also allows organizations to save, share, govern, and audit common filters.

Design Principle: Filters Should Express Intent

The core principle is this:

Filtering should move from technical query construction to intent-guided exploration.

Traditional filtering asks the user to think like the database.

Intelligence-first filtering allows the user to think like a person doing work.

The system should provide:

• sensible default perspectives,
• persona-aware quick filters,
• context-sensitive refinements,
• natural language filter expression,
• visible active assumptions,
• drill-down into underlying records,
• optional structured query inspection for advanced users.

The goal is not to remove filters.

The goal is to stop making users manually construct context that the system should already understand.

Dashboards Become Question-Driven

Traditional dashboards are predesigned. They answer questions someone predicted in advance.

That is useful, but limited.

Intelligence-first dashboards are question-driven.

The user asks:

“Why did performance drop this month?”

The system composes a temporary view:

• trend chart,
• top contributing factors,
• anomalies,
• affected categories,
• relevant records,
• recommended actions,
• evidence and assumptions.

Again, this does not require arbitrary runtime code generation. The system can compose a dashboard from approved components.

The point is that the dashboard becomes responsive to the question.
The user is no longer limited to dashboards someone designed six months ago.

Memory Shapes the Experience

A major difference between traditional UX and intelligence-first UX is how the system remembers.

Most current applications already have a form of memory. It usually appears as:

• saved dashboard profiles,
• saved filters,
• saved searches,
• user preferences,
• column layouts,
• default views,
• pinned reports,
• favorite screens,
• configurable widgets.

This is useful, but it is mostly static memory.

A user or administrator creates a profile, saves it, names it, and later selects it from a list. Over time, organizations can end up with hundreds of saved profiles, dashboards, filters, and views. The original goal was to make navigation easier, but the result can become another navigation problem.

The user no longer only asks:

“What data do I need?”

They now also need to ask:

“Which saved profile has the data I need?”
“Which dashboard view is the latest?”
“Which filter did my team use last month?”
“Which of these 80 profiles applies to this context?”

That is the limitation of static memory.

It remembers configuration, but it does not understand intent.

Intelligence-first UX changes this.

Instead of forcing users to find the correct saved profile, the system should build or select the right view based on the current intent, persona, context, and history.

The experience moves from:

Select dashboard profile
↓
Load saved widgets and filters
↓
Interpret the data manually

To:

Express intent
↓
System understands context
↓
System composes the relevant dashboard
↓
System explains the insight
↓
User drills into evidence or takes action

This is the shift from static memory to adaptive memory.

Old Memory: Saved Profiles and Static Views

Traditional applications often use profiles to remember how a user or group wants to see data.

For example, a dashboard profile may remember:

• which widgets are visible,
• which filters are applied,
• which columns are shown,
• how data is grouped,
• how charts are arranged,
• which date range is selected,
• which records are included.

This works well when the user repeatedly needs the same view.

But the weakness is that the profile is fixed.

A saved profile does not always understand:

• what the user is trying to do right now,
• what persona the user is acting as,
• what changed since the last time,
• what records are urgent,
• what insight matters,
• what action should happen next,
• whether the current context makes the profile less relevant.

The user still has to know which profile to open and how to interpret it.

In complex systems, saved profiles can become a second layer of complexity. The application has many screens, and then each screen has many saved views, profiles, filters, dashboards, and reports.

New Memory: Context-Sensitive Experiences

In an intelligence-first UX, the system should not rely primarily on users selecting from large lists of saved profiles.

Instead, memory should help the system shape the experience dynamically.

The user may say:

Show me what needs attention today.

The system should understand:

• who the user is,
• what role or persona they are acting in,
• what data they are allowed to see,
• what context they are currently working in,
• what they usually care about,
• what the organization considers important,
• what has changed recently,
• what actions are available.

Then it can compose a context-sensitive dashboard.

For one user, “what needs attention today” may mean deadline risk, blocked work, and approvals.

For another user, it may mean exceptions, missing evidence, and compliance gaps.

For another, it may mean assigned tasks, site issues, and work completed in the last 24 hours.

The dashboard is no longer only a saved profile.

It becomes a response to intent.

Profiles Become Memory Inputs, Not the Main Experience

This does not mean saved profiles disappear completely.

There may still be value in:

• standard organizational views,
• governed reporting layouts,
• compliance dashboards,
• team-level templates,
• executive summary views,
• reusable analysis patterns.

But these profiles should become inputs into the intelligence layer rather than the main navigation model.

A saved profile can tell the system:

“This is a useful way to look at this type of problem.”

But the user should not always need to manually find and select it.

The system can use profiles as historical knowledge, templates, or defaults.

For example:

The user is asking about blocked work.
A known team dashboard exists for blocked work analysis.
Use that profile as a starting point, but adapt it to the current user, date range, permissions, and active context.

So the old profile does not vanish.

It becomes a reusable memory artifact.

The important difference is that the system uses it intelligently instead of forcing the user to go hunting for it.

Static Memory vs Adaptive Memory

The shift can be summarized like this:

Static memory	Adaptive memory
Stores saved profiles.	Understands intent and context.
User selects from a list.	System suggests or composes the right view.
Views are mostly fixed.	Views adapt to persona, task, and situation.
Filters are saved manually.	Filters are inferred, suggested, and explainable.
Dashboards are preconfigured.	Dashboards are composed around the current question.
User must know which profile applies.	System helps identify the relevant perspective.
Profiles can multiply over time.	Memory reduces repeated navigation.
Configuration is remembered.	Behaviour and intent patterns are remembered.

Static memory remembers the interface.

Adaptive memory remembers how the user works.

That is the real difference.

Memory Can Shape Dashboards

In traditional systems, dashboards are often configured in advance.

A user selects a profile such as:

• Daily Operations View
• Weekly Performance View
• Exceptions View
• Manager View
• My Team View

This is helpful, but it still requires the user to know which view they need.

In an intelligence-first system, dashboards become context-sensitive.

The user asks:

What should I focus on this morning?

The system may compose a dashboard showing:

• Items requiring attention
• Blocked work
• Recent changes
• Deadline risk
• Approvals waiting for the user
• Recommended next steps

If the user often starts the day by reviewing blocked items, blocked items can appear more prominently.

If the user usually checks completed work from the last 24 hours, that perspective can be suggested.

If the user explicitly says:

Always show recently completed work when I review team performance.

That becomes memory.

The system is no longer just storing a dashboard layout.

It is learning which dashboard composition is useful for a specific intent.

Memory Can Shape Forms and Data Capture

Memory should not only affect what the system displays. It should also affect what the system asks the user to provide.

Traditional forms often expose many fields because the system does not know which fields matter.

An intelligence-first form should be more selective.

When creating a new record, the system should ask for the minimum meaningful information required for the task, then suggest additional fields based on context, history, and rules.

For example:

Required to create:
– asset or object
– issue description
– priority
– required date

Suggested based on context:
– notes
– supporting photo
– safety concern
– related record

The suggested fields may come from personal memory, organizational memory, or historical patterns.

If the user always adds notes, the notes field can become part of their default form.

If the organization requires safety information for certain work types, safety fields become required.

If similar records often include photos, the system can suggest attaching evidence.

The goal is to keep the experience relevant not only when retrieving information, but also when capturing and updating information.

Memory Can Reduce Profile Sprawl

One of the biggest usability problems with saved profiles is profile sprawl.

At first, saved profiles are helpful. Then every team, department, manager, report, and edge case gets its own profile. Over time, the list grows.

Eventually, users may see:

Daily View
Daily View – New
Daily View – Manager
Daily View – Manager Copy
Daily View 2025
Daily View Final
Daily View Final 2
Team View
Team View – Updated
Team View – Do Not Use

That is not intelligence. That is a filing cabinet having a nervous breakdown.

Adaptive memory helps reduce this problem.

Instead of creating a new profile for every slightly different perspective, the system can use:

• intent,
• persona,
• context,
• date range,
• selected records,
• organizational rules,
• user preferences,
• historical behaviour.

The user no longer needs 100 profiles. They need the ability to express what they want to understand.

The system can then compose the right view.

Memory Should Be Personal, Organizational, and Contextual

Not all memory is the same.

An intelligence-first system needs different levels of memory.

Personal memory

Personal memory captures how an individual user prefers to work.

Examples:

• Always include notes when I create this type of record.
• Show recently completed work when I review team activity.
• Prefer summary views before detailed grids.
• Use a compact layout for my dashboard.

Organizational memory

Organizational memory captures the way the organization expects work to happen.

Examples:

• For high-risk work, always require safety evidence.
• For approval reviews, always show policy exceptions.
• For financial decisions, always show budget impact.
• For compliance reviews, always show audit history.

Contextual memory

Contextual memory preserves the flow of the current task or conversation.

Examples:

• The user is currently reviewing blocked work.
• The active perspective is “completed in the last 24 hours.”
• The user filtered to their team.
• The user asked to inspect records with issues.
• The current evidence set contains these records.

Personal memory makes the experience familiar.
Organizational memory makes the experience consistent.
Contextual memory makes the experience coherent.

Memory Should Nudge, Not Surprise

Memory should make the system easier to use, but it should not make the interface feel random.

If memory changes the experience, the system should be able to explain why.

For example:

This dashboard emphasizes blocked items because you usually review blocked work first.

Or:

This field is shown because you asked to always include notes when creating this type of record.

Or:

This view is based on the standard team performance template, adjusted for your current role and date range.

This is important because adaptive interfaces can become frustrating if users do not understand why something changed.

The user should be able to inspect, adjust, reset, or override memory-driven behaviour.
Memory should reduce repeated effort.
It should not remove user control.

Memory Needs Governance

Adaptive memory must be governed.

A system should be able to distinguish between:

• personal preference,
• team convention,
• organizational policy,
• compliance requirement,
• temporary session context,
• historical pattern,
• system recommendation.

These should not all have the same authority.

A useful hierarchy is:

Legal and compliance requirements
↓
Organizational policy
↓
Team or role defaults
↓
Personal preferences
↓
Session context

For example, a user may prefer a simplified form, but the organization may require additional fields for a specific record type.

In that case, policy wins.

The system can still explain:

This field is required by organizational policy and cannot be hidden.

Or:

Your personal preference hides optional fields, but these fields are required for this context.

This keeps the interface adaptive without undermining governance.

Design Principle: Memory Should Replace Profile Hunting

The core principle is this:

Memory should move the experience away from manually selecting static profiles and toward context-sensitive views shaped by intent, persona, history, and governance.

Traditional profiles remember a view.

Adaptive memory understands why that view was useful.

That changes the experience from:

• Find the right profile.
• Open the profile.
• Check if it still applies.
• Adjust filters.
• Interpret the result.

To:

• State the intent.
• System composes the relevant view.
• System explains what it used.
• User drills into evidence or changes perspective.

This is a much better model for complex systems.

The user should not need to navigate through hundreds of saved profiles just to find the right view of the data.

The system should use memory to understand the task, suggest the relevant perspective, and adapt the interface without losing explainability or control.

The goal is not to remove customization.

The goal is to make customization intelligent.

Accessibility Becomes a Runtime Concern

Intelligence-first UX can improve accessibility, but only if it is designed properly.

There are real opportunities here.

Natural language can reduce navigation burden. Text-to-speech can make insights easier to consume. Speech-to-text can support users who cannot easily type. Voice interaction can help users in hands-free environments. Dynamic summaries can simplify complex information. Micro UIs can reduce clutter by showing only what matters.

MCP Apps examples include use cases around text-to-speech and speech-to-text, which shows how these interaction modes are starting to sit beside visual UI as part of richer app experiences. (Model Context Protocol)

But dynamic UI can also create accessibility problems if handled poorly.

If an interface changes based on AI output, the system must still support:

• keyboard navigation,
• screen readers,
• proper focus management,
• text alternatives for charts and images,
• status announcements,
• predictable interaction,
• clear labels,
• confirmation for destructive actions,
• accessible error handling.

WCAG 2.2 remains a critical foundation for accessibility. It covers recommendations for making web content more accessible to people with disabilities and includes principles and criteria around perceivable content, operable interfaces, understandable behavior, robust implementation, text alternatives, keyboard access, focus order, labels, predictable behavior, and input assistance. (W3C)

In intelligence-first UX, accessibility is not only a page design concern.

It becomes a runtime interaction concern.

If the system dynamically changes the interface, it must communicate:

• what changed,
• why it changed,
• what is now available,
• where focus moved,
• what the user can do next.

Voice also becomes more important. Google’s AI Search direction includes multimodal interaction, and the broader movement toward conversational AI experiences shows that users increasingly expect to interact through text, voice, files, images, and context rather than only through fixed screens. (The Verge)

For business applications, this has major implications. Voice is not just a convenience feature. It can become a serious interaction model for users who are mobile, hands-free, visually impaired, motor impaired, or working in environments where typing is not practical.

The principle is simple:

Every intelligence-first interface should have an accessible text path, visual path, keyboard path, and ideally a voice path.

The Risk: Insight Without Evidence

The biggest risk in intelligence-first UX is that systems may become too confident.

AI systems can summarize, recommend, and explain. But if those outputs are not grounded in evidence, users may trust conclusions they should question.

This risk is already visible in AI search. A 2026 study of Google AI Overviews found that AI-generated overviews can select sources differently from traditional search, and that 11% of decomposed claims in the tested responses were unsupported by the cited pages. (arXiv)

For enterprise and productivity software, the lesson is clear:

Insight-first must also be evidence-first.

Every insight should allow the user to inspect:

• source records,
• documents used,
• calculations,
• assumptions,
• confidence level,
• missing information,
• time range,
• permissions applied,
• business rules used,
• recommended action rationale.

The user should be able to ask:

“Why am I seeing this?”

And the system should have an answer.

The user should be able to ask:

“Show me the records behind this.”

And the system should provide them.

The user should be able to ask:

“What did you not consider?”

And the system should expose limitations.

Without evidence, intelligence-first UX becomes black-box UX. That is not progress. That is just mystery meat with nicer typography.

---

A Practical Pattern: Insight, Evidence, Action

A strong intelligence-first interface should be designed around three layers.

1. Insight

What matters?

Examples:

• “These items are at risk.”
• “This trend changed significantly.”
• “These records need review.”
• “This process is blocked.”
• “This decision has missing evidence.”

2. Evidence

Why does it matter?

Examples:

• source records,
• charts,
• documents,
• history,
• relationships,
• calculations,
• policy checks,
• anomalies.

3. Action

What can the user do?

Examples:

• approve,
• reject,
• escalate,
• assign,
• create task,
• request more information,
• open investigation,
• generate summary,
• start workflow.

The best pattern is:

• Insight first.
• Evidence always available.
• Action clearly explained.
• Human confirmation for important changes.

That is the practical heart of intelligence-first UX.

The New UX Assumptions

The shift can be summarized like this:

Traditional UX assumption	Intelligence-first UX assumption
The user starts with a screen.	The user starts with an intent.
The default view is a list of records.	The default view is an insight.
Search returns results.	Search returns synthesized information and next steps.
Menus define navigation.	Intent routing defines navigation.
Toolbars show possible actions.	Action surfaces recommend relevant actions.
Tabs hide complexity.	Context surfaces what matters now.
Dashboards are predesigned.	Dashboards can be composed around a question.
Grids are the main workspace.	Grids become evidence and drill-down layers.
Filters expose fields and operators.	Filters become intent-based perspectives.
Query builders require schema knowledge.	Natural language expresses the desired context.
Users understand the data model.	The system translates intent into the data model.
Users interpret data manually.	Systems assist with interpretation and explanation.
Accessibility is designed per page.	Accessibility must work across dynamic interactions.
Applications are destinations.	Applications become capabilities embedded into workflows and assistants.

A Reference Architecture for Intelligence-First UX

A generalized intelligence-first UX architecture may look like this:

User Interaction Layer
  - text input
  - voice input
  - visual selection
  - current screen context
  - uploaded files or images
  - user role and permissions

Intent Layer
  - intent classification
  - entity detection
  - task recognition
  - context resolution
  - ambiguity handling

Context and Knowledge Layer
  - operational data
  - documents
  - historical activity
  - business rules
  - semantic relationships
  - user permissions
  - policies
  - application ontology

Intelligence Layer
  - summarization
  - anomaly detection
  - risk detection
  - recommendation
  - ranking
  - explanation
  - confidence estimation
  - intent-to-query translation

UI Composition Layer
  - approved component registry
  - micro UI selection
  - layout composition
  - perspective filters
  - accessibility metadata
  - state management

Action Layer
  - workflow execution
  - tool calls
  - approvals
  - write actions
  - audit logging
  - policy enforcement

Evidence Layer
  - source records
  - citations
  - calculations
  - version history
  - decision trace

The important design principle is:

The interface may be dynamic, but it must remain governed.

That means dynamic UI should still be testable, explainable, accessible, auditable, and secure.

Design Principles for Intelligence-First UX

1. Start with intent, not navigation

The user should not always need to know where to go. They should be able to express what they want to achieve.

2. Show insight before raw data

Raw data should remain available, but it should not always be the first thing the user sees.

3. Keep evidence close to every insight

Every summary, recommendation, or risk signal should have a path to supporting evidence.

4. Compose from trusted components

Avoid unrestricted runtime UI generation in serious applications. Use approved, tested, accessible components.

5. Make recommendations explainable

Recommended actions should include reasons, assumptions, and possible impact.

6. Preserve user control

The system can suggest and prepare actions, but important changes should remain reviewable and confirmable.

7. Treat accessibility as part of the runtime

Dynamic UI must support screen readers, keyboard navigation, focus management, text alternatives, predictable interaction, and voice-friendly interaction.

8. Design for drill-down

Insight-first does not mean detail-hidden. Users must be able to inspect the underlying records.

9. Make uncertainty visible

The system should communicate confidence, missing data, stale data, and ambiguous assumptions.

10. Audit the journey

When systems recommend or perform actions, the decision path should be traceable.

11. Hide unnecessary ontology complexity

Users should not need to understand entities, relationships, field names, joins, statuses, or internal data structures just to answer normal business questions.

12. Use persona-aware intelligent filters

The system should expose the most relevant quick filters and perspectives based on the user’s role, task, and current context.

13. Let natural language refine the view

Advanced query builders should remain available, but natural language should become the everyday way to express more detailed intent.

Relevant Documentation and References

The following public references are useful for understanding the direction of travel:

• OpenAI’s Apps SDK documentation explains how developers can build apps with both logic and UI that run inside ChatGPT, using MCP as the underlying standard. (OpenAI Help Center)
• OpenAI’s developer mode and MCP apps documentation describes internal MCP-powered apps, interactive UI, write or modify actions, testing, publishing, and admin controls. (OpenAI Help Center)
• The official MCP Apps documentation describes interactive HTML applications that render inside MCP hosts, including dashboards, forms, data visualizations, rich media, real-time monitoring, and multi-step workflows. (Model Context Protocol)
• Claude Artifacts documentation describes dedicated spaces for substantial, self-contained content such as tools, apps, visualizations, and documents. (Claude Help Center)
• Recent Google Search reporting describes the move toward conversational AI search, multimodal input, dynamic/generative UI patterns, and agentic search experiences. (The Verge)
• WCAG 2.2 remains an important baseline for designing accessible dynamic interfaces. (W3C)

Conclusion

The next phase of user experience is not about removing traditional UI. Screens, menus, forms, grids, dashboards, tabs, filters, query builders, and toolbars will still exist.

But their role changes.

Screens become context containers.

Menus become less important than intent routing.

Toolbars become recommended action surfaces.

Grids become evidence layers.

Filters become intent-based perspectives.

Query builders become advanced inspection and governance tools.

Dashboards become question-driven.

Search becomes an intent interface.

Accessibility becomes a runtime requirement.

And the default view shifts from raw data to meaningful information.

The core idea is this:

Intelligence-first UX changes the user experience from “navigate the system to find the data” to “state the intent and let the system bring forward the insight, evidence, and action.”

That is the real post-2026 UX shift.

Not chat replacing UI.
Not AI generating random screens.
Not dashboards disappearing.

The real shift is that applications become better at understanding what the user is trying to do, translating that intent into the underlying ontology, extracting what matters from the data, nudging the user toward relevant next steps, and presenting the right interface at the right moment.

The future of UX is not less UI.

It is more intelligent UI.