The distinction between changing the environment and correcting a single output is useful. I would make the hard refusals independently testable, not just part of the style brief. In an image workflow, for example: a generated concept must not be presented as a real product screenshot; an edited product photo still needs a check that it depicts the actual item; and provenance should remain clear even when layout or presentation changes. Those checks can survive a redesigned interface.
For disclosure, I build iLoveAIImg (https://iloveaiimg.com/), which brings image generation, photo editing and background removal into one site. I am not claiming it implements ephemeral UI or MCP. It is a concrete image-task context for thinking about what an agent or a human reviewer must refuse to ship, rather than another example of faster canvas-to-code.
There’s a concept in computational fluid dynamics called a boundary condition. Before a simulation runs, you define the edges → temperature at the wall, pressure at the inlet, velocity at the outlet. You don’t simulate every molecule. You constrain the space the simulation will explore. The fluid does the rest.
As AI becomes a generative layer in design work, the role of the designer increasingly resembles this → not producing artifacts directly, but configuring the conditions under which artifacts get produced.
Great to see this expressed. A bit of a tangent, but I’ve been seeing work towards building design systems in order to “not have a designer in the room” which grossly misrepresents the role of design.
UI and components are the final 10% of the process. Designers should be collaborating with product and engineering teams from the beginning. Helping to shape the discovery and prioritization of which problems to solve and for whom. Researching user needs, product/service market fit, building prototypes to test hypothesis.
Giving tools to people who don’t know why they are solving a problem, or if it’s the right problem will never result in a high quality experience.
What’s the point of teams building static UI three times faster, if you’re building something no one needs?
To tie it back to this… designers need to own the experience, regardless of how it eventually takes shape. Why build an app or website for something that can be solved with better industrial design, or wholly taken over by an agent?
Too many designers have narrowed the scope of their involvement to pushing UI pixels, instead of actually solving a problem and designing the experience.
Wow, I’m so glad I found your work. I really feel we are on the same page. In this new agentic era, most people seem focused on build time, so it’s refreshing to find someone broadening the conversation to runtime. Thank you for putting this perspective into words.
“All of it is about the same thing, making the environment good and the intentions legible, so that what emerges there is something you would be proud to put your name on.”
In artifact-led companies, the one where artifacts consistently get created faster than the reasons they exist, designs job will be manufacturing intent.
Design will confirm the decisions that already believed. The purpose of design is to create friction, but it will be slowly selected out over time in a system that wants to move at speed.
Is there a place or a community where this conversation is happening? I'd love to join and keep talking about this with folks like yourself, experimenting, and learning from each other.
I think what you saying here is a bit what we're trying to build at TypeUI (https://www.typeui.sh/).
We use design skills for UI orientation: specifications for buttons, typography, modals, etc.
Then we use prompts for layouts: hero sections, pricing sections, navbars.
Lastly, we use a fundamentals skills that is always applied and verified in a loop.
We're still not getting to the best results, but we're getting there!
Thanks for the article, it is always a nice read.
The UI was never really the point.
The distinction between changing the environment and correcting a single output is useful. I would make the hard refusals independently testable, not just part of the style brief. In an image workflow, for example: a generated concept must not be presented as a real product screenshot; an edited product photo still needs a check that it depicts the actual item; and provenance should remain clear even when layout or presentation changes. Those checks can survive a redesigned interface.
For disclosure, I build iLoveAIImg (https://iloveaiimg.com/), which brings image generation, photo editing and background removal into one site. I am not claiming it implements ephemeral UI or MCP. It is a concrete image-task context for thinking about what an agent or a human reviewer must refuse to ship, rather than another example of faster canvas-to-code.
Yes!!! - I've been seeing this same pattern emerge curious what you think - https://substack.com/home/post/p-200660904
There’s a concept in computational fluid dynamics called a boundary condition. Before a simulation runs, you define the edges → temperature at the wall, pressure at the inlet, velocity at the outlet. You don’t simulate every molecule. You constrain the space the simulation will explore. The fluid does the rest.
As AI becomes a generative layer in design work, the role of the designer increasingly resembles this → not producing artifacts directly, but configuring the conditions under which artifacts get produced.
Great to see this expressed. A bit of a tangent, but I’ve been seeing work towards building design systems in order to “not have a designer in the room” which grossly misrepresents the role of design.
UI and components are the final 10% of the process. Designers should be collaborating with product and engineering teams from the beginning. Helping to shape the discovery and prioritization of which problems to solve and for whom. Researching user needs, product/service market fit, building prototypes to test hypothesis.
Giving tools to people who don’t know why they are solving a problem, or if it’s the right problem will never result in a high quality experience.
What’s the point of teams building static UI three times faster, if you’re building something no one needs?
To tie it back to this… designers need to own the experience, regardless of how it eventually takes shape. Why build an app or website for something that can be solved with better industrial design, or wholly taken over by an agent?
Too many designers have narrowed the scope of their involvement to pushing UI pixels, instead of actually solving a problem and designing the experience.
Thanks for sharing this Andrew, nicely put and I couldn't agree more.
Wow, I’m so glad I found your work. I really feel we are on the same page. In this new agentic era, most people seem focused on build time, so it’s refreshing to find someone broadening the conversation to runtime. Thank you for putting this perspective into words.
Thanks!
This a great article, and I checked out your designpowers, excellent stuff! Thank you for sharing
Thanks Erik!
“All of it is about the same thing, making the environment good and the intentions legible, so that what emerges there is something you would be proud to put your name on.”
In artifact-led companies, the one where artifacts consistently get created faster than the reasons they exist, designs job will be manufacturing intent.
Design will confirm the decisions that already believed. The purpose of design is to create friction, but it will be slowly selected out over time in a system that wants to move at speed.
Is there a place or a community where this conversation is happening? I'd love to join and keep talking about this with folks like yourself, experimenting, and learning from each other.