Zunkiree Labs

Generative UI development

Stop making users learn your dashboard.

Generative UI: interfaces assembled at runtime around what the user is actually trying to do. The model chooses and fills real components from your design system, so the answer arrives as a working control, not a paragraph.

Try it yourself Scope a pilot

Your components. Your design system. Your permissions.

✓ Chose 3 components✓ Props validatedGenerated live

Revenue

42.8k

+8%

Orders

318

+5%

Avg. order

134.6

flat

By channel

18.4k
11.2k
8.6k
4.6k
WebInstaWhatsAppStore

✦ Insight

Web drives 43% of revenue and grew 8% this week. WhatsApp is the smallest channel but the fastest rising

Written from the data above

7 days30 daysExport
✦Show revenue by channel this week
What is generative UI?

Instead of describing the answer, the software builds it.

Generative UI is an interface composed at runtime by a model choosing and filling components from your own design system.

It is used for dashboards, adaptive forms, internal tools and in-product assistants: anywhere a user knows what they want but not where it lives.

The problem
Most software makes people learn where things live. Chat helps, but it answers in text, and the user still goes somewhere else to do the work.
The idea
A model reads the request and assembles the screen for it: real components from your design system, filled with live data, with the controls attached.
The guardrail
It can only use components you have approved, with props a schema validates. It never writes markup, so your design system and permissions stay in charge.
  1. 1

    Ask

    The user says what they want in plain words.

  2. 2

    Choose

    The model picks components from your registry.

  3. 3

    Validate

    Props are checked against your schema. Failures fall back to text.

  4. 4

    Render

    Real components appear, filled with live data.

Live Demo

One request. Every interface.

Scroll to watch an agent build real screens, then tap anything it makes.

NNorthwind
Components Sample content

✦

Simulated example built from our four example screens. Nothing is generated live or stored.

How it works

The model never writes markup. It chooses from components you already own.

  1. 01

    Intent

    The request arrives in natural language, from a prompt box or an assistant already inside your product.

  2. 02

    Data

    The system fetches what is asked for through your existing APIs, under the viewer’s permissions, not the model’s.

  3. 03

    Component selection

    The model names components from your registry. A name outside it cannot be rendered at all.

  4. 04

    Prop validation

    Every prop is checked against a schema first. Invalid props fail closed and fall back to text.

  5. 05

    Streamed render, action in place

    Components stream in as they resolve, and the controls are real: adjust, correct, approve, export.

What the model returns 
[
  { "component": "KpiRow",
    "props": { "range": "7d", "metrics": ["revenue", "orders"] } },
  { "component": "BarChart",
    "props": { "by": "channel", "range": "7d" } }
][
  { "component": "FullScreenPopup",
    "props": { "message": "Buy now!" } }
][
  { "component": "BarChart",
    "props": { "by": "channel", "range": "forever" } }
]

Accepted: both components are in the registry and the props pass the schema

Revenue

…

Orders

…

Rejected: “FullScreenPopup” is not in your registry, so nothing renders

Fallback
The user gets a plain text answer instead. Your design system is untouched.

Rejected: “range” must be one of 7d, 30d, 90d

Fallback
Invalid props fail closed. The worst case is a plain answer, never a broken screen.

Illustrative example. It cycles every 2 seconds; click a tab to hold one.

What it is used for

Six jobs where generative UI earns its place.

It is the wrong tool for most of a mature product. These are the cases where it is clearly the right one.

Conversational dashboards

Instead of hunting for a saved report somebody built two years ago.

You get the view you asked for, filtered and charted.

Forms that adapt

Instead of one long conditional form with every field on screen.

You get only the fields a given case needs, with validation intact.

Internal tools

Instead of requests that never justified a sprint.

You get a filtered queue, a bulk action or a reconciliation view on demand.

In-product assistants

Instead of instructions the user has to follow by hand.

You get a populated settings panel or a prefilled checkout.

Reporting for non-analysts

Instead of needing your schema, table names and where the report was filed.

You get an answer from someone who only knows the question.

Data exploration

Instead of a fixed screen that could not predict where the analysis goes.

You get a next view shaped by the last answer.

Same question, two paths

“Which region declined last quarter?”

Fixed screens

Six screens somebody had to design. The user has to know the path.

Home01Reports02Sales03Region view04Filter: last quarter05Compare to previous06

Generative UI

One request. The answer arrives as an interface, with the controls attached.

Ask Answer + controls

Illustrative example with made-up data. Both paths start together.

Alternatives

