Judgment Has to Travel Without Us

Judgment Has to Travel Without Us

Why this matters

As PMs and engineers become builders, more decisions happen with no designer present. The craft right now is making design judgment portable.

Judgment Has to Travel Without Us As PMs and engineers become builders, design judgment has to work in rooms with no designer in them. Three places it has to travel, plus a shelf. As PMs and engineers become builders, more decisions happen with no designer present. The craft right now is making design judgment portable. Design judgment has to travel where designers aren't: into a design system an AI can consume, into pipeline gates and playbooks, and into principles that name the gap between today and where you're headed.

As PMs and engineers become builders, design judgment has to work in rooms with no designer in them. Three places it has to travel, plus a shelf.

Engineering has a category of tool that design doesn’t. Point it at a product and it navigates every screen, clicks everything, and surfaces the bugs before a human tester gets there. When our design leadership team met this week, the question on the table was what the design equivalent would even be. Is it an agent that walks through Figma and helps engineers understand the design more fully before they build? Is it something that checks a shipped flow against the intent? We don’t know yet (and that’s more of an exciting problem than a scary one).

The question matters because of where the work is headed. Where I think the timing lands, which I shared with the team on Monday: it’s months, not years, before we’re working radically differently than we ever have, and designers working alongside a pseudo AI engineer in Claude Code or Cursor is going to be table stakes within 3 years. When PMs and engineers become builders too, the QA bottleneck gets worse, and more decisions get made in rooms with no designer present. The state of our craft right now is figuring out how design judgment travels into those rooms.

Four books I keep pulling off the shelf for this, each one about packaging judgment so it survives a handoff.

The shelf

  1. Design Systems

    Alla Kholmatova

    Still the clearest argument that a system is a shared language before it's a component library, which is exactly what an agent needs from it.

  2. Articulating Design Decisions

    Tom Greever

    How to explain a design choice to people who don't share your training, which is the whole job when the room is engineers and an AI.

  3. Laying the Foundations

    Andrew Couldwell

    The practical book on building the system itself, documentation included, and documentation is what the MCP is reading.

  4. Org Design for Design Orgs

    Peter Merholz and Kristin Skinner

    For the question underneath all of this: where design sits in the company, and how it keeps its judgment when it sits somewhere new.

Three places I think it has to travel.

Into the design system, in a form an AI can use. One of our design leads ran an experiment this week that I’ve written up separately in this issue: they pointed a model at a Figma file over MCP and it reproduced the designs almost exactly. The follow-up question from our leadership meeting was the better takeaway: is the design system actually giving the MCP what it needs? We built our systems for humans to read, with tokens that have sensible names and components with documentation a person skims. An agent consumes them differently, and the gaps a human papers over with judgment are gaps an agent ships. Rearchitecting a design system for AI consumption is going to be a real workstream, and I’d rather start it on purpose than discover it in a bug report.

Into the pipeline, as signal. Design has to be built into the process end to end: tracked in the issue tracker next to velocity, with stage gates where design judgment is required to stay in the loop, so that the process carries the judgment on the days we can’t. One of our design leaders made a point I keep returning to: engineers may not need to design yet, but they should develop a design mindset first. Playbooks are how a mindset gets taught at scale. Our near-term work as leaders is writing them, and the goal we set is a hardened, shared process by the end of H2 next year.

Into principles that name the gap. Vision work has a way of exhausting design teams, because a vision deck for one area never shows how the change works across the whole product, and then it gets shelved. A design lead on my team proposed a framing I think is right: define the principles we practice today, define the ones we want to move toward, and make the gap the pitch. That’s easier to sell than an abstract vision, and it gives designers a clear why before anyone opens another vision file. Principles travel in a way a deck mostly doesn’t.

The platform can be gerry-rigged for a while. The judgment can’t.

Our new product and technology leader said something in an AMA this week that I’d repeat to any design team: start with the customer experience you want, then work backward to the platform, and accept that the platform might be a little gerry-rigged at first while the AI stack is still moving. Foundation-first, in their experience, rarely works. I agree with that for infrastructure. The asterisk I’d add is that the customer experience you want is a judgment, and it’s the one thing in that sentence that can’t be gerry-rigged. So the work ahead of us is to get it out of our heads and into the system, the pipeline, and the principles, before the rooms multiply.

The teachable part

Design judgment has to travel where designers aren’t: into a design system an AI can consume, into pipeline gates and playbooks, and into principles that name the gap between today and where you’re headed.

Filed under SC State of the Craft — Monthly synthesis.