Discussion: From a UX perspective, what problems does A2UI uniquely solve?

[selmanays]

I’m a UX designer with nearly 15 years of experience designing digital products across consumer and enterprise software.

I have read the A2UI specification, explored the examples, and followed many of the discussions in this repository.

First, I want to say that I think the protocol itself is thoughtfully designed. I understand the architectural motivations behind it: secure UI generation, platform independence, structured UI representation instead of arbitrary HTML/code generation, streaming updates, interoperability, and security boundaries between agents and applications.

However, after going through the documentation, I still find myself trying to clearly understand one fundamental question:

What category of problems does A2UI solve significantly better than existing UI architectures?

This may simply be a gap in my understanding. Given my background in UX design, I expected the product value proposition to become clearer as I explored the specification. Instead, I repeatedly found myself returning to the same question:

What is the concrete user or product problem that A2UI uniquely addresses?

I would genuinely appreciate clarification from the community and maintainers.

⸻

Where I’m struggling

Many examples in the documentation demonstrate scenarios such as:

• displaying a date picker
• presenting charts
• generating forms
• rendering maps
• asking users for confirmation
• showing structured information instead of plain text

These are all valuable interaction patterns, but they are also interactions that modern applications already support.

Today, AI assistants can already instruct applications to use existing UI capabilities through:

• design systems
• component libraries
• APIs
• application-specific tools
• native UI frameworks

Frameworks such as React, Flutter, SwiftUI, and Jetpack Compose already allow applications to compose sophisticated interfaces from reusable components.

So my question is:

What fundamentally new capability does A2UI introduce beyond providing another declarative way of describing UI?

Is the primary value the ability for agents to communicate UI intent across application boundaries without requiring every possible interaction to be predefined by the application?

If so, I would love to better understand where this abstraction becomes significantly more valuable than existing approaches.

⸻

Is the primary value proposition runtime UI composition?

From reading the specification, my understanding is that one of A2UI’s main goals is enabling agents to compose interfaces dynamically based on the user’s current task.

If this is the intended direction, I have some UX questions.

Interfaces are not only containers for information.

They also create:

• familiarity
• spatial memory
• muscle memory
• predictability
• confidence

Many usability principles established over decades rely on consistency and recognition rather than constant adaptation.

A highly dynamic interface could potentially create trade-offs.

For example:

If the route from my home to work changed every morning because an AI selected a theoretically optimal route, it might not necessarily create a better experience. Over time, I may actually feel less confident because I lose familiarity and predictability.

The same question applies to software interfaces:

At what point does personalization and adaptation become more valuable than consistency?

How does A2UI balance these two competing UX principles?

⸻

Discovery vs asking

Another area I’m curious about is discoverability.

Great interfaces do not only help users complete tasks they already know they want to perform.

They also expose possibilities users were not previously aware of.

Examples:

• recommendations in commerce applications
• productivity features users discover through navigation
• contextual insights in dashboards
• unexpected but valuable workflows

If interactions increasingly begin with users asking an agent for something, could we unintentionally lose some of the discovery benefits that traditional interfaces provide?

How does A2UI think about this relationship between conversational intent and interface-driven discovery?

⸻

Enterprise software considerations

I can clearly imagine potential value for exploratory workflows.

Examples such as:

• research assistants
• data exploration
• analytical workflows
• open-ended knowledge tasks

make intuitive sense to me.

However, I am less certain about repetitive enterprise environments.

Consider:

• ERP systems
• banking software
• accounting platforms
• manufacturing dashboards
• logistics operations
• procurement systems
• healthcare systems

Many of these applications are intentionally repetitive.

Users may perform the same workflows thousands of times.

In these environments, consistency is not a limitation.

It is often the foundation of efficiency.

A trained operator may know exactly where a button is, how a workflow behaves, and what outcome to expect.

So I’m curious:

Would dynamically composed interfaces reduce cognitive load in these environments, or could they unintentionally increase it by introducing variability?

Are there specific enterprise scenarios where A2UI has demonstrated a clear advantage over established application architectures?

⸻

UX quality and ownership

Another question I have is around UX governance.

Traditional applications usually have clear ownership of interface quality:

Designers define:

• interaction patterns
• hierarchy
• information architecture
• accessibility considerations
• user flows

Developers implement these systems consistently.

