Bigger Than the Screen

Developer experience is a kind of design work most designers never claim.

Design
Developer Experience
Collaboration
Engineering
Bigger Than the Screen

We've gotten good at naming experiences. Customer experience. Employee experience. Patient experience. Learner experience. Each one pulls a specific kind of person out of the generic "user" and insists they deserve a discipline of their own. Developer experience belongs on that list — but it's the odd one out. In every other case, the person on the receiving end consumes something: a service, a workplace, a course, a diagnosis. The developer doesn't consume the product. They use it to build another one. DX is the only experience discipline where the user's output is more software.

That one difference reframes everything. UX optimizes the path to using value. DX optimizes the path to creating it.

DX was already being framed through UX in 2011. In a UX Magazine article, Jeremiah Lee Cohick — a software developer with a design and product background — described developers as a distinct kind of platform user. A formal academic definition followed in 2012. So a product designer looking hard at developer experience isn’t crossing into someone else’s territory. They’re working in a space that sits between design, product, and engineering.

The catch is that this user is unlike any other a designer works with. You can design for a patient without having been sick. But you can also design a flow your system is incapable of producing — and may not notice you've done it unless you understand how that system works. DX is the rare experience discipline where empathy isn't enough; you have to share some of the user's literacy.

That makes it less a new domain for designers than a new competency. You stop designing screens and start designing the production interface: the whole surface between a person's intent and a working system. The API contract. The component. The empty state nobody specified. The handoff. The decision that never got written down.

DX is almost always told as an engineering story, and most of it is one — build times, CI, tooling, deployment. But a real part of developer experience is decided before the first line of code: in fuzzy product decisions, states left unhandled, components reinvented instead of reused, and the quiet gap between what a design meant and what got built. That part has a designer's fingerprints all over it. Its impact can be measured — imperfectly, but more concretely than we usually do.

What the production interface actually is

Once you accept that the developer is a builder, the object of design changes.

In ordinary product work, "interface" means screens, flows, states, hierarchy, microcopy. In developer experience it's wider. The production interface is everything a developer touches on the way from intent to working software. Some of it faces outward: API contracts, SDKs, error messages, the sandbox, the developer portal — the familiar version, where a developer outside your company builds on your product as a platform.

But there's an internal version, and every product team has one, even a team that never ships a developer tool. Internal DX is shaped by the handoff, the spec, the component contract, the acceptance criterion, the design system, and the decision that only ever got said out loud in a call. That internal layer is where product designers have the most direct impact, yet rarely treat it as part of the design surface.

A missing empty state. Unclear permission logic. A "small UI change" that turns into an architectural detour because nobody discussed the constraint early enough. None of it looks like a DX problem at first glance. Developers feel all of it as friction — as a reason to stop and ask, implement the wrong thing, or work around a decision that was never made explicit.

These problems surface during engineering. But they're born earlier, in the gap between product intent and implementation. That gap is touched by everyone and owned by no one. We rarely treat it as an interface that can be designed. It can be.

This is why a design system is a DX surface, not just a consistency tool. Aligned with code and documented for implementation, it's one of the strongest production interfaces a designer owns. Drifted from code, it becomes one more translation layer that looks mature and quietly taxes everyone downstream.

Documentation built in code rather than represented as a mock can become the working artifact itself. Some of the most important production surfaces never have a frame in a design file at all.

Where a designer actually moves DX

We can't touch build times, CI, or deployment pipelines. Most of DX is engineering, and pretending otherwise is how designers lose the room. But Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler offer a useful frame: developer experience can be understood through cognitive load, feedback loops, and flow.

  • Cognitive load. A developer's attention should go to architecture, performance, and security — not to guessing which state is missing, whether a pattern is reusable, or whether the mock reflects a real constraint. Every behaviour left implicit becomes load. Making it explicit is design work, not administrative cleanup.

  • Feedback loops. Not only tests and compile times. How fast can a developer get an answer from design? Was engineering in the room before the design was called final? Do decisions get written down, or do they live in a Slack thread three weeks deep?

  • Flow. A ticket marked "ready for dev" but full of open questions isn't ready; it's a deferred meeting. A design that shifts mid-build without a clear reason is rework. Protecting flow is a design responsibility too.

Sometimes the whole problem is a single recurring question: which value do I use here — the example, or my own? It reads as trivial. But if it comes up during every integration, the interface is failing to answer something developers need to know. Removing the question is design.

The cost of literacy

That requirement for shared literacy has a cost.

Your own engineers will often move through a developer-facing flow quickly; years of context do that. It's easy to read their speed as the design's clarity. The same flow exposes gaps within minutes when developers outside the company try it. Same task, different literacy.

To design the production interface, you need enough of the developer's own fluency to avoid designing blind spots: enough to know what data exists before you build a screen around data that doesn't, enough to tell a real constraint from an old habit, enough to see when a small visual change is a large architectural one. Not to replace engineering judgment — to stop manufacturing problems engineering has to discover later.

It cuts the other way, too. Literacy doesn't make a designer less user-centered; it makes them better at defending the user inside a technical system. You stop accepting constraints blindly and start negotiating them — protecting user value while understanding what it actually costs to build.

Measure it by friction, not output

If design shapes DX, the impact should show up somewhere — just not in output. Screens shipped and comments resolved say nothing about whether the work became clearer to build.

The SPACE framework makes the general point: you can't reduce developer productivity to a single number. Design's contribution reads the same way — as friction removed, not assets delivered:

  • Fewer clarification questions and blocked tickets after handoff.

  • Fewer design-related bugs and missing states discovered mid-build.

  • Less rework once implementation starts.

  • Higher component reuse and a shorter path from "ready for dev" to merged.

None of these is clean on its own, and attribution is genuinely hard — most of the time you can't isolate design's line in the result. The point isn't a dashboard. It's a different question at handoff. Not "did design deliver the assets," but "did design make this clearer, safer, and more predictable to build."

Claim the gap

Developer experience is mostly enabled by engineering. But its quality depends on more than engineering — on how well a company turns intent into a working system. That process runs on code, and also on decisions, artifacts, constraints, and the collaboration around them. Designers shape it whether they name it or not. Every unclear state and undocumented behaviour becomes a question, a workaround, a bug, or a delay in someone else's day.

The interface is bigger than the screen. The work doesn't end in Figma. The space between what a design means and what gets built is already part of the experience.

We may not own the whole developer workflow, but we do own the decisions we send into it.

Where this comes from