Why Developer Tools Have Terrible UX

Most developer tools have bad UX.

Are the developers who build dev tools just bad at design? No, at least not necessarily. Some of the smartest engineers in the world build these tools — but the incentives behind these tools make good UX almost impossible.

Despite the talent and brainpower behind these systems, they're often:

The problem

When a tool is hard to use, we often blame the user for not reading the documentation thoroughly enough, rather than blaming the interface for failing to guide them.

But cognitive load is a zero-sum game. Every ounce of mental energy spent remembering flags or parsing dense dashboards is energy not spent solving real problems.

If you've ever used modern developer tools, you've felt this. You open something expecting to do a simple task — and instead you're met with:

Take something as simple as making an API request. That's the core job. That's why you open a tool like Postman. And yet, you're greeted with:

…everything except a clear “start here.”

You shouldn't have to search for the primary action.

Why this happens

This is structural, not accidental.

1. Builders are not representative users

The people building these tools are:

They optimize for speed once you already understand everything, rather than clarity for someone just trying to get something done.

So the UI reflects internal mental models, not user workflows.

2. “Users will figure it out”

Developer tools get a free pass.

There's an implicit assumption that:

That removes pressure to make the interface intuitive. UX becomes optional.

3. No one owns the UX

In many teams:

The result is predictable:

Developer tools end up as locally optimized features but globally inconsistent experiences.

Every feature makes sense on its own. Together, they don't.

4. Feature pressure turns tools into dumping grounds

This is the biggest one.

Every request becomes:

Nothing gets removed. Nothing gets consolidated.

Over time, the interface becomes a collection of decisions, not a product.

Real-world examples

Postman — no clear starting point

You open the app to make a request.

Instead, you're dropped into:

Where do you actually go to make a request?

The core action is buried under everything else.

Postman home screen showing AI prompt, workspace chrome, and activity feed with no prominent New Request action.
Postman’s home page shows everything…except what you need. Its competing surfaces — such as a front-and-center AI agent and an unnecessarily large “notifications” panel — makes the primary job (sending a request) easy to lose. Why not a “Quick Start” or “New Request” entry point?

Jenkins — debugging as archaeology

Setting up pipelines feels like a scavenger hunt.

When something fails:

The system gives you data, but not clarity.

AWS Console — power without hierarchy

AWS is incredibly powerful. But the console feels like dozens of unrelated tools stitched together.

Problems:

Even experienced engineers get lost. In fact, many eventually abandon the UI entirely in favor of CLI or Terraform.

These aren't necessarily easier, but at least they're more predictable.

Jira — work about work

Jira is supposed to help teams move faster.

Instead, it often feels like:

Developers spend time maintaining the system instead of doing the work.

Why this actually matters

It's easy to dismiss this as “just how dev tools are”

But the cost is real:

Dev tools are used constantly. Small inefficiencies compound massively over time.

What good looks like

Good developer tools don't try to expose everything.

They prioritize:

Most importantly, good tools optimize for getting something done — not for exposing every possibility.

Final Thoughts

Developer tools don't have a UX problem because developers don't care.

They have a UX problem because complexity is rewarded and no one is incentivized to say no.

Better UX doesn't come from adding designers; it comes from reducing scope, enforcing priorities, and designing for clarity over power.

— Dan Thoreson