Designing AI experiences

AI changes what a product can do. It doesn’t change who the work is for, or what makes an interface worth trusting. Two questions decide most of it: whether AI belongs in this workflow at all, and how much of the screen a model is allowed to assemble.

The principles

Four, in priority order. The first one gates the other three.

1. AI is not the first fix for a broken workflow. Establish this before anything else here applies. Where a workflow is confusing, slow, or poorly structured, fixing it will do more for users than anything layered on top, so adding AI first spends the effort in the wrong place and leaves the original problem intact. Answer this question first, and be willing to answer it with no.

2. A mental model for AI is still forming. Don’t assume a stakeholder already shares it. Show a concept inside the person’s real tasks, data, and vocabulary, not a generic capability demo. However advanced the underlying technology, it earns nothing without adoption: workflow fit, not raw capability, is what earns trust and what everyone can judge.

3. Trust should match reliability. Users should lean on AI exactly as far as it has earned, no further and no less. Under-trust wastes the feature, and over-trust causes incidents. People here are cautious because a mistake can cost a crew’s day or damage equipment, not merely because the tool is unfamiliar. Weigh every pattern on whether it moves reliance closer to reliability, not on whether it raises confidence.

4. Design for compliance and accessibility from the start. Both belong in the first version of a feature, alongside the core interaction. A pattern that only meets them by beta has skipped a step rather than deferred a nice-to-have. This extends to obligations that formally sit with the customer: capabilities they need to meet their own duties are ours to build, not theirs to work around.

How a screen gets built

A designer normally decides the layout in advance, and everyone gets the same one. A model can change that. It can choose the interface itself, not only the content inside it, deciding as the page loads for the person in front of it. That is generative UI.

“An AI screen” gets used for four quite different things, though, and only two of them involve a model at all. They differ in what they cost to build, what it takes to test them, and what compliance asks of them, which is what makes the vocabulary worth having.

Two terms the modes below rely on. A component registry is a machine-readable list of the components a model may pick from, with rules for each one: what it’s for, what data it needs, what it can’t sit beside, and who may see it. The AI label, confidence indicator and override control are the elements that tell someone AI was involved, how sure it is, and how to take over. They sit outside that list, so a model can’t reorder or drop them.

Four ways to assemble the same panel, then. Only two of them involve a model.

Fixed. Not generative. The screen doesn’t change.

Rule-based. Not generative. The screen changes by written rule, so the same input always produces the same screen.

Declarative. Generative, constrained. The model selects and orders from an approved component registry. It doesn’t invent structure.

Open generative. Generative, unconstrained. The model invents its own page structure rather than selecting from an approved registry.

Generative UI is the umbrella for the last two: the modes where a model does the assembling.

Declarative needs three things to already exist: a component library, a registry describing it, and an evaluation method. Without all three, what’s being built is a fixed or rule-based interface whatever it gets called.

Open generative has the harder validation problem. The set of possible arrangements isn’t fully enumerable, so a placement test can’t cover every render the way it can for a fixed layout set. The compliance bar doesn’t move either way: the AI label, the confidence indicator, and the override control have to hold position on every render. Ask for the validation approach when someone proposes open generative.

One term to avoid: adaptive UI. The industry uses it for any interface that changes, generative or not, so it doesn’t tell you whether a model is involved, and that is the distinction that changes the design work, the compliance work, and the cost.

How a screen is assembled is a separate decision from how far the AI acts on its own. A fixed, hand-built screen can carry an agent that acts autonomously; a declaratively assembled screen can offer no actions at all. Expect the two to be treated as one decision in conversation until the distinction is written down.

When fixed or rule-based is enough

Rule one of generative UI is confirming that neither fixed nor rule-based already solves the problem. Both are cheaper to build, cheaper to test, and fully predictable.

Fixed is the right answer when the task is the same for every user and the value is in everyone learning one layout. That covers most operational screens.

Rule-based is the right answer when the conditions that should change the screen are known, few, and stable enough to write down.

Rule-based covers more cases than people expect. If you can state the condition in a sentence, it’s a rule, and a rule is testable, auditable, and explainable to a customer in a way a model’s selection is not.

Reach for generative UI when the conditions are too many or too variable to enumerate, and when the design-system work it demands is justified by what that buys.

Terminology

One vocabulary across product, design, and content, so users and internal teams build the same mental model of what the software is doing. These follow Helix’s AI foundations and are industry-standard.

AI. The umbrella term shown to users. Prefer it over model names, assistant branding, or vendor terms. Every customer configures things differently, and this keeps the language stable and vendor-independent.

Generate. AI produces new content: text, a summary, a draft, an image. Distinguishes “created new” from “proposed a choice”, so the user knows how much of it is genuinely new.

Suggest. AI proposes an option the user can accept, edit, or ignore. Signals lower stakes, and no commitment yet.

Draft. AI-produced content the user is expected to review before it counts as theirs. Sets an accurate expectation of required review, which is what keeps overreliance down.

Source. The data, record, or document an output is grounded in. The unit that makes attribution and an audit trail possible.

Skill, or action. A discrete task AI can perform. Naming the unit of agentic capability is what lets permissions and disclosure be scoped to it, rather than to “AI” as a whole.

Confidence. How sure AI is. Show it only where it would change what the user does next, so it informs a judgement rather than decorating every output.

Human-in-the-loop. The system can’t act without a human approving that specific step first. A required gate, not a monitor.

Human-on-the-loop. The system acts on its own; a human monitors and can intervene or override. Supervisory rather than gating.

Generative UI. A model assembles the interface as the page loads for a specific user, rather than the interface being decided in advance. Covers Declarative and Open generative. Fixed and Rule-based involve no model and are not generative.

Human-in-the-loop and human-on-the-loop are established in industry use, but they are not the EU AI Act’s own vocabulary. Use them between ourselves, and never quote them to Legal as the regulation’s wording.