--- title: "What is generative UI? | Snowplow Signals" description: "Generative UI assembles the interface for each visit at request time from data and rules, instead of shipping one fixed layout to everyone." source: https://signals.snowplow.io/learning/generative-ui/what-is-generative-ui --- [Learning](https://signals.snowplow.io/learning) / [Generative UI](https://signals.snowplow.io/learning/generative-ui) # 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. ## The idea 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 app assembles the layout for each request from data it already has, then sends the result. The interface is an output, not a fixed asset. ## What decides the layout Two inputs drive it. Rules or a model say 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, and 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 spec that names components you built and the props to give them. Libraries such as [json-render](https://signals.snowplow.io/learning/generative-ui/json-render-explained) draw the spec. The model can handle cases nobody wrote a rule for, and the screen still only contains components you shipped. 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 customer-facing pages. Most teams start with rules and move parts of the decision to a model as the cases multiply. ## Examples These are illustrations of the same pattern on different pages. ### Example: 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 read left out. Both pages come from the same template and the same components. ### Example: 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. ### Example: 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. ## What it needs to work The decision is only as good as the state it reads. If that state is a segment computed yesterday, the interface responds to who the visitor was, not what they are doing in this visit. [Why generative UI needs real-time state](https://signals.snowplow.io/learning/generative-ui/why-generative-ui-needs-real-time-state)covers this in detail. It also has to fit the render budget. 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. ## 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. ## How it compares Generative UI overlaps with server-driven UI and with A/B testing, and differs from both in what decides the layout and how often. See [generative UI vs server-driven UI](https://signals.snowplow.io/learning/generative-ui/generative-ui-vs-server-driven-ui) and [generative UI vs static A/B testing](https://signals.snowplow.io/learning/generative-ui/generative-ui-vs-static-ab-testing). ## Where Signals fits Signals supplies the state: what each visitor is doing right now, computed from their behavior and served to your app in milliseconds. Deciding what to render stays in your stack, in your own rules or a model you choose. ## Put it to work * [Generative UI on Signals →](https://signals.snowplow.io/lp/generative-ui) * [Build an adaptive experience →](https://signals.snowplow.io/lp/adaptive-experiences) ## See it on your own traffic Add the SDK, define one attribute, and see an attribute updating against your own traffic in the first session. The free tier runs on the real engine: no card, no sales call. [Start free](https://signals.snowplow.io/start) [Talk to an engineer](https://signals.snowplow.io/start?intent=engineer) More explainers in the [Learning Center →](https://signals.snowplow.io/learning)