# What is generative UI? > Generative UI is an interface assembled for each request rather than shipped as one fixed layout. The app decides what to render from data about the visit, so two people can see different screens from the same code. _Last updated 2026-10-24. From The Generative UI Guide, https://generativeui.guide_ A traditional page ships the same markup to everyone and changes it with client-side scripts after it loads. Generative UI moves that decision earlier. The application assembles the layout for each request from data it already has, then sends the result. The interface is an output, not a fixed asset. The term covers ordinary screens, not just chat. A product page, a news front page, a dashboard, or an onboarding flow can each be composed per visit from the same code and the same components. ## What decides the layout Two inputs drive a generated interface. A set of rules or a model says what this visitor should see, and state says what is true about them right now: what they have looked at, what is in the basket, where they are in a flow. The richer and fresher that state, the more the generated interface can respond to. ## Three ways to generate an interface 1. **Rules over a set of components.** Code picks which components to show, and in what order, based on the visitor's state. It is predictable and easy to test. Every new case is a new rule someone has to write. 2. **A model choosing from a catalog.** A model reads the state and returns a specification that names components you built and the props to give them. The model can handle cases nobody wrote a rule for, and the screen still contains only components you shipped. This is the common pattern for customer-facing generative UI. 3. **A model writing the markup.** The model produces the interface itself. It is the most flexible and the hardest to keep on brand, accessible, and safe, so it is rare on pages real customers see. Most teams start with rules and move parts of the decision to a model as the cases multiply. The last two approaches have names that recur across the tools. Composing from a catalog you define is the schema-driven approach: the model returns data, and the client draws the screen from components it already ships. Letting the model produce the markup is the code-generation approach. Schema-driven generation is becoming the default for interfaces real customers see, because the result stays on brand, accessible, and safe by construction. Code generation is kept for one-off cases where no catalog would fit. That dividing line runs through most of the field, and [how to build generative UI](/building) returns to it. ## How much should it change? A generated interface sits between two failures. Vary too little and every visit looks the same, so the generation is for show. Vary too much and the interface is unrecognizable from one visit to the next, and people cannot learn where anything is. The useful setting is a budget: keep the structure stable and vary the detail. A product page holds its shape and reorders the modules inside it. An onboarding flow keeps its steps and changes their order and emphasis. Most of the skill is deciding how much latitude the rules or the model get, and most of the value is in keeping that latitude small on purpose. This is an old idea. Artists working with rule-based systems named it decades before software, and [the history of generative UI](/history) traces the line. The practical point holds now: a layout that changes wholesale every visit is usually worse than one that changes a little, for the same reason a shop that moves its shelves every night is harder to use. ## How it works, end to end A generated interface has three jobs, whichever approach drives it: - **State.** A current picture of the visit, read on the request. - **Decision.** A rule or a model that turns that state into a choice of what to render. - **Render.** Something that draws the chosen components into a screen. The state and the decision both sit on the path to the first paint, so reading them has to be fast enough that the visitor does not wait for a layout. [How to build generative UI](/building) walks through each of these parts. ## Examples The same pattern shows up on different pages. ### A news front page A first-time visitor sees the top stories and a newsletter signup. A reader who has opened three basketball stories this visit sees a sports module moved up, with the stories they have already read left out. Both pages come from the same template and the same components. ### A product page A shopper who has compared prices across several similar products sees a price comparison and delivery dates near the top. A shopper who arrived from a review and went straight to the size guide sees fit details and reviews first. The product is the same, and so is the code. ### An onboarding flow A new user who skips a setup step twice sees a shorter path with that step moved to the end. A user who completes every step quickly gets the advanced options straight away. The flow is assembled from the same steps for each of them. ## Why real-time state matters The appeal of generative UI is that the interface responds to the person. That only holds if the data it reads describes the person now. Fed a segment computed last night, the same machinery produces a layout for who the visitor was, not who they are on this visit. Real-time state is the running picture of a visit: pages seen in the last few minutes, the last action and how long ago, items viewed, a search that returned nothing, a basket left idle. It updates as the visitor acts, and it is available to read on the next request. This is where most of the engineering effort goes, and where tools differ. Some products specialize in it. [Snowplow Signals](https://signals.snowplow.io/learning/generative-ui), for example, computes a running picture of each visit from behavioral events and serves it to your application in a few milliseconds, leaving the decision of what to render in your own code. The point is general: without current state, a generated interface is guessing. ## Adaptive experiences, the outcome An adaptive experience is what generative UI exists to deliver: a product that changes in response to what a person is doing, as they do it, within the same visit rather than the next one. If someone searches, filters, then hesitates on a product, the experience can respond before they leave. Adapting in the moment needs the two halves above. Generative UI is the acting half. Live state is the knowing half. An adaptive experience does not replace a recommender or a campaign tool; it keeps those tools working from what is true now, so the ranking or the message reflects the visit rather than the profile. ## What it gives up Generating the interface per visit has real costs, and a plain account should name them. People remember where things are, and interfaces that keep things in place are faster to use; an interface that differs every time cannot be learned by location. A generated interface is also harder to hold to account. If each visitor sees something composed for them, the question of what any one person saw has no answer unless the system recorded it. And a catalog, once a model composes only from it, quietly bounds what the interface can ever be. None of this is fatal. Each is a reason to vary with restraint, to keep a record of what was shown, and to treat the catalog as something you maintain rather than set once. [Measuring generative UI](/analytics) picks up the record-keeping problem. ## Why it matters When the interface is generated, the same code can serve a first-time visitor and a returning one differently, without a separate template for each case. The limit is no longer how many layouts a team can maintain by hand. It is how good the data and the rules behind the generation are.