Opinion
4 min read
Vincent co-founded November Five and created MX™, the memory-first design method the team applies across client work. He speaks on brand experience and customer memory at conferences including MWC Barcelona.
With GenUI you design the pieces and the rules, and the service builds the interface for each customer in the moment, so the classic meeting where finished screens get approved stops working.
What you approve instead is the range of possible outputs: the information the experience may use, the actions it may take, the components it may assemble from, what it must always say, what it may never say, and what it does when it is not sure.
QA, compliance, brand and accountability all change. Testing checks that the system stays inside the rules across many real situations, legal signs off permitted claims and tone, brand guidelines become technical constraints, and a named person can pause the service without waiting for a release.
The design team becomes an orchestration team. It sees more screens than before but stops designing them, and instead runs the service against real situations and reads what it did.
You know you have made the shift when the design review stops being the meeting where work gets approved and becomes the meeting where someone asks what the service did last week that nobody expected.
You know the meeting. Screens on the wall or on a shared screen, the team walking through the flow, someone from marketing asking about the headline, someone from legal asking about the small print, and at the end a decision: yes, build this. Every company I work with has a version of that meeting. Most have several, in a fixed order, with named approvers.
That meeting works because whatever gets approved in the room is what the customer sees, in that order, for the next two years. Everything that could appear was in the Figma file.
That part is ending, because of generative interfaces.
With GenUI, you design the pieces and the rules. The service builds the interface for the customer in the moment, out of those pieces. Nobody designed it in advance.
If this is the first you are hearing of GenUI or Generative Interfaces, I wrote a separate piece on it and where they are worth it: read it here.
So, what experience do you approve?
Instead of approving outputs, you approve the range of possible outputs.
Which information the experience may use, which actions it may take, which components it may assemble from. What it must always say and what it may never say. What it does when it is not sure enough to act.
That is harder to sign off than screens. A screen you can judge by looking at it. A boundary you have to reason about, because you are approving a set of answers you will never individually experience yourself.
The useful questions turn out not to be about screens at all. They are about the customer's situation. Can the customer express their intent. Do they want to do it in their own words, or do they need to recognise it from something you show them? Does anything have to stay visible while they decide? And whatever it decides to show, what must the customer always be able to see?
What comes out of those questions is not a design. It is more of a boundary: here, the service may compose its own answer. There, it may not. That is the thing that gets signed off.
What else is going to be different?
Most of what breaks here is habit. We'll have to rethink some of the practices that were sensible for years. Let's walk through a few.
QA. You cannot test every path when the paths are assembled at the moment of use. Testing moves from "does this screen do what the spec says" to "does the system stay inside the rules across a large sample of real situations". That is a different discipline with different people in it, and most test plans have no place to put it.
Then compliance. Legal approved something. What, exactly? Not a page, because the page is different every time. They approved a set of permitted claims, a tone, a list of things that must appear whenever money or a contract is mentioned. Somebody has to write that down in a form legal can sign, and almost nobody has.
Brand consistency is the one people underestimate. When the copy is assembled rather than written, who owns the voice? Your brand guidelines are now a technical input, not a PDF. If they cannot be expressed as constraints a system can hold to, they do not apply any more.
Accountability is the one that stalls programmes. When the service tells a customer something wrong, who is responsible? Today the chain is clear because a person approved the screen. Tomorrow a person approved the rules under which that screen was generated. That is a real form of responsibility, but not one your current escalation path recognises. It also needs a name attached to switching it off. If the service behaves differently than the team expected in week three, someone should be able to pause that behaviour without waiting for a release.
The design team becomes an orchestration team
The work moves upstream, and it gets busier. A team like this sees more screens than it ever did, not fewer. It just stops designing them. You set the components, the rules and the boundaries, then run the service against real situations and read what comes back. Where did it overstep? Where did it hold back when it should have acted? Which combination produced something nobody would have signed?
None of this is a smaller job, and it changes for everyone. Hardest for the teams who were judged on how many screens they shipped.
It also takes away the trade-offs behind every flow you have ever built. You used to design a handful of flows for millions of people. Now you can stop designing for the average and fit the experience to each customer, each intent, and each context.
You will know you have made the shift when the design review stops being the meeting where the work gets approved, and becomes the meeting where somebody asks what the service did last week that nobody expected.
