Static interfaces have a shape. You can sketch it on a napkin, put it in Figma, hand it to engineering, and what ships looks more or less like what you drew. The interface is the artifact. That mental model has been reliable for thirty years.
Generative interfaces don't work that way, and most designers haven't fully internalized what that means for the work.
Here's the actual difference: a static interface renders a pre-defined shape at runtime. A generative interface negotiates its shape at runtime. That is not a subtle distinction. It changes the nature of the design problem.
When I look at the Shapes of AI pattern library or dig through Microsoft HAX guidelines, the same tension surfaces in every pattern. The interface can't be fully known in advance. The output is co-produced, which means the layout isn't a layout in any traditional sense. It's a probability space. You're not designing a screen, you're designing the boundary of what can emerge.
Think about a form versus a chat thread. A form has fields. You know how many, what type, what order. The user fills them in and submits. The interaction surface is fixed and the designer fully owns it. A chat thread with an AI behind it has none of that predictability. The response might be two sentences or twelve paragraphs. It might include a table, a list, or a clarifying question. The shape of the exchange is determined by what the user asks and what the model decides to surface.
This creates a category of design problems that static-interface training doesn't prepare you for.
In a static system, you design states: empty, loading, error, success. You enumerate them. In a generative system, you design for a distribution of outputs. You can't enumerate every possible response, so instead you define constraints: length guidance, format hints, response structure, failure modes. The design work shifts from drawing screens to writing the rules that govern what the interface can become.
That's a skill most senior designers already have, applied to a different layer. When you write content guidelines, you're constraining the shape of text in the interface. When you define a component API, you're constraining the range of visual configurations that component can take. Generative interface design extends that instinct into the model layer. You're authoring the conditions under which the interface assembles itself.
Where designers run into trouble is treating the AI response as a black box and designing only around it. You build a nice chat container, add some loading states, and call it done. But the response IS the interface. If it's poorly structured, too long, or inconsistent in format, no amount of container polish fixes it. The interface failed upstream, not in the UI layer.
Microsoft HAX calls this the design of AI behavior rather than the design of the AI surface. The surface is what users see. The behavior is what determines the shape of that surface at any given moment. Both require design intent.
The workflow implication is real. On a static interface project, the designer is mostly done when the Figma file is done. On a generative interface project, the designer needs to stay in the loop through prompt engineering, evaluation, and iteration on model outputs. The feedback loop is longer and messier. You're debugging something that doesn't fail cleanly.
If you want a single reframe for your next AI project: stop designing the interface and start designing the generative contract. What can it produce, what can't it produce, and what does it do when it doesn't know? Answer those questions first. The container follows.