You can't UX your way out of a DevEx problem

User Experience (UX) and Developer Experience (DevEx) are two terms that get used interchangeably in product discussions. I do it too. But conflating them leads to solutions that address one while quietly ignoring the other. And for any product where your users are engineers – people who build and ship software for a living – that distinction matters a lot.

UX is universal – DevEx is specific

User Experience applies to everyone. It describes the quality of any interaction between a human and a product. A checkout flow. A settings panel. A dashboard. UX asks: is this clear? Is it efficient? Can someone accomplish their goal without unnecessary friction?

These principles apply regardless of who the user is. A nurse using a hospital scheduling tool. A marketer building an email campaign. A developer configuring a deployment pipeline. The UX lens works across all of them.

DevEx is a subset. It applies specifically when the user is a technical practitioner. And what makes it distinct isn't just the audience. It's what that audience brings to the interaction.

Developers arrive with pre-formed mental models. They have strong intuitions about how systems should behave, built up over years of working with other tools, languages, and platforms. When a product's model matches theirs, it feels intuitive – almost invisible. When it doesn't, it feels awkward and wrong. That mismatch creates a kind of cognitive friction that engineers find particularly intolerable, because they're accustomed to systems that behave logically and consistently.

DevEx is not the whole story

Good developer experience is crucial. It's what earns respect from engineers, helps build trust, and keeps them engaged with your platform. But it’s not everything.

Most devtools products have multiple user personas interacting with the same system – release managers, QA engineers, IT operators, and even non-technical stakeholders who rely on dashboards, approvals, and reports. These personas have different mental models, priorities, and workflows. What feels seamless for a developer might confuse or frustrate someone who doesn’t write code every day.

That means design decisions need to balance multiple experiences:

• DevEx ensures the tool behaves predictably and efficiently for engineers.
• UX for other personas ensures that those who rely on the system for context, approvals, or monitoring can succeed without friction.

The distinction matters

Good UX means someone can find what they're looking for, complete a task, and understand what happened. Good DevEx goes further: it makes a product feel like it was built by people who understand the domain deeply, for people who take their craft seriously.

It's the difference between a tool that works and a tool that earns respect.

At Octopus Deploy, our users are deeply technical. They care about correctness of the tool – how it matches their notion of deployments. Designing for them means holding both UX and DevEx in mind at the same time, because satisfying one without the other isn't enough.

Both matter. But they require different things – and that's where it gets interesting.

What this actually requires of us

The UX/DevEx distinction has direct consequences for how design is implemented in a developer tool.

DevEx requires domain fluency, not just design skill.

Designing well for developers has a knowledge prerequisite that most UX work doesn't. A designer working on a consumer product can develop sufficient empathy through research and observation. A designer working on a developer platform needs to go further.

You need to understand what the product actually does at a technical level. How engineers think about the problem it solves. What failure modes look like in practice. What "correct" means in that domain – not just what "usable" means. Without that foundation, design decisions can look reasonable in isolation but fail in practice because they impose the wrong mental model on the user.

Great UX designers working on developer tools need a longer ramp, a closer relationship with engineering, and genuine curiosity about the technical domain. Actually building expertise in it.

DevEx requires that design and engineering share a definition of "correct."

In many product contexts, design defines what the experience should be, and engineering works out how to build it. That division of labour is fine when "correct" is primarily a question of desirability, usability, and feasibility. In developer tools, it isn’t deep enough.

Whether an abstraction is the right one, whether a workflow maps to how engineers actually think about a problem, whether a configuration model will hold up under real-world complexity – these are questions that designers and engineers need to answer together, before any interface decisions are made.

The teams most likely to produce good DevEx are not the ones where design throws a spec over the fence, and engineering implements it. They're teams where designers and engineers are building shared understanding – arguing about the right mental model, testing assumptions against real usage patterns, and arriving at solutions that are both technically sound and usable. That's a different way of working. It requires trust, proximity, and a shared language.

The takeaway

A product with poor UX loses users before they ever see what it can do. A product with poor DevEx can still lose engineers after they've seen exactly what it can do – and decided it wasn't built for people like them.

UX and DevEx go hand in hand – and the teams most likely to get both right are the ones who understand that they're related, but not the same. That's worth designing for – a genuine understanding of what each one requires.

Good UX gets engineers in the door. DevEx makes them feel at home.