Tyler YoungSenior Director of Design

How I design with AI

I build the system that AI designs within

An agent can build a screen in minutes. Knowing whether it is the right screen still takes a person who understands the problem. I build the design systems, constraints and review loops that agents work inside, and I am accountable for what ships.

The operating loop runs in five stages. Frame the intent: define what a good result has to be true of. Generate working options: build them rather than describe them. Review in context: put running software in front of the people who know different parts of the problem. Decide together: rank, choose, and say why. Strengthen the system: fold the decision back into what everything else is generated from. Human judgment runs across all five stages rather than sitting at the end as a gate.

Human judgment runs across all five, not at the end.

Getting from an idea to something a person could actually use took weeks. Now it takes hours. I can try several directions, put them in the real interface, and come back to the team with something they can click instead of something they have to picture.

What I am responsible for has not moved.

I still have to understand the problem, decide how the thing should behave, keep the product coherent, get the right people into the decision, and notice when a good-looking answer is solving the wrong thing.

What is new is where those decisions end up. A rule I set — this state has to exist, this colour comes from the token page, this action needs a person — used to be written down and checked later by whoever built it. Now it is applied while the thing is being built. Fewer of my decisions survive as notes; more of them survive as behavior.

Frame

I begin with intent, not instructions for a picture

An agent can build a polished version of a poorly framed idea remarkably quickly. So before generating anything, I define the conditions of a good result:

  • Who is trying to accomplish what?
  • What decision should become easier?
  • What must remain true across every state?
  • What can the system do autonomously?
  • What requires confirmation or human judgment?
  • What would make the result wrong, even if it looked finished?
  • How will we evaluate the working experience?
  • IntentWho is trying to do what, and which decision should get easier
  • Required behaviorStates, transitions, permissions, failure paths
  • System constraintsThe tokens, components and patterns the work must resolve to
  • Prohibited actionsWhat the agent may not do without a person
  • Open questionsWhat the work should help us resolve
  • Evaluation criteriaHow we will judge the working experience

That is more specification than a screen drawing carries, not less — behavior, hierarchy, states, content, accessibility, system constraints, and the questions the work should help us answer.

Encode

The design system becomes part of the production environment

Every colour, type style, spacing value, radius, interaction pattern and accessibility rule should resolve to the system. If a required value or pattern does not exist, the agent should name the gap rather than quietly invent an exception.

That puts the design system somewhere new. It is no longer a document people consult or a standard applied at review — it is part of the environment the interface comes out of.

Design intent, tokens, components and behavioral rules together produce the working interface: the interface is generated inside all four rather than compared against them afterwards.

At Atheer I rebuilt an ageing system into a pipeline that worked this way. Explorations came back as working components, and approved decisions moved toward engineering as code rather than a secondhand reading of redlines.

The leverage ran in both directions:

  • Designers could explore without abandoning product coherence.
  • Engineers received behavior expressed in the implementation medium.
  • Accessibility and brand rules were present before review, not after it.
  • A new decision could strengthen the shared system instead of becoming an isolated exception.

The product and the system it was built from are both running, and the component library documents the states that prove it.

A design system this close to production decides what the product is allowed to become.

Explore

Options come back as working software

Making three versions of something is cheap now. Choosing between them is the part that still costs.

On a recent engagement I directed three approaches to the same problem and deployed each to its own URL. We evaluated actual behavior, content, responsiveness and edge cases rather than debating static approximations.

That changes the quality of the conversation. A stakeholder can try the workflow. An engineer can see a structural problem. A designer can compare hierarchy under real content. The team can discover that two people read the same requirement differently — before either reading hardens into production work.

I still read every option, rank them, and say why. That is the part of the job the tooling has not touched.

Collaborate

Running software gives the team something precise to disagree about

No specification captures everything people mean.

A designer may use a word differently from an engineer. A product manager may assume an edge case is included. An agent may satisfy the literal instruction and miss the reason behind it. Working software makes those misunderstandings observable.

