How should generative UI be organized as a design space?

This CHI 2026 workshop proposal, co-organized by researchers at Microsoft Research, UCSD, MBZUAI, Apple, and MIT, argues that AI's growing capacity to generate UI "directly to users" at run-time unsettles the foundations of HCI practice, which has built itself on "developing tools and methods to support the crafting of interfaces by people" through stable, predictable, iteratively tested software. It organizes the generative UI ("genUI") design space along four dimensions: (1) whether the generated UI is for a designer/developer — feeding a human-led design process that refines it before shipping — or produced "in the general course of human-AI interaction," directly for end-users at run-time; (2) whether the UI is static (wireframes and visuals made during design), "interactive" (generated once and then fixed, as in dynamic prompt middleware), or "dynamic" (changes during the interaction itself); (3) if it changes, whether that change is user-driven ("malleable software"), system-driven ("adaptive UI"), or both; and (4) the interaction timeframe — "ephemeral," used once and abandoned, versus supporting a "longer-lasting activity."

The dimensions are drawn from a review of prior "dynamic UI" research — adaptive systems like SUPPLE, PUC, UNIFORM, and HUDDLE, and malleable-software tools like Bespoke, NL2INTERFACE, LIDA, and DynaVis — and the lesson the authors carry forward is that dynamic UI "can reduce cognitive load and cater for diverse needs," but "can also introduce complexity, reduce predictability, require the collection of potentially sensitive data, and create challenges for users' awareness of, and control over, possibilities for interaction," and its development "can be methodologically complex." The proposal's reasoning is that these same tensions apply, likely amplified, once an AI model rather than a rule-based system is doing the generating and adapting, and it calls for HCI's ideation, testing, and iteration workflows to shift from targeting a stable shipped design toward targeting "what an AI model will generate at run-time" — evaluation becoming "model-centric" rather than artifact-centric.

The two nearest notes document what happens once a genUI system already exists: Do generated analysis UIs really work better than chat? finds that generative widgets in LLM-assisted analysis trade clarity for rigidity and prompting effort, and How should users control systems with unpredictable outputs? documents the intent-specification and trust problems unpredictable outputs create for users. This workshop proposal sits one level up the stack: it treats the same underlying tensions — malleable versus adaptive control, static versus dynamic UI — as dimensions for organizing HCI's design and evaluation process, not as findings about a deployed tool. Its user-driven/system-driven axis maps directly onto the malleable-software/adaptive-UI split that TaskArtisan's malleability axis operationalizes for analysis widgets, and its designer-facing/end-user-facing axis separates TaskArtisan's own use case — a probe built for analysts — from the end-user-facing genUI that Nielsen's intent-based design principles address. It also connects to How does AI context differ from conventional software context?, since its ephemeral/longer-lasting timeframe dimension is the interaction-design counterpart to that note's claim about context mutability.

As a workshop proposal rather than a study, the excerpt reports no data, no completed framework, and no resolved answers to the questions it poses — it calls its own four dimensions a starting point meant only "to ground discussions." It does not specify what "model-centric" evaluation metrics would look like, nor how practitioners could test a design they cannot fully pre-specify. What follows at that strength is narrow: one influential cross-industry group judges genUI a significant enough rupture in HCI method to convene a dedicated workshop around it, not that the field has yet produced replacement methods.