With agent-generated interfaces, how do we ensure that UX quality remains consistent?

For example:

A payment flow is not only a collection of components.

The order of information, error handling, confirmation states, and user confidence are all design decisions.

How does A2UI approach the question of who owns and guarantees UX quality when interfaces are composed dynamically?

⸻

Learning cost vs measurable benefit

Another question I keep returning to is the trade-off between abstraction and value.

Adopting A2UI introduces:

• a new protocol
• new tooling
• new infrastructure considerations
• new mental models
• additional implementation complexity

What measurable benefits justify this additional abstraction compared to extending existing component-based architectures with AI capabilities?

At what scale or scenario does A2UI become clearly advantageous?

⸻

The question I’m ultimately trying to answer

I may be misunderstanding the intended scope of A2UI.

My goal is not to question the technical design of the protocol, but to better understand the product problem it is solving.

So I would genuinely like to ask the maintainers and community:

What is the concrete problem that existing UI architectures cannot solve efficiently, and where does A2UI create meaningful value that justifies introducing a new UI communication protocol?

Not only from an implementation perspective, but from a product and user experience perspective.

In which real-world scenarios does A2UI fundamentally improve the experience for users, designers, or developers compared to existing approaches?

I feel like I may be missing an important part of the vision, and I would genuinely appreciate learning more from the community.

(If I’m approaching A2UI with the wrong mental model, I’d genuinely appreciate being corrected. I’m asking because I’d like to understand where A2UI creates value beyond what I’m familiar with as a UX designer.)

[MrTONYCHAN]

I think the differentiator is not that A2UI can render a form, chart or date picker—existing UI frameworks already do that better. The useful boundary is that an agent outside the host application can propose a structured interaction at runtime without sending executable UI code and without knowing whether the host is React, Flutter, SwiftUI, etc.

That matters when three conditions are true:

• the agent and host app are independently developed/deployed;
• the exact task UI cannot be enumerated ahead of time; and
• the host must retain control over security, accessibility, design-system components and allowed actions.

A2UI becomes a capability-negotiated protocol: the agent expresses intent and data; the host maps only supported components/actions to trusted native UI. Streaming patches also let the interaction evolve while the task runs. A normal component library solves composition inside one application; A2UI targets composition across an agent/application boundary.

It is probably unnecessary for a product with a small, known set of workflows—normal tools plus predefined screens are simpler and more consistent. Its strongest UX case is the long tail of task-specific interfaces where plain chat is too weak but arbitrary generated HTML/code would be unsafe and visually inconsistent.

[selmanays]

Thanks, this definitely helps me better understand the architectural motivation.

If I understand correctly, the core value of A2UI is not richer UI components themselves, but providing a standardized protocol that allows independently developed agents and applications to negotiate structured UI interactions at runtime while the host application retains control over security, accessibility, native components, and design-system constraints.

That makes sense to me from a systems architecture perspective.

Where I’m still trying to connect the dots is the next step in the chain:

How does this architectural capability translate into a meaningfully better experience for end users?

The reason I’m asking is that the project documentation doesn’t seem to position A2UI as only an interoperability protocol or implementation detail.

For example, the documentation frequently emphasizes ideas such as:

• moving beyond text-only interactions,
• enabling rich, interactive user interfaces,
• and providing more natural, task-oriented interactions.

Those statements suggest that A2UI is ultimately expected to improve the user experience, not just the developer experience.

I completely agree that plain chat is often an inefficient interface.

What I’m trying to understand is where A2UI itself becomes the reason for that improved experience, rather than generative UI in general.

For example, compared to an application that already combines today’s tool-calling approaches with a well-designed component system, what becomes noticeably better for the end user?

• Can users accomplish tasks they realistically couldn’t before?
• Do tasks become significantly faster?
• Does cognitive load decrease?
• Is discoverability improved?

Or is the primary benefit actually architectural, with UX improvements emerging only as an indirect consequence?

You mentioned the “long tail” of task-specific interfaces, which sounds like a compelling use case.

Could you share one or two concrete real-world examples where:

• existing tool-calling together with predefined UI becomes impractical,
• A2UI enables a substantially better solution,
• and the improvement is clearly experienced by end users rather than primarily by developers?

I think that’s the final piece I’m currently missing—the connection between the architectural capability and the actual product value delivered to users.

