From Sanskriti Khandelwal | Product & Market Analysis
Generative UI Scored 1736 to a Designer's 1800. The Craft Moves to Constraints
On this page
Google Research put its generative UI system against websites built by human experts and published the scores. The humans won, 1800.3 Elo to 1736.2. Every other output format lost badly to both. That 64 point gap is the whole argument about what design work becomes, and it does not point at fewer designers. It points at a job that produces constraints instead of screens.
Key takeaways
- Generative UI came second to human designers and beat everything else. In Google Research's evaluation, human expert sites scored 1800.3 Elo and generative UI scored 1736.2, against 1437.7 for generated markdown and 1173.7 for plain text answers.
- The component catalogue is turning into the interface contract. Google's A2UI protocol, open sourced on 15 December 2025, lets an agent request only components the client application has pre-approved, and keeps styling under the client's control.
- Most design systems are nowhere near ready to be that contract. In zeroheight's 2026 survey of 147 practitioners, 7% called their system fully adopted across all teams, 61% of system teams said they were understaffed and 5% measured return on investment.
- Evaluation is the scarce skill, not screen production. 95.9% of the top one million home pages already fail automated accessibility checks, and an interface assembled per request cannot be reviewed one screen at a time.
What generative UI actually means
Generative UI is an interface a model assembles while the user waits. It is not a mockup produced faster. It is not a component suggested inside a design tool. The screen is decided at request time, for one person's stated intent, and it may never exist again.
That is a different object from the one the design profession built its process around. A design system assumes the set of screens is finite and reviewable. Runtime assembly assumes it is neither.
Three different things share the name
The term covers three technologies, and conflating them wastes quarters. Separate them before you plan anything.
The first is AI inside the design tool. Figma's 2026 research puts 33% of designers using AI to generate design assets and 22% using it to draft interfaces. That changes throughput. It does not change what a screen is.
The second is AI that writes front-end code from a prompt. The output is still a build artefact. A person reviews it, merges it and ships it on a release cycle you control.
The third is the subject of this post. A model selects and arranges components at request time, and no human sees the result before the user does. Only the third case breaks the review loop that design management rests on.
Google published its generative UI research in November 2025 and described the implementation as Gemini 3 Pro with tool access, system instructions and post-processing. The capability now sits inside Search and the Gemini app, under the names visual layout and dynamic view.
Jakob Nielsen called the result the dawn of cheap, disposable UI. That phrase is the useful one. A disposable interface cannot be approved individually, so what you approve instead is the space it gets drawn from. Software has been drifting this way for a while, which is the argument in the piece on why the dashboard is dead.
The evidence, and the part it does not cover
The strongest public evidence is Google's own. Yaniv Leviathan and eleven co-authors published Generative UI: LLMs are Effective UI Generators in February 2026.
The method is worth stating because it bounds the claim. The team sampled 100 prompts from LMArena, produced outputs in five formats, and collected pairwise human preferences on a three point scale with two raters per result. A second set of 100 information seeking prompts ran alongside it.
| Output format | Elo | Gap to the leader |
|---|---|---|
| Website built by a human expert | 1800.3 | Leader |
| Generative UI | 1736.2 | 64.1 points |
| Generated markdown | 1437.7 | 362.6 points |
| Top search result website | 1352.2 | 448.1 points |
| Generated plain text | 1173.7 | 626.6 points |
Elo here is derived from pairwise human preference, not from an objective quality measure. Read the gaps rather than the absolute values.
Read the distances, not the ranking. The human designers are 64 points ahead of the model. The model is 363 points ahead of the format most AI products actually ship, which is generated markdown, and it was preferred over markdown in 82.8% of pairwise comparisons.
That is the finding that matters commercially. The competition for generative UI is not a designed product. It is the wall of text your AI feature returns today.
Who ran the evaluation
Google Research built the system, wrote the prompts, ran the raters and published the paper. That is not a reason to throw the numbers out. It is a reason to hold them loosely until somebody independent repeats the test.
Two versions of the human comparison also circulate, and they do not agree. Nielsen wrote in November 2025 that human designs were preferred 56% of the time against 43% for the model. The February 2026 paper reports human expert sites chosen in 50.0% of comparisons. Those may be different evaluations rather than a trend, and nothing published reconciles them.
The paper names its own biggest weakness plainly, which is more than most vendor research does. Generation is slow, often a minute or two, and outputs sometimes carry JavaScript, CSS or HTML errors.
The design system stops being a library and becomes an API
If a model picks the components, then the set of components is the product decision. Everything downstream of that choice is arithmetic. This is the part design leaders should act on now, because a catalogue a machine can read is useful whether or not anything generative ever ships.
A2UI keeps the catalogue on your side of the line
On 15 December 2025 Google open sourced A2UI, a format for agents to describe interfaces as structured JSON rather than executable code. Renderers exist for Lit, Angular and Flutter. Collaborators listed at launch include AG UI and CopilotKit, Opal, Gemini Enterprise and the Flutter GenUI SDK.
The design-relevant sentence is in the protocol's own description. The client application holds a catalogue of trusted, pre-approved components, and the agent may only request from it. The client keeps full control of styling and security.
Read that as a boundary drawing exercise rather than a technology. Brand, spacing, contrast, focus order and error states stay with you. Composition and sequencing move to the model. Negotiating exactly where that line sits is the design leadership work of the next two years.
It is the same structural move that MCP made for tool access, applied to pixels instead of functions. Whoever defines the catalogue defines what is possible, and the protocol is deliberately quiet about who that should be.
Design tokens now have a stable spec
The other half of the contract arrived earlier. On 28 October 2025 the W3C Design Tokens Community Group published version 2025.10, its first stable specification. It covers colour, typography, spacing, theming and aliases across web and native platforms. More than 20 organisations participated or implemented, including Adobe, Amazon, Google, Microsoft, Meta, Figma, Salesforce and Shopify.
One caveat that vendors skip. This is a Community Group specification, not a W3C Recommendation, so it has not been through the full standards track. It is stable and widely implemented, and it is not a formal web standard yet.
Tokens matter here for a narrow reason. They are how a design decision gets stated in a form a machine consumes without a person in the middle. A constraint that only lives in a Figma file or a slide is not a constraint a generator can obey.
Components need the same treatment, and this is where most systems fall down. A model choosing between a table and a chart needs to know what each is for, when it fails, and what it must never be paired with. Most component documentation is written for a human who reads it once. Writing it for a consumer that reads it every time is closer to context engineering than to documentation.
| Work | Where it goes | Why |
|---|---|---|
| Screen layout for a known intent | Generated at runtime | Composition is the thing models are already competitive at. |
| Visual consistency across screens | Tokens and renderer | Enforced once, applied everywhere, cheaper than review. |
| Which components exist at all | Human, deliberately | The catalogue is the ceiling on what can ever be produced. |
| What a component is for | Human, written for machines | Selection quality depends entirely on stated intent. |
| Problem definition and research | Human | No generator has access to what your users struggle with. |
| Deciding what "good" means | Human, as a test suite | This is the reviewable artefact once screens stop being one. |
Rows three, four and six are the ones most teams have never staffed explicitly. They also decide the output quality of everything in row one.
What happens to craft
Figma asked 906 digital designers to define craft, through the research firm NewtonX, across five regions and seven languages. The most common answer was visual polish, at 58%. Then thoughtful problem-solving at 47%, clear and intuitive user experience at 36%, emotion and delight at 35%, and consistency across products at 15%.
Visual polish is the most automatable definition of craft
A renderer fed a stable token file holds spacing, contrast and type scale steady across a thousand generated screens. It will do that more reliably than a team of people under deadline. Polish is the part of craft that survives delegation best.
Consistency across products came last, named by 15%. Under runtime assembly it becomes the hardest property to hold and the most expensive to lose, because there is no fixed set of screens to compare against each other.
If I were rewriting a design team's craft ladder this quarter, I would build it around the 47% answer. Visual polish becomes a property of the system rather than an achievement of a person. That is unpopular with senior individual contributors, and I think it is correct.
None of this reads as a profession in retreat. Among those 906 designers, 91% said AI tools improve their designs and 89% said they work faster. In Figma's wider sample, 90% said design is as important or more important than before AI, and 65% of developers agreed with them.
Evaluation becomes the scarce skill
You cannot usability test a screen that does not exist yet. You can test the generator that produces it, and almost nobody in design has been trained to do that.
The shape of the work is established elsewhere. Fix a set of representative user intents. Generate an interface for each. Score the output on accessibility, correct component selection, task completion and tone. Run it on every change to the catalogue, the prompt or the model. That is an eval suite, and model teams have built them for two years. The walkthrough of building one is a better starting reference right now than most design literature.
Accessibility is the measurable floor
The February 2026 WebAIM Million found detected WCAG 2 failures on 95.9% of the top one million home pages, up from 94.8% the year before. The average page carried 56.1 errors, up 10.1%. Six years of slow improvement reversed.
Six failure types account for 96% of all detected errors. Low contrast text on 83.9% of pages, missing image alternative text on 53.1%, missing form input labels on 51%, empty links on 46.3%, empty buttons on 30.6%, and missing document language on 13.5%.
Every one of those six is enforceable once, inside a component. This is the strongest argument available for the pre-approved catalogue model, and it is not the argument vendors make. Hand-built pages fail these checks 95.9% of the time. An interface restricted to components that pass them cannot fail them at all.
That is the one claim in this post I would bet money on. The honest limit is that automated tools detect a minority of WCAG criteria, so a page with zero detected errors is not an accessible page. It is a page that passed the cheap checks, which is still the floor worth enforcing at volume.
What this does to the shape of a design team
Figma's 2026 AI report ran 8,403 survey responses and 639 qualitative interviews across 10 markets, published on 24 June 2026. Two of its numbers describe a boundary dissolving. Designers doing development work went from 21% to 41% in a year, and developers doing design work went from 44% to 60%.
The official labour data says something calmer. The US Bureau of Labor Statistics counts 220,100 web developers and digital designers in 2025, with 5% projected growth to 2035, and median pay of $99,520. A 5% decade is neither collapse nor boom. Anyone claiming the role disappears is arguing against the official projection, and should say so.
The staffing math does not work yet
zeroheight's fifth annual report surveyed 147 practitioners. 83% of organisations now have a dedicated design system resource, up from 78%, and the most common team size is one to two people at 28%.
Then the harder numbers. 61% of those teams say they are understaffed. Only 38% describe the system as moderately adopted and 7% as fully adopted. Just 5% measure return on investment, and satisfaction with buy-in fell from 42% to 32% in a year.
Put those beside the protocol news and the tension is obvious. The artefact that generative UI makes load-bearing is owned by one or two people, understaffed by their own account, unable to demonstrate their return, and losing executive support.
If you are a design leader with one budget line to move in the next two quarters, move it here. Not into AI tooling for designers, which the market will give you anyway. Into the catalogue, its metadata and its adoption.
Where this argument is weakest
Two places, and the first should slow you down most.
The case that nothing much changes
The evaluation tested information seeking and open prompts. Nobody has published a comparable result for a stateful workflow application with permissions, audit requirements and multi-step transactions.
Those are most of enterprise software. A generated interface that has to satisfy a compliance reviewer is a different problem from one that has to explain a topic well. The evidence does not reach that far, and treating a Search result as proof about your billing console is a category error.
The slow generation the paper flags cuts the same way. A minute or two is acceptable for a research answer and disqualifying for a screen a support agent opens 200 times a day.
The part nobody can settle
Both cases rest on how fast generation quality improves, and nobody has a defensible rate for that. Anyone quoting one is extrapolating from a handful of model releases.
So the useful move is to name what would change your mind. Mine is three things. An independent evaluation not run by the vendor whose system is being scored. A generative interface shipped in a regulated workflow, with published error rates. And a design system team publishing its catalogue as a machine-readable contract, then reporting what the generator did with it.
Until one of those lands, treat generative UI as proven for answers and unproven for applications. That is a narrower claim than most writing on this subject, and it is the one the evidence supports.
What design leadership does in the next two quarters
The work is unglamorous and it does not require betting on a timeline. Every item below pays off even if runtime assembly stalls entirely.
| Move | What it produces | Value if generative UI stalls |
|---|---|---|
| Export tokens to the W3C 2025.10 format | Machine-readable visual constraints | Cross-platform consistency and easier tool migration. |
| Write component intent, not just props | Documentation a selector can read | Faster onboarding and fewer misused components. |
| Build a 20 intent evaluation set | A definition of good you can run | Regression testing for any UI change, human or not. |
| Automate accessibility checks in the catalogue | An enforced floor on six common failures | Direct legal and usability benefit on day one. |
Deliberately absent: buying a generative UI product. On current evidence there is nothing to buy that a catalogue and an eval set will not serve better.
Hiring changes sooner than the org chart does. The question that separates candidates is no longer about portfolio screens. It is whether someone can state, in writing, what a component is for and when it should not be used, which is a close cousin of the questions in the guide to interviewing for AI fluency.
The entry-level risk deserves naming honestly. If junior work has historically been screen production, and screen production delegates first, the training path narrows. Engineering hit this first, and the mechanics are the same ones described in the piece on the junior developer pipeline. Assume it applies to design and plan a different apprenticeship rather than waiting to find out.
Frequently asked questions
What is generative UI?
Generative UI is an interface assembled at runtime by a model rather than drawn in advance by a designer. The model chooses layout and components in response to the user's intent, then a client renders them. Google shipped it inside Search and the Gemini app in 2026, and published an open protocol, A2UI, for agents to describe interfaces to a host application.
Will generative UI replace designers?
Not on the current evidence. In Google Research's own evaluation, sites built by human experts still scored highest, at 1800.3 Elo against 1736.2 for the generative system. What changes is where the work sits. Fewer hours go into drawing individual screens, and more go into the component catalogue, the constraints, and the tests that decide whether an assembled interface is acceptable.
Do design systems still matter with generative UI?
They matter more, and most are not ready. A model assembling an interface at runtime can only use the components it is allowed to request, so the catalogue becomes the contract. zeroheight's 2026 survey of 147 practitioners found only 7% of organisations describing their system as fully adopted across all teams, and 61% of system teams reporting they are understaffed.
How do you test an interface that is generated at runtime?
You test the generator and the constraints, not the screen. That means a fixed set of representative user intents, a rendered output for each, and scored checks on accessibility, correct component use, task completion and tone. Model teams already run this pattern as an eval suite. Design teams can copy it, because the alternative is reviewing an interface nobody has seen before.
What is A2UI and why does it matter for designers?
A2UI is an open protocol Google published in December 2025 that lets an agent describe an interface as structured JSON instead of executable code. The client application keeps a catalogue of pre-approved components and controls all styling. For a designer that is the important sentence, because it means brand and accessibility decisions stay on your side of the boundary rather than the model's.
What skills should a product designer build in 2026?
Three, in order. Writing constraints a machine can read, which means tokens, component metadata and stated rules about composition. Designing evaluation, which means deciding what a good generated interface is before you see one. And accessibility, because it is the one quality attribute that can be measured automatically at the volume runtime assembly produces.
Where to start this week
Pick the two smallest things on the list above and do them properly.
Open your three most-used components and write, in plain sentences, what each is for and when it must not be used. Not props. Purpose and prohibition. If nobody on the team agrees on the answer for a component, you have found the first thing a generator would get wrong.
Then run an automated accessibility check across your component library, not your pages, and count how many of the six common WebAIM failures your system already prevents. That number is your real readiness score for anything assembled at runtime, and it takes an afternoon to produce.
Related on this site
This sits next to two arguments about where interfaces are going: why the dashboard is dead, and how to build the eval suite that replaces reviewing screens one at a time.
References
- Leviathan, Valevski, Kalman and others, Google Research, Generative UI: LLMs are Effective UI Generators, arXiv 2604.09577, February 2026. Used for all Elo scores, the 82.8% markdown comparison, the 50.0% figure and the stated limitations.
- Google Research, Generative UI: a rich, custom, visual interactive user experience for any prompt, 18 November 2025. Used for the implementation description and product names.
- Google Developers Blog, Introducing A2UI: an open project for agent-driven interfaces, 15 December 2025. Used for the pre-approved catalogue model and launch collaborators.
- W3C Design Tokens Community Group, Design Tokens specification reaches first stable version, 28 October 2025. Used for version 2025.10, scope and participating organisations.
- zeroheight, Design Systems Report 2026, fifth annual edition, 147 practitioners. Used for adoption, staffing, AI use and measurement figures.
- Figma, State of the Designer 2026, 906 digital designers surveyed with NewtonX. Used for the craft definitions and satisfaction figures.
- Figma, 2026 AI Report, 24 June 2026, 8,403 responses and 639 interviews across 10 markets. Used for the role-blur figures.
- WebAIM, The WebAIM Million 2026, February 2026, and US Bureau of Labor Statistics, Web Developers and Digital Designers, 27 August 2026. Used for accessibility and employment figures.
The weakest thing about this source base: the central evaluation was designed, run and published by the team that built the system being scored, and no independent replication exists. The two Figma studies and the zeroheight report are vendor research with disclosed samples, which is better than most and still not neutral.
Related reading