What makes a good product designer now?

Key idea 1 of 6

The building got fast, so the judgment moved upstream

For most of my career, design ended at the handoff. I drew the blueprint, someone else built it, and months later we found out what survived the translation. The work ran as a relay: research, design, a specification, engineering, QA, each leg waiting on the one before.

That relay is coming apart. I build what I design now, with coding agents, and a working version of an idea takes days instead of a quarter. An agent will build every branch it’s asked for, and a few it wasn’t.

1. 01The systemwhat each part means, the rules, the checks
2. 02People and agents buildfrom the system, in days
3. 03The checksevery change has to pass them
4. 04A person decideswhat the checks can’t, and the system keeps the answer

When building is cheap, the expensive mistakes move. A badly drawn screen used to cost one screen. A badly written rule now repeats across every screen an agent touches. A well-written one improves all of them, without anyone inspecting a pixel.

So the designer’s leverage moved upstream, into what the building is made from:

• The parts, and what each one means
• The rules a builder reads before it starts
• The checks every change has to pass
• The decisions only a person should make

Most of that list isn’t new. Design systems, standards and review are what I spent thirteen years building inside enterprise programs. What’s new is who reads them. The next builder on the team may not be a person.

Key idea 2 of 6

A design system now has to explain itself to builders who can’t ask

A design system used to be something people learned. A new designer read the documentation, picked up the reasons from the people around them, and made a considered call. An agent does none of that. It builds from what’s written down, faster than any review queue can keep up with.

Netflix’s design systems team has given one of the clearest public accounts of what that changes. Ben Lister and Szymon Chudy (opens in a new tab) describe Hawkins Professional, Netflix’s enterprise design system, as having AI agents among its users now, and warn that “left unchecked, AI can quietly drift from the system’s rules.” So the team builds guardrails. Chudy calls the result a paved road (opens in a new tab), and ships skills, MCP servers and context with the system so agents can use it.

Atlassian’s design system team (opens in a new tab) describes the same shift as building a context engine: an MCP server, structured context files and skills, so an agent builds with the system rather than around it.

Molly Misek’s work at Justworks (opens in a new tab) makes the same move with words. Her team sorted everything the product says to customers into tasks, things to do, and notices, things to know, then gave each type a trigger, a priority, an expiration and a rule for how long it persists. That’s meaning, written down where a system can act on it.

My own example is a red. In Agent Review, my prototype for supervising coding agents, the same red marks “Payment failed” on one screen and a replaced plan on another. Lint passes. Accessibility passes. Whether people rely on that red to spot a problem at renewal isn’t in the code, so no check can say which fix is right.

1. 01Lookscolor, type, space: what most systems write down
2. 02Meanswhat it signals, where the two reds part
3. 03Behavesits states, its errors, its motion
4. 04Applieswhere it holds and where it doesn’t
5. 05Ownerwho may change it, and who approves

A component that only says how it looks will be used everywhere it looks right. One that also says what it means, how it behaves and where it doesn’t apply can be used correctly by a builder who has never met the team.

Key idea 3 of 6

Build to find out, not to produce more

When the distance between an idea and a working result collapses, there are two ways to spend the time it saves. One is to make more. The other is to learn faster. Only the second is the job.

Ryan Brownlow’s account of designing Korl (opens in a new tab), an AI product for building sales presentations, is a good picture of the second. He prototyped with Figma’s MCP server and Claude Code to test with users, and testing showed that people’s hand edits broke the presentation’s sync with its data. The answer was a variable for every piece of tracked data, one source of truth, not better generation.

Speed also makes it easy to skip the part that tells you what to build. Julia D’Amico, Justworks’ VP of Product (opens in a new tab), wrote this year about building much of an applicant tracking system with agents. The AI’s first drafts were generic, and conversations with real customers surfaced what it had missed.

I learned the same thing on my own projects. Lucy Learns, a dog-training app I built for my household, shipped with voice commands, so the handler could say “next step” with a leash in one hand. A couple of real sessions took them out. Someone speaking brightly at a phone is using the cue voice, and the dog hears every word as meant for her. The AI I built it with didn’t flag that. Using it did.

1. 01A questionthe thing that makes the next step risky
2. 02A working versionreal code, in days rather than months
3. 03Real usethe people who would use it, on real inputs
4. 04Evidencewhat held, and what broke
5. 05A callbuild it, kill it or park it

