When the interface assembles itself
Generative UI turns a design system from a library of screens into a contract of components. What has to be true before that is safe to turn on.

A system that assembles itself needs rules a machine can read.
Generative UI changes what a design system is for. A library of screens is a set of examples. A contract of components is a set of rules, and only the second kind can be assembled by something other than a person.
The distinction becomes load bearing the moment a product composes its own interface at runtime. A human designer reading a documentation page can infer that a destructive action should not sit beside a primary action. A composition engine cannot infer anything that is not encoded.
Encoding what documentation currently implies
Most enterprise design systems document appearance thoroughly and behaviour loosely. A component page will specify padding, states and colour tokens, and describe usage in prose. Prose is the part that does not survive automation.
What has to become explicit is the set of constraints a person currently applies from judgment. Which components can contain which. How many primary actions a region may hold. Which components require a label and which may not be used without one. What the system does when a container is too narrow for its contents. Which pairings are forbidden rather than merely discouraged.
Written down, these read as unremarkable. Left implicit, they are the difference between a generated layout that works and one that is subtly wrong in a way nobody catches until a customer finds it.
Grading the system before turning it on
Nielsen Norman Group's six-dimension maturity framework is a useful pre-flight here, and the two dimensions that decide readiness are not the ones teams usually prioritise. Components and documentation are necessary and not sufficient. Tooling and governance are what determine whether the system can be trusted to assemble itself.
Tooling matters because a generated interface has to be built from the real components rather than from copies of them. If product teams have forked variants, a composition engine will assemble a product from the forks.
Governance matters because a contract with no owner drifts. Someone has to decide what happens when a new pattern is needed, and the answer has to be faster than building around the system.
A human designer can infer that a destructive action should not sit beside a primary one. A composition engine cannot infer anything that is not encoded.
BrilliantUX editorial principle
Starting where the risk is low
The sensible first surface is one where the content varies and the stakes do not. Dashboards assembled from a user's own selections, report layouts, and settings pages built from a permission set are all reasonable places to test whether the contract holds.
The surfaces to leave alone until the rules have been proven are the ones with irreversible actions in them. A generated layout that puts a delete control somewhere unexpected is a different class of problem from a generated dashboard with an odd column order.
Huei-Hsin Wang, Design-System Maturity: A 6-Dimension Framework, Nielsen Norman Group, 10 July 2026, on the tooling and governance dimensions.


