Generative UI with LLMs: making web pages adapt to each user

Madjar Evan — Tue, 21 Apr 2026 14:03:05 +0000

Most web apps show the same layout to every user. Large language models (LLMs) change this: they let you generate adaptive, per-user interfaces that restructure themselves based on what each person cares about.

TL;DR

Web pages look the same for every user, but LLMs can adapt them per user or per cohort.
The LLM generates a template once — not on every page render. Cost stays bounded.
I built a working Django + OpenAI prototype where a recipe page rearranges itself from a free-form user prompt. Screenshots and stack details in Section 9.

1. Why adapt web pages per user?

Adaptive interfaces have two connected motivations — one for the user, another for the site owner.

For the user — convenience. On a product, job, or apartment page, about 80% of the information is usually irrelevant to a specific person. Someone looks at price and location; someone else cares about furniture; someone else about the tech stack and salary. Today the user scrolls, visually filters, and wastes time on things they don't need. An adaptive interface removes that work: the page arrives already sorted and trimmed to fit their interest.

And more than convenience — new information. Adaptive interfaces can do more than remove clutter; they can add things that weren't on the original page: turning a news article into a knowledge graph with connections between people and events, enriching dense technical text with inline explanations for beginners, or assembling a summary from multiple sources. This is no longer repackaging — it's enrichment, and it's only possible thanks to LLMs.

For the site owner — traffic and engagement. When the page shows what matters to the user right away, they:

stay on the site longer;
reach the target action faster (submit a request, call, buy);
leave for a competitor less often;
are more likely to come back.

It's the classic chain: convenience → engagement → business metrics. Adaptive interfaces don't invent new value — they remove the familiar friction between the user and the information.

Example. On a real estate site, a user is looking for an apartment with a specific furniture setup. On the standard page, the furniture block is buried at the bottom — below the description of the building, its year of construction, and the developer's history. To get to what matters, the person scrolls, skims, and often closes the tab before getting there. On the adapted page, the furniture block sits at the top, everything else is collapsed or removed. Within a few seconds the user can tell whether the apartment fits, and is more likely to reach the "submit request" button. Same action — but the friction is gone.

2. What can an LLM change on a page? Four levels

Page adaptation can happen at four levels — from the most surface-level (just text) to the deepest (the whole markup). The deeper the level, the more freedom the system has to rethink the page, but also the more context is needed about the user and the higher the risk of getting it wrong.

Level	Name	What exactly changes
I	Content	Text inside `<p>...</p>` — wording, headings, paragraphs
II	Font	CSS font styles: weight, family, size, spacing
III	Block styles	Position and shape of `<div>`, `<p>`, and other containers
IV	Page design	The entire HTML markup — a fully regenerated page

3. Individual vs cohort adaptation: how it works

Adaptation can work at two scales:

Individually — the page adjusts to one specific user.
By cohort — the page adjusts to a group of people sharing a common trait (age, role, interests, language, perceptual needs, etc.).

Either way, the system needs data — what exactly to adapt and for whom. That data can be collected in two ways:

From the user themselves.
- Directly — the user configures the page through a settings interface.
- Indirectly — the user answers questions about preferences, and the system derives settings from the answers.
The system infers it — like a recommendation system, based on behavior, history, device, context.

For cohorts the logic is the same: the user either selects their group (if a ready-made adapted design matches it), or the system tries to detect the cohort automatically.

4. Example: adapting a job listing page

Before digging into the mechanics, let's look at the idea through a simple example.

A standard job listing page is overloaded: a long company pitch, mixed responsibilities and requirements, the tech stack buried in a paragraph, salary at the very bottom. Every company has its own format, and the user keeps hunting for the same pieces of information again and again.

An adaptive interface can collapse this into a compact view that the user has configured once: at the top — the job title, stack, location, and 3–4 key requirements. Everything else is hidden behind "show more".

Standard view:

┌──────────────────────────────────────────┐
│ Middle PHP Developer                     │
│                                          │
│ About TechCorp: we are a leading,        │
│ fast-growing, dynamic team ...           │
│                                          │
│ Responsibilities:                        │
│   • Develop and maintain services        │
│   • Take part in code reviews            │
│   • ...                                  │
│                                          │
│ Requirements:                            │
│   • 3+ years of experience               │
│   • PHP 8, Laravel                       │
│   • ...                                  │
│                                          │
│ We offer: snacks, health insurance, ...  │
│ Contact: hr@example.com                  │
└──────────────────────────────────────────┘

Adapted view:

┌──────────────────────────────────────────┐
│ Middle PHP Developer                     │
│                                          │
│ Stack:         PHP 8, Laravel, MySQL     │
│ Location:      Chișinău, hybrid          │
│ Requirements:  3+ years, ORM, Docker     │
│                                          │
│ [show more]                              │
└──────────────────────────────────────────┘