Chat, fixed screens, or generative UI?

Chat reply

Best when the answer is genuinely prose.

Output
Text
Who designed it
Nobody
Unanticipated asks
Yes, as text
Act on the answer in place
No
Layout
n/a
Cost per new view
None

Fixed screens

Best when the task is known and repeated.

Output
Interface
Who designed it
A developer, in advance
Unanticipated asks
No
Act on the answer in place
Yes
Layout
Completely predictable
Cost per new view
A sprint
What we build

Generative UI

Best for the long tail nobody anticipated.

Output
Interface
Who designed it
Assembled at runtime from your components
Unanticipated asks
Yes, as interface
Act on the answer in place
Yes
Layout
Predictable within the component registry
Cost per new view
None

Fixed screens remain the right answer for most of a mature product, and we would not propose replacing them. Generative UI earns its place on the long tail: the one-off views that never justified a build.

How we build it

The model is the small part.

The work is mostly in your component layer: what exists, what is allowed, and how it is tested. Get those right and the model has very little room to go wrong.

  1. 01

    Your component library

    A component library worth generating from: React components with clear props, in reasonable shape.

  2. 02

    One surface first

    The screen users complain about most, built beside your current UI so you can compare the two directly.

  3. 03

    Data and permissions

    Your existing endpoints and permission model, honoured exactly. There is no second access path.

  4. 04

    Registry and schemas

    Approved components by name, with every prop checked against a schema before anything renders.

  5. 05

    Real-request tests

    Ten or twenty real requests become the regression suite, which is how you test an interface that changes every time.

When to use it and when not to

A good fit
  • ✓The long tail of questions no fixed screen covers
  • ✓Reports people cannot find or cannot ask for in your schema
  • ✓Long forms where most fields do not apply to most cases
  • ✓Assistants that should do the task, not describe it
A poor fit
  • —Well-understood, repeated flows like checkout, where a fixed screen is better
  • —Screens where the exact wording or layout is fixed by regulation
  • —Tasks that are already one good screen

Fixed screens stay better wherever the task is understood and repeated. That is most of a mature product.

FAQ

Questions about generative UI

What is generative UI, in one sentence?

It is an interface composed at runtime by a model choosing and filling components from your design system, rather than a set of screens laid out in advance by a developer.

How is this different from a chatbot in our product?

A chatbot returns text and leaves the user to go and do the thing. Generative UI returns the thing — the populated form, the chart with its filters, the button that completes the action. The conversation is the input method; the output is still your product's interface.

Can the model invent components or break our design system?

No, and that is the point of the architecture rather than a promise about model behaviour. It can only emit a component name from a registry you define, with props a schema validates. An unknown name or an invalid prop fails closed and falls back to text, so the worst case is a plain answer, never broken or off-brand markup.

Does every screen in our product need rebuilding?

No — and it would be a poor idea. Fixed screens are better wherever the task is well understood and repeated, which is most of a mature product. Generative surfaces earn their place on the long tail: the questions nobody anticipated and the one-off views that never justified a build. We usually start with a single surface alongside your existing UI.

What about latency — will users wait for an interface to generate?

Components stream as they resolve rather than appearing all at once at the end, so the first useful element lands quickly. Where a task is predictable we cache the arrangement and regenerate only the data, which removes model latency from the common path entirely.

How do you test an interface that is different every time?

You test the pieces and the contract, not the permutations. The components have their own tests as usual; the model's output is validated against the prop schemas; and we keep a suite of recorded real requests as regression cases. What you cannot do is rely on screenshot comparison of whole pages, which is the genuine cost of the approach.

Sources and further reading

Where the claims on this page come from.

Outside references for the claims on this page. Our own descriptions of what we build are our own account, not independent evidence.

Last updated · Zunkiree Labs, Kathmandu, Nepal

Vercel AI SDK documentation Generative user interfaces Describes the pattern of connecting a model’s tool-call result to a React component, the same approach as the component registry described here. Read source Google Research Generative UI: a rich, custom, visual interactive user experience for any prompt Research on models generating custom, interactive interfaces in response to a prompt. Read source JSON Schema Understanding JSON Schema The schema language used to validate a component’s props before anything renders. Read source
Related Custom Agent AI Development Web Development Voice Agent
Get Started

Try it on one surface first

Pick the screen your users complain about most. We will build a generative version against your real components and data, and you can compare them side by side.

Based in Kathmandu, Nepal · Clients in Nepal and abroad

Scope a Pilot View Case Studies