Thanks again for taking the time to explain it. I’m genuinely trying to understand where A2UI creates unique value, because I feel like I’m still missing an important part of the vision.

[MrTONYCHAN]

I agree that the UX improvement is not automatic. A2UI is primarily an architectural enabler; the end-user benefit appears only when that architecture removes friction that predefined flows cannot handle economically.

Two concrete examples:

1. Insurance or field-service intake: An agent receives an unusual claim or repair request and progressively composes only the evidence controls relevant to that case—camera capture, annotated image, map location, parts selector, signature and confirmation. A predefined application can build every flow, but the combinations grow quickly. A2UI lets the agent request a task-specific interface while the host still renders trusted native controls. The user experiences fewer irrelevant questions, less backtracking and fewer hand-offs to another screen or employee.

2. Enterprise incident response: An agent coordinating several independently developed systems can present a live incident-specific workspace: affected-service table, log excerpts, remediation choices, approval controls and rollback confirmation. The required interface changes with the incident and available tools. The user gets progressive disclosure and can inspect and approve actions without switching among dashboards or interpreting a long chat transcript.

A single application that controls its agents, tools and component library can reproduce both experiences without A2UI. The protocol becomes valuable when agents and host applications are independently developed and need a shared, safe interaction contract. So the unique value is less “a completely new UX pattern” and more making high-quality generative UI interoperable, trustworthy and reusable across application boundaries.

[selmanays]

Thanks, these examples are much more compelling than the simpler ones in the documentation, especially because they illustrate the combinatorial complexity that predefined workflows eventually run into.

I can definitely see why an architectural abstraction like A2UI becomes much more valuable in those scenarios.

Your examples also made me think about a different question.

If interfaces are increasingly composed dynamically at runtime, how should product teams evaluate and improve those experiences over time?

In traditional UX, we optimize relatively stable interfaces using metrics such as task completion rate, conversion rate, error rate, usability testing, and A/B experiments. Those methods assume that users are interacting with largely consistent interfaces.

But if different users receive different interfaces for the same underlying task, what becomes the unit of optimization?

Are we evaluating:

• the generated interface,
• the agent’s decisions,
• the underlying model,
• or the protocol itself?

Similarly, how should teams reason about conversion rates, funnel analysis, or long-term UX improvements if the interface itself is no longer consistent?

I’m asking because I’m genuinely interested in the UX implications of a protocol like this. I’m trying to understand not only the architectural problems A2UI solves, but also the new UX challenges it introduces, and where UX thinking can meaningfully contribute to its evolution.

Thanks again for taking the time to explain your perspective. It has already helped me better understand where A2UI begins to provide value.

[MrTONYCHAN]

That is exactly where UX work becomes more important, not less. The interface instance is variable, but the user’s underlying task and the system’s design constraints can remain stable.

I would evaluate the experience at four levels:

1. Task outcome: Did the user complete the claim, repair, approval or investigation? Measure completion rate, time, abandonment, corrections and escalation—independent of which interface was generated.

2. Agent decision: Did the agent choose the right interaction pattern, request the necessary information and avoid unnecessary steps? This evaluates the policy or model responsible for composing the experience.

3. Generated UI plan: Was the resulting component tree understandable, accessible and appropriate for the task? Teams can evaluate hierarchy, component count, validation, readability, cognitive load and conformance to UX rules.

4. Host renderer and protocol: Did the host faithfully render the plan, preserve state, enforce permissions and expose usable telemetry? These are properties of the implementation and protocol rather than the agent.

The important instrumentation is therefore not only page views. Each session should record a stable task identifier, the agent’s UI specification or a privacy-safe hash of it, components/actions used, validation failures, revisions, completion outcome and user feedback. That lets teams compare interface strategies even when the exact layouts differ.

A/B testing can still work by testing policies or constraints rather than individual screens—for example, progressive disclosure versus one large form, confirmation placement, maximum choices per step or when the system falls back to a predefined flow. Stable “golden tasks” can also be replayed against new agent or protocol versions to detect regressions before release.

UX designers can contribute directly by defining the component vocabulary, composition rules, accessibility invariants, evaluation rubrics, failure taxonomy and boundaries where dynamic generation should not be used. The optimization unit shifts from a fixed screen to a task plus generation policy, while the design system provides the consistent UX contract.