It’s Not Great UX If It’s Great at the Wrong Job

“This product has great UX” is not the compliment you think it is.

It’s an incomplete sentence pretending to be a conclusion.

Great at what? For whom? In what situation? Under what stakes? Compared to which alternative? Helping them make what kind of progress?

“Experience quality” isn’t a universal property like screen brightness. It’s a relationship: a product, hired for a job, in a context, with constraints. If the product is beautifully executed while serving the wrong job (or the right job for the wrong segment), the UX isn’t great.

It’s just polished and pretty.

The most dangerous kind of design praise

Teams love to hear things like “the flow is so smooth,” “it feels intuitive,” “the UI is gorgeous,” “it’s delightfully simple.” All of those can be true while the product is getting fired.

Users don’t hire a flow. They hire progress.

And progress isn’t “I made it to the end of the funnel.” Progress is relief, certainty, speed, safety, status, confidence. It’s the feeling that the thing you came here to do is actually moving forward.

Underneath every UX debate are two different questions:

1. Did we pick the right job to serve?
2. Did we design the experience of doing that job well?

Most critique lives on #2. But you can execute beautifully and still fail if you executed the wrong job. “Great UX” has to mean job‑fit and job‑execution together. Without the first, the second is theater.

You can see this mismatch everywhere once you start looking at Jobs instead of screens.

The “beautiful browsing” trap

Many recipe and meal‑planning tools are designed as inspiration engines: big editorial imagery, endless carousels, rich filters, swipey discovery. On a lazy Sunday when the job is “get ideas and feel inspired,” that’s perfect UX.

Put the same person in a different job: it’s a weeknight, they’re tired, they have 20 minutes and whatever is already in the fridge. The job is “get a dinner on the table that will actually happen with what I have.” Now:

• Every extra card is a delay.
• Every “more ideas” module is cognitive load.
• Every scroll is time they don’t have.

Nothing about the UI changed. The job and context did. “Great UX” for the browsing job is actively bad UX for the execution‑under‑constraint job.

A JTBDUX team would treat those as separate segments and give each one a different front door: “What can I cook right now?” for the execution job, inspiration feeds for the browsing job.

The “high‑control UI” trap

Analytics platforms are full of this. The tool is designed for the hands‑on analyst whose job is “explore, slice, and build custom views,” so the UX is full of knobs, filters, and dense dashboards.

For that job, it’s great. Analysts feel powerful.

But a big chunk of paying users often have a different job: “tell me if we’re okay, and where to look if we’re not.” They’re hiring analytics for delegation, not for another cockpit. To them, the same interface feels like unpaid labor.

The design is coherent. It’s just coherent for a different job.

The JTBDUX version of “great UX” there would split the jobs:

• For analysis: keep the flexible surfaces.
• For delegation: design a very different path that surfaces a small set of statuses and recommended actions, and treats “no action required” as a valid, reassuring outcome.

The “reliable directions” job

Navigation is the cleanest illustration of why job success trumps interface polish.

For the job “get me to my destination reliably,” wrong directions are a betrayal. Early Apple Maps is a textbook example: familiar gestures, clean visuals, standard UI patterns — and directions that, in many places, were simply wrong.

Under real stakes — late, lost, unfamiliar territory — the only thing that matters is whether you arrive. If you don’t, nobody cares that the map UI felt smooth. The job failed. The UX failed with it, no matter how well‑designed the controls were.

You don’t get to claim “great UX” if you can’t reliably complete the job under real conditions.

You see a more subtle version of this with personal knowledge tools like graph‑based note apps. For a small segment whose job is “build my own thinking environment,” the UX feels incredible. It fits how they think. It rewards tinkering.

For most people, the job is closer to “keep track of what I need to do and not drop important things.” They do not want to design their own system. To them, the same UX feels like overhead.

What “experience quality” has to include

If you take the Job seriously, “good UX” can’t just mean “usable and pretty.” A more honest definition is: The degree to which the product helps a specific segment make progress on a specific job, in a specific context, with as little anxiety and as much momentum as possible.

That definition forces more useful questions in design reviews:

• What job are we assuming they’re hiring us for in this moment — not “in general”?
• What’s the context around that job: time pressure, risk, social exposure, toolchain, policy?
• Are we designing for a hands‑on job (control, exploration) or a hands‑off job (delegation, reassurance)?
• Are we serving exploration when the user actually needs execution?
• Right before commitment — send, publish, approve, present — what would it take for them to feel confident enough to go through with it?

In JTBD terms, that’s jobs and forces: struggling moment, desired progress, Push, Pull, Habit, Anxiety. In JTBDUX terms, that’s what shapes the actual experience decisions: which job segments you design for, what entry points they see, what defaults you set, how much friction you add or remove, how you trade off delight vs defensibility for each job.

Once you specify the job and the segment, “great UX” stops being a vibe and becomes a verifiable claim: great for whom, for what, when.