If the model builds the screen at the moment someone needs it, what is the designer doing there?
Nobody asks that at a GenUI kickoff. I think it’s because everyone already has a quiet answer, and the quiet answer is “less.” Design the components once, hand them over, and the system takes it from there. The designer made the Lego. The model plays with it.
I believed a version of that too. Then I spent most of this year designing generative pages for ten different industries, and the job didn’t get smaller. It moved somewhere I wasn’t looking.
The first page felt like design. The fifth didn’t.
The first one was a bank. It felt like normal work: a hero, a card recommendation, a loan flow, the spacing I’d argue about with anyone. Comps, a review, a build. Fine.
By the third one, a travel brand, I noticed I’d stopped drawing screens. I was drawing the same six parts and writing sentences next to them. By the fifth, retail, the sentences were the work and the screens were just proof the sentences held.
Things like:
- A product never appears without its price.
- Whatever the person typed stays on screen until it’s been answered.
- On a phone, three cards. Never four.
- A remembered preference gets shown as a fact, not a suggestion. “Window seat, like last time.” Not “Would you like a window seat?”
- If the model isn’t sure which of two things you meant, it shows both, small, and asks. It doesn’t pick.
None of that is a screen. And every one of those lines was a place where taste used to be a decision I made once, on one comp, in one meeting. Now the decision had to hold on a thousand screens I’d never see, assembled for people I’d never meet, at two in the morning.
That turned out to be the job. Honestly it’s most of what the job ever was, just written down.
Not a style guide
I keep saying “rules,” which makes this sound like a style guide, and it isn’t one. A style guide says what things look like. These say what’s allowed to happen.
The closest thing I can compare it to is a building code, and I don’t mean that as a metaphor about rigor. I mean the actual shape of the document. A building code doesn’t draw your house. It says a stair riser can’t be taller than this, a bedroom needs a window you can climb out of, a railing goes here if the drop is more than that. Then an architect draws a thousand different houses inside those lines, and none of them kill anyone.
The model is the architect that draws a thousand houses a second. Somebody still has to write the code it draws inside. And that somebody has to have been in a lot of houses.
Where the taste actually lives
Andrew King wrote a piece this week about GenUI latency that I think is secretly about design. His team’s system was slow, and the fix wasn’t a faster model. It was noticing that “most of the work was deciding,” and moving the deciding to a small fast model that answers closed questions, so the big model only writes when there’s something to write. Fifty-four seconds down to under four.
From the design side that sentence lands differently. Most of the work was deciding: which component, how many, in what order, what gets emphasized, what gets hidden. That is the design job, described by an engineer who was optimizing for speed and arrived at the same place.
Because those closed questions don’t write themselves. Someone has to know that a returning customer’s cart should lead with what they left behind and not with the sale. Someone has to know that on a crew tablet in a restaurant kitchen, the order number is the headline and the customer’s name is furniture, and that on the customer’s phone it’s the reverse. Someone has to have watched a person squint at a boarding pass to know which of the eleven things on it they were actually looking for.
That knowledge used to get spent on one screen at a time. Now it gets written once, as a question the system can answer in a few hundred milliseconds, and the same knowledge carries a lot further.
The catalog comes with instructions
The word everyone uses for the approved set of components is “catalog,” and I’ve come around to it, as long as we’re clear that a catalog is more than the parts.
Go back to the Lego. A pile of bricks lets you build anything, and most of what you build is a mess. The box worth buying comes with an instruction booklet, and the booklet is where the design lives. “Product” and “price” are both bricks in the catalog. The instructions say a product never appears without its price, and the reason isn’t aesthetic. A person who sees a product with no price assumes something is being hidden from them, and you’ve just spent trust you didn’t mean to spend.
So when I hand a catalog to a system now, the components are maybe a third of it. The rest is instructions: what can sit next to what, what has to come first, what’s never allowed on the same screen, what a component means when it shows up alone versus in a row. The engineers on the other side turn those instructions into validators, and I’ve stopped thinking of validators as an engineering thing. They’re the closest thing this field has to a designer’s signature.
To be fair, some of the screen is still the screen
I don’t want to oversell the shift. Checkout is still hand-built. Legal wording is still hand-built. Core navigation is still hand-built. Anything where being surprised is worse than being served stays exactly as designed, pixel for pixel, and the generative parts live around it. If you’ve ever tried to explain to a compliance team why a screen “might” look a certain way, you already know why.
And I’ve shipped the other kind of rule too, the lazy kind. “Use the brand blue.” “Cards have 16 pixels of padding.” Those aren’t wrong. They’re just the part of the job that was always going to be automated, and a designer whose rulebook is only that is going to have a short year.
What this does to a design team
I think the shape of the team changes more than the size. A generative product still needs someone who can draw, because the catalog has to come from somewhere and the hand-built parts still need a hand. But the person who matters most is the one who can look at a screen the system produced, see what’s wrong with it, and write the reason down in a sentence a validator could be built from, rather than “it feels off.”
That’s a different skill than making a beautiful comp, and it’s a skill most of the good designers I know already have and have never been asked to write down. They’ve been carrying it as instinct. GenUI is the first technology that pays you for the instinct directly, in a form that runs.
What’s left to design turns out to be the part that was always the job. The screen was how the decisions got delivered. Now the decisions get delivered on their own, and the screens are made from them.