A working prototype is a question, asked in a form people can answer. It should end in a call, made on what the people using it did rather than on how fast it came together.

Key idea 4 of 6

Decide what software does alone, and where a person decides

Products used to wait for people. A button was something a person pressed and a dashboard was something a person read. Now software can take the action, read the dashboard and decide whether to send the message. The interface has to cover what the system does when nobody is looking, and the line between that and what a person decides is a design decision.

Tushar Roy’s case study (opens in a new tab) of making security work measurable at Apple draws that line well. When a metric breaks its control limits, an agent drafts the analysis, with its reasoning and a confidence score. The draft stays labelled as a draft until the person accountable for that metric validates it and signs off. The machine does the first pass, and a person takes responsibility for the conclusion.

Zakiya Pope (opens in a new tab), a behavioral design leader at TIAA, describes what makes people say yes: an experience that feels clear, easy, normal, safe and worth it. Those signals can help someone start saving for retirement, or make one choice feel inevitable. When software can tune them for each person, the design work is the decision, not the screen.

Trust alone is the wrong target. Researchers at Microsoft argue for appropriate reliance (opens in a new tab) instead: people accepting a recommendation when it’s right and rejecting it when it isn’t. Explanations don’t guarantee that. In one study (opens in a new tab), they made people more likely to accept the AI’s recommendation whether it was right or not.

Agent Review sorts an agent’s work into three lanes, and a person only ever sees two of them.

1. 01Proceeds on its ownclear instructions, permission, passing checks; recorded
2. 02Needs judgmentcontext missing, or two defensible answers; a person decides
3. 03Needs approvalpast what the delegation allows; whoever owns it approves

Second Look, my dispatch prototype, draws the line from the other side. It enforces the federal hours-of-service limit before any score is figured, and nothing on the screen can argue past it. A close call between two trucks it leaves to the dispatcher, and names the trade-off.

An approve button isn’t oversight. If the person approving can’t see the evidence, the consequence and a way to say no, their yes is a formality.

Key idea 5 of 6

Quality has to hold when nobody is looking

When agents and many hands build, nobody reviews every screen. Quality has to live in checks that run on every change, and in measures that show whether the product is getting better.

GitHub’s Primer design system (opens in a new tab) shows what that looks like when the builder is an agent. Its MCP server hands an agent the components with their usage and accessibility guidelines, and also a token linter and an alt-text review. The checks ship with the system, so the agent meets them while it builds, not after.

I hold this site to the same idea. It’s plain HTML built with coding agents, and ten checks run on every merge, five of them rendering every page in a real browser: every color against its contrast floor, every type size against the scale, every token the specs name. On the SAP program, the same principle was a quality check written into the release process, across more than forty apps.

10

checks run on every merge to this site, five of them in a real browser

40+

apps under one design system and one release check on the SAP program

12

design rules a coding agent reads before it builds, in Agent Review’s experiment

A check is a design decision that keeps being made after the designer has left the room. Writing it is part of the design.

Key idea 6 of 6

It’s the job I started with, at a longer reach

I started in 2005 as a hybrid designer and developer. At the studios I worked in, designing and building weren’t separate jobs yet, so I did both, in a room where whoever shipped it sat close enough to argue with.

Then the jobs split, and I followed the work into UX and product design: thirteen years at RBA on large enterprise products for CBRE, Toro, Banner Bank and International Trucks, and, the longest engagement, building and running a UX practice inside a global enterprise. That’s where I learned that most design problems are communication problems, and that coherence at scale takes systems: shared patterns, governance, honest measurement.

1. 01Craft, 2005designing and building, one job
2. 02Systems, 2013the standards other teams built from
3. 03Agents, 2026both again, at a longer reach

This year the two halves came back together. I build with coding agents now: two products in use, three working prototypes, client work, and this site. The hardest design problem I worked on this year wasn’t any of those. It was saying what I do now, and the answer was shorter than I expected. I design the system good work comes from, I build enough of it to know it holds, and I decide, with the people who own the product, where a person stays in charge.

That gives anyone hiring a short list to ask a designer about:

• Can they say what a component means, not only how it looks?
• Have they built something real, and changed their mind because of it?
• Can they say where an AI feature should stop and ask?
• Do they write the checks, or only pass them?
• Do they still go and watch someone use the thing?