The collaboration loop runs in five steps: frame the intended outcome; generate the smallest working expression of it; review it with people who understand different parts of the problem; find where the mental models diverge; then correct both the implementation and the brief and system that produced it.

None of this is a workaround for unreliable AI. Talking it through has always been how a hard product decision becomes a shared one. What is different is that the thing being discussed shows up sooner.

A stakeholder review run this way is on the site: two running builds, forty-eight notes, and the three that show where the human work actually was.

Evaluate

I read the screen for the decisions inside it

A generated screen can be clean, consistent, and still wrong.

  • IntentDoes this solve the problem we agreed to solve?
  • BehaviorDo the states, transitions, permissions and failure paths make sense?
  • SystemDoes this strengthen the product’s patterns, or erode them?
  • ContentDoes the interface explain what happened and what to do next?
  • AccessibilityCan people perceive, understand and operate it in real conditions?
  • ImplementationIs the behavior credible in the actual product environment?

This is where design leadership stays close to the work. I do not need to draw every artifact by hand to hold a bar, but I do need to recognise where the work is coherent, where it is merely plausible, and where the system underneath it needs to improve.

Boundaries

Autonomy needs an explicit perimeter

An agent can run checks, implement approved patterns, generate options inside the system, and propose an addition when no pattern fits. The limits worth stating are not the obvious operational ones — they are the three places where an agent would otherwise make a design decision by default.

  • Invent design-system valuesIf the system has no approved value, the agent names the gap. It does not fill it.
  • Resolve product ambiguityAn assumption made at speed is still an assumption, and it arrives looking finished.
  • Treat valid as approvedPassing every check is not the same as being the right thing to build.

None of this assumes the agent behaves badly. It exists because speed magnifies misunderstandings. The goal is not maximum autonomy; it is useful autonomy, with visible consequences and clear accountability.

I automate execution more readily than I automate judgment.

Accountability

Whoever approves it owns it

Anything that ships still belongs to people.

Whoever approves the work needs to understand what changed, which checks ran, where uncertainty remains, and what could be affected. A human name on a change should mean informed responsibility, not a ritual click after an automated process.

The same idea runs through my product work. InAlucify I designed the surfaces that expose coverage gaps, downstream impact, stale analysis, and the places where human interpretation is still required. I hold my own work to the same rule: automation should make its output inspectable and its limits explicit.

I do not ask whether an agent is trustworthy in the abstract. I ask whether this result is grounded, reviewable, and safe to advance.

Leadership

AI changes the leverage of a design leader

Design leadership used to scale mostly through capacity: how much a team could research, draw, review, document and shepherd through implementation. Capacity still matters, but it is no longer the only constraint.

Increasingly the leverage is in the environment the work comes out of:

  • The clarity of the product intent
  • The strength of the design system
  • The quality of the evaluation criteria
  • The boundaries around autonomous action
  • The speed and honesty of the review loop
  • The team’s ability to turn individual learning into shared infrastructure

That lets me stay close to consequential decisions without becoming the production bottleneck, and lets a team explore more widely while holding one standard.

The opportunity is not to replace designers with agents. It is to remove avoidable production friction so designers spend more time understanding problems, comparing possibilities, resolving ambiguity, and improving the systems that shape the next piece of work.

My leverage is the system the work comes out of, not how much work comes out of it.

Closing

What changed is the material

I am not presenting myself as a frontend engineer, and I do not think every designer needs to become one. I am describing a change in the material of design.

A decision about behavior can be built the same day it is made. A design system can decide what an agent is allowed to produce instead of being checked afterwards. Options can be tried instead of imagined. A misunderstanding can surface in an afternoon rather than in a sprint review. And less gets lost between the people who decide something and the people who build it.

The tools are new. What the work has to be has not moved: useful, coherent, accessible, explainable, and right for the people it serves.