This is the shallow view — here the LLM mostly repackages structure. The more complex case — template caching, cost, and protection of critical information — is covered below in the real estate example.

5. When does the LLM actually run? (not on every page load)

If the LLM had to be called on every page render, an adaptive interface would be both expensive and slow. But that's not required: the LLM is called once — when a template is created for a user or cohort. After that, pages are assembled from that template via ordinary rendering, with no model involved.

There are two modes, differing in who initiates generation and when it happens:

Mode	Who initiates	When it's generated	Where it's stored
Individual	User (via settings)	Once at runtime, the moment settings are saved	In the user's profile
Cohort	Administrator	Once at build-time (or on a schedule)	As part of the build or in the CDN

What exactly gets stored as "the template" depends on the mode:

In the individual case — a JSON description of the blocks: their order, visibility, and styles. This format is safe (arbitrary markup can't break the site) and compact.
In the cohort case — ready-made component code, which the administrator reviews before deployment.

Invalidation. When the data schema changes (e.g. a field is added or renamed), previously generated templates no longer match reality — they need to be invalidated and regenerated.

Two-level cache. In some cases the LLM is needed not only for the template but for the content itself — for example, if the template calls for a shortened version of the description, someone has to produce that shortened version too. This is solved with a second level of cache:

Level one — the template, keyed by (user) or (cohort).
Level two — the rewritten content, keyed by (object, style). The shortened description of apartment #42 in the "under 200 characters" style is generated once and reused for all users who chose that style.

This turns "LLM per request" into "LLM once per unique object-and-style pair".

6. Full walkthrough: adapting a real estate listing

Let's walk through the mechanics on a concrete example — the apartment page on a real estate site. Each user here has their own priorities: some care about furniture, others about the neighborhood, others about the building itself.

6.1. The settings interface

The account settings have a free-form input field: the user describes in their own words what matters to them.

Example input:

"I want to see photos and furniture right away. Keep the description short, no fluff. Move building info to the very bottom — it's not important to me."

Free-form input is convenient because the user isn't boxed in by toggles and checkboxes — they just say what they want, the way they'd say it to a friend.

6.2. What the LLM does

The LLM turns this text into a JSON template — a structured description of the page: which blocks to show, in what order, with what settings.

{
  "blocks": [
    { "id": "gallery",     "order": 1, "style": "detailed" },
    { "id": "furniture",   "order": 2, "style": "detailed" },
    { "id": "description", "order": 3, "style": "short", "maxLength": 200 },
    { "id": "building",    "order": 4, "style": "compact" }
  ],
  "furniture_priority": ["fridge", "dishwasher", "conditioner"]
}

The template is stored in the user's profile and used to render every apartment page they open.

6.3. Consistency

The template is generated once and stays stable between visits. The user gets used to the block layout on the page and finds what they need faster: where the furniture is, where the description is, where the contacts are.

The template is only regenerated when the user re-saves their settings. No unexpected interface changes between visits, no "magical" reshuffling of the page.

6.4. Cost and latency

Generating a template is a single LLM call. Let's ballpark the scale:

Latency. A request returning a couple hundred tokens takes 1–3 seconds on modern models.
Cost. At current prices, one such request runs about $0.001–0.01 depending on the model (cheaper for lighter models, more expensive for stronger ones). This is an order-of-magnitude estimate, not a precise quote — the real numbers depend on the model and prompt size.
Frequency. A real user re-tunes their preferences rarely — say, up to ten times a year. That puts the annual cost of templates for 1M active users at roughly $10K–$100K in total — not per request.

Subsequent page renders run as usual, with no LLM involved: the server fetches the template from the profile and plugs in the data for the specific apartment. The model is not touched on each request.

When saving settings, the user sees a brief "preparing your view…" spinner for a couple of seconds — a one-off wait, not a delay on every page load.

On shortened descriptions. If the template says "style": "short", then at render time someone has to compress the original description text. That's another LLM call, but it's cached by the (apartment, style) pair and reused across all users with that style. For 10,000 apartments and 3 popular shortening styles, that's 30,000 calls total — once per pair, not millions per day.

6.5. Protecting critical information

While "simplifying" the page, the LLM could drop something important: the price, contacts, a deposit. Two mechanisms guard against that.

Required blocks. The site developer defines a list of blocks the LLM is not allowed to hide. For apartments, that's the price, address, and contacts. The LLM may reorder them but can't remove them. A template that violates this rule is rejected — the default is used instead.

"Show original" toggle. Every adapted page offers a one-click return to the full original version. If the user feels the shortened version missed something, or simply wants to see everything as-is, a single click restores the standard page.

6.6. Who pays for this

The LLM costs are borne by the site owner — as part of infrastructure or marketing spend, not a charge to the user. The $10K–$100K per million active users per year mentioned above is in the same ballpark as a single marketing campaign. If the adaptation lifts conversion or retention by even a few percent, the investment pays for itself many times over. The economics work like any other UX investment; the difference is that the effect comes not from a one-off redesign but from continuous tuning to specific users.

7. Where to put the adaptation logic: site, proxy, extension, browser

By now it's clear what is adapted and how it's stored. The remaining question: where does the adaptation logic live? There are several options, differing in who controls the adaptation and how many sites it works on.

Option	Who controls	Scope	What the user does	How it's integrated
Site-level	Site owner	One site	Nothing	Part of the site's code
Proxy	Site owner or third party	Sites using the proxy	Nothing	Between the site and the user
Browser extension	User	All sites	Installs an extension	Browser plugin
AI browser	User	All sites	Switches browsers	Built into the browser

The two axes here are who initiates the adaptation and how many sites it works on. Site-level and proxy solve the problem on the site owner's side; extensions and AI browsers solve it on the user's side, on top of any site.

8. Use cases: e-commerce, news, recipes, real estate

An adaptive interface isn't a single feature but an approach that shows up differently across domains. Below are a few scenarios, each highlighting a different facet of the idea.

8.1. E-commerce — cohort approach

In e-commerce it makes sense to split users into cohorts and generate a dedicated version of the page for each one. For seniors — larger font and only the essential information; for power users — detailed specs and comparison with alternatives; for beginners — simpler wording and more explanation.

Generation happens at build-time: the administrator gives the LLM requirements for each cohort, the model produces page versions, and the administrator reviews the results before deploying. At runtime the user simply gets the version that fits them — no LLM calls required.

8.2. News — where an LLM is indispensable

In the earlier examples (real estate, jobs), the LLM mostly repackaged structure — reordered blocks, hid unneeded ones, sometimes shortened text. That kind of work can be approximated without a language model, e.g. through drag-and-drop settings.

News is different. The content itself is the product of the page, and it can't simply be "rearranged" — it needs to be understood, reassembled, and enriched. Here are three scenarios where only an LLM handles the job:

A knowledge graph from an article. An article about a central bank rate hike contains dozens of entities: people, organizations, events, concepts. The LLM extracts them along with their connections and displays them as a graph — click a node and a card expands. A template can't do this: each article's graph is unique and is built from the article's own content.
Adaptive depth of context. A novice reader going through an article about the central bank rate doesn't always understand the terminology. The LLM sees their level of knowledge and adds inline explanations: "the key rate is…", "the previous hike was on…". An expert doesn't see those callouts, but does see an expanded "related regulator decisions" section. This only works as a content-level transformation tied to the specific article.
Cross-source synthesis. An aggregator has five articles about the same event from different outlets. The LLM assembles a synthesis: "all of them agree on X; source A claims Y, B contradicts it; only C has the unique detail Z." The result is a new artifact that doesn't exist in the database — it comes into being only after the LLM builds it.

8.3. Recipe site — different users, different interests

The same recipe page can be shown differently depending on who is reading it:

A vegetarian — sees at a glance whether the dish fits them, and alternatives for meat ingredients.
A diabetic — carbs, glycemic index, and calories are pulled to the top; the recipe itself is below.
A beginner cook — photos of each step, technique explanations, a timer.
An experienced cook — only the ingredient list and a short description of the technique.
A parent with a child — allergens and cooking time on top, everything else secondary.

Same page — five different first screens. The example makes it clear that "one page for everyone" isn't a technological inevitability but a simplification that can be dropped.

8.4. Real Estate

Already covered in detail in Section 6: prioritizing blocks from the user's free-form intent, shortened descriptions, and protection of required fields like price and contacts.

8.5. Language adaptation and multilingualism

Choosing a language and style of presentation is a special case of the same idea. A standard translation works bluntly: the same text is translated once and shown identically to every speaker of that language. With an LLM you can adapt not just the language but also the style, density, and tone — to a specific reader.

A few examples:

For a young reader — shorter sentences, modern vocabulary.
For an older reader — a more formal and detailed tone.
For a foreigner learning the language — simplified grammar and explanations of complex terms.

From the same database you get several versions of the text. Each is generated once and cached by the (object, style+language) pair — following the same pattern as the shortened descriptions in Section 6.4.

8.6. Where adaptation doesn't belong

Adaptive interfaces work well where a page is overloaded and different users have different priorities. But there are contexts where adaptation is more likely to do harm than good:

Legal and medical documents. The exact wording of a contract, insurance terms, a prescription, an informed consent form — these are the law or a protocol, letter by letter. Any "simplification" by an LLM is unacceptable here. At most, it makes sense to show a plain-language retelling alongside — never in place of — the original.
Financial and payment interfaces. Account numbers, bank details, transfer amounts, confirmation codes — every single character matters. An LLM mistake here costs money, not just inconvenience.
Pages with nothing superfluous. If a page is already minimal (a login form, a single button, a short card), there's nothing to adapt — and trying will create chaos where everything was already clear.
Complex tools with a well-established interface. Control panels, code editors, accounting software — users spent weeks memorizing where every button is. Automatically restructuring such an interface is a productivity loss, not a win.

The rule is simple: adaptation belongs where the cost of error is low and users have different priorities. Where the cost of error is high, or the interface is already well-learned, it's better to leave things alone.

9. A working Django + OpenAI prototype

To validate the approach beyond diagrams, I built a small working prototype — a recipe site where a logged-in user can adjust the block priority right on the recipe page.

What the user sees. The recipe page shows seven blocks in a default order: photos, timing, ingredients, instructions, nutrition, allergens, chef's tips. Above the blocks sits an adaptation panel asking "What matters to you in a recipe?".

Default view — photos on top, everything else in standard order.

The user types their intent in plain language, hits Apply, and the blocks reorder live — no page reload. Two buttons appear: Accept saves the order to the user's profile so every other recipe opens with the same layout; Revert restores the default.

After applying "Tips should be at the first stage. The rest as before" — chef's tips moves to the top; the rest stays in order.

How it works under the hood.

Stack: Django + Django templates + vanilla JavaScript. OpenAI API (gpt-4o-mini) turns the free-form text into a block order.
Template format: just a JSON array of block IDs in the desired order. Any ID not in the array is hidden. No styles, no extra metadata — the minimum that still lets the user express priority.
Storage: the array lives in a UserTemplate model, one-to-one with the user.
Safety: the backend filters the LLM's response against an allowlist of seven known block IDs, so the model can't inject anything unexpected.
Cost: the LLM is only called when the user hits Apply. Every subsequent page render is a regular Django server render, with no LLM involved.

What this confirmed. The prototype reproduces the core mechanic from this article end-to-end with minimal tooling. Three concrete observations:

A plain-language prompt from the user reliably turns into a correct block order. If the model returns something unexpected, the allowlist filters it out.
The LLM only runs when the user clicks Apply. Users who don't change anything cost nothing.
The feature feels like a normal preference setting, not like "the AI took over the page" — which matters for trust and consistency.

10. Conclusion

The web page is no longer a static artifact. The same data can now be delivered to each user or cohort in the form most convenient for them — and sometimes with additional information that wasn't in the source data at all.

What makes this realistic in practice is how the LLM's work is distributed. The model is only invoked when preferences change or a cohort is rebuilt; templates and rewritten content are cached; the per-page render delay stays at zero; cost stays bounded. The risk of losing something important is covered by two simple mechanisms: required blocks and the "Show original" toggle.

The next step is not to rewrite your whole site, but to pick a single page type (a product card, an apartment, a job listing, an article) and adapt it to specific users. That's enough to see whether the approach works in your product.

11. Limitations: accessibility, privacy, testing

This article describes the approach but doesn't close every question that comes up when you try to implement it. Five questions worth thinking through before you build on the idea:

Does this break accessibility?

It can. Automatically regenerated markup can break screen readers (used, for example, by blind users) and other assistive technologies. You have to explicitly make sure headings, buttons, and element order stay correctly marked up — otherwise "interface improvement" turns into an accessibility regression.

What about user privacy?

To adapt the page, data about the user's preferences and behavior ends up in the LLM. You have to decide upfront what the user consents to, which data goes out, and how long the results are stored — in many countries this is regulated by personal-data protection laws.

How do you A/B test an adaptive page?

Classical A/B testing is complicated by the fact that each user sees their own version of the page. You need cohort-level metrics and an explicit feedback signal — for example, the share of "Show original" clicks as an indicator that the adaptation didn't fit.

What happens when the LLM fails?

When generation fails or the model is unavailable, the system has to fall back to the default version cleanly, with no visible glitches for the user.

How is this different from reader modes and personalization engines?

The idea overlaps with browser reader modes, on-site personalization systems, interface-simplifier extensions, and the recent wave of AI-driven generative interfaces. A serious product built on this idea has to show honestly how it differs and where it wins.

None of these questions invalidates the approach — but each needs separate work before the idea turns from a concept into a real product.

DEV Community: Madjar Evan