For a long time, the scarce thing in software was a well-considered, beautiful screen. That took craft and time. Design delivered it. Clients paid for it.
That thing is no longer scarce. AI produces, in minutes, a plausible, neat-looking, roughly working screen. Not always a correct screen — but a plausible one, fast, at volume.
The value of design has not disappeared. It has moved — in two directions at once. Downstream, into the behaviour of the system under the glass. Upstream, into the constraints that decide what every generated screen is allowed to become.
This is not a manifesto against AI. It is a map of where design work actually lands when generation is cheap and judgement is not.
The behaviour of the system is the product.
Take a tool that plans algorithmically. A gorgeous interface on top of an algorithm that needs twelve seconds, or that proposes a plan nobody understands, is bad UX. Full stop. You do not fix that with button positions.
The real design questions look like this:
- Latency — how fast must a proposal arrive before people distrust it?
- Confidence — when the system is unsure, do we show one answer or alternatives?
- Explainability — can a user see why something was planned this way? If not: blind obedience or endless overrides. Both fail.
- Override — what happens when a human disagrees? Is the correction absorbed, remembered, learned — or quietly thrown away?
- Conflict — what does the system do when two truths collide?
These are design decisions, an order of magnitude more important than where the button sits. And they belong to design — not as decoration after the model is trained, but as the brief for what the model is allowed to do in the world.
A user who corrects the algorithm is the feedback loop that works. Never discourage the correction — but always count it.
Many corrections? Then the interface is not the problem: the algorithm does not know something. The question is not “how do we make correcting smoother” but “what is this correction telling us?”
Zero corrections? Also an alarm. People trust blindly, or they do not dare. Both are dangerous.
That is what a KPI looks like when design owns it: not “fewer clicks”, but “what does this behaviour say about the system underneath?”
Not “the user can rebook” — but “as few rebookings as possible.”
Not “the planner can assign a tow” — but “no conflicting assignments.”
The goal usually runs against the task: the best optimisation of a task is to make it unnecessary. No optimisation loop finds that, because a loop takes the task list as given. Only a human asks whether the task should exist at all.
In the agentic era this matters twice. Agents are excellent at executing tasks you hand them. They are terrible at questioning the task list. Design’s job is to keep that question on the table — in the brief, in the acceptance criteria, in the metrics — before anyone asks a model to “just build the screen for it.”
One question sorts almost everything:
Am I making something AI could also have made — or something that decides what AI makes?
AI could also have made: a mockup, a prototype, a Figma library, a screen built with AI, a pipeline that carries Figma into Cursor. That last one is the most seductive. It feels like progress. It is a faster engine on the old way of working — it makes transport more efficient for precisely the artefact whose necessity is under discussion.
What actually decides what AI makes: the five spacing values we allow (and the nine we do not), the rule that every list has empty, loading and error states, the decision that there is one button component, the spec for no-permissions / 500 records / zero records, acceptable latency, the microcopy for the error nobody thought of, the tokens and rules an engineer’s AI reads as context.
None of this is a picture. All of it is a constraint — and constraints shape not one screen, but every screen generated after.
A mockup improves one feature. A rules file improves every feature someone builds afterwards. It compounds.
And commercially: if an engineer generates UI with AI and design delivers a mockup, that mockup was either redundant, or it diverges and someone has to hand-translate it — slower than nothing. In both cases design became a step in the process instead of a multiplier.
Working upstream reverses that. The rules go into generation, and the output is right the first time — because design defined what “right” means.
| Instead of | We deliver |
|---|---|
| A Figma file | tokens.json in the repo |
| A component library in Figma | Components in code + a rules document |
| A mockup per feature | A spec in the ticket |
| Review of a design | Review of the running build, against the rules |
| Handoff automation | Nothing — there is nothing to hand off |
A useful spec has four sections:
- Goal — what we want less of, not only what the user can do
- Flows — the steps, per job to be done
- States — empty, loading, error, no permissions, one item, five hundred items
- System behaviour — acceptable latency; what happens at low confidence; what is shown on conflict; how it explains itself; what it does with a correction
Section 4 is the one that always gets skipped — and the one that decides whether the product is good.
Review changes with it. If a finding cannot be traced to a rule, it is taste, and taste does not scale. Every manual catch is a rule that has not been written yet — the real fix is the rule, not the ticket.
Ownership gets a boundary. Design owns the system: tokens, components, patterns, states and the behavioural questions above. Engineering owns the assembly. Designers do not build production screens; engineers do not invent components or decide what the system does when it is unsure.
Fair objection: a spacing scale in a JSON file says nothing. You have to see what 24px does next to 32px. Of course.
The difference is not whether we experiment, but what the source of truth is. Old: you nudge in Figma until it feels right, and the picture is the truth. New: the token file is the truth, and the screen is a rendering of it. Same judgement, reversed dependency.
Practically: build a place where tokens are live. One route in the codebase — /system, or Storybook — with every component in every state. Change a value in tokens.json and everything shifts at once. That is where you feel it, and better than in Figma: you see what a spacing change does across forty components, not across the three you happened to draw.
Throwaway screens are a measuring instrument. Generate a realistic screen with your tokens in it, look, discard. You are testing the constraint; you are not making a design. The line is sharp: if you keep the screen and hand it to someone, you are back in the old mode.
And we never start blank. The tokens are already in what we have built — scattered and inconsistent. Pull them out, prune them, hold the product up against them. That takes a few rounds. Fine.
The rule: the experiment is an instrument, not a deliverable.
Which model you iterate against matters. Iterate against a weak, free, local model. Never against a strong one.
Reframe what the weak model is and it clicks into place: it is not a lesser designer. It is a renderer. It makes no choices — it makes your choices visible. Adjust a value, see the effect, judge. As often as you want, for free. If it looks wrong, it is wrong — and it is wrong because of you. That is the feedback you came for.
A strong model is unsuitable for that, and not because it is expensive. Because it is friendly. It compensates. Give it a spacing scale that does not work and it quietly makes something beautiful — it repairs your mistake, and you learn nothing. The judgement you meant to pass has already been passed, by the model, on your behalf. That is the delegation you want to avoid; the cost was only a symptom of it.
The weak model renders. The human feels. The strong model builds — only after the feeling has solidified into tokens and rules.
Iterate endlessly. Tweaking is not avoiding thinking — tweaking is the thinking. But do it against something dumb enough to tell you the truth.
Same logic one level up: do not hand a spec straight to a strong model to build. First ask: “list every decision you would have to take because the spec is silent, and mark which ones change the behaviour of the product.” Otherwise a capable model takes those decisions for you — well, and invisibly.
There is no limit on iterating. The brake sits on the transition: you only move to the strong model once the decisions are made — once the feeling has solidified into tokens, rules and a spec with all four sections filled in.
Generating early to find out what you think is not iteration. It is outsourcing the decision and hoping something good falls out.
That distinction is the whole difference between using agents as a force multiplier and using them as a substitute for design.
Judgement. Seeing that something looks good but does not work. Noticing the state nobody thought of. Realising a flow asks for something we already know. Understanding that a slow algorithm is a design failure, not a technical one. Asking why this task exists at all.
AI has none of that. That judgement is the entire reason design sits at the table. The only thing that changes: we no longer spend it on loose screens. We encode it in the system that produces them.
Three sentences, then:
The interface is not the product. The behaviour of the system is the product.
The output of design is no longer a screen that has to go somewhere — it is the context in which the screen comes into being.
And the feeling stays with us. Iterate against something dumb enough to tell you the truth.