The code works. The user is still stuck.

Everything passes the tests. The system is fast. The architecture is sound.

Then someone opens the product and asks, “What am I supposed to do here?”

That question deserves as much attention as a failing test. The software may be behaving exactly as intended, while the person using it still cannot accomplish what they came to do.

AI makes this gap worth paying closer attention to. We can generate an implementation, explore alternatives, and revise a screen with less effort. But a finished screen tells us very little about whether someone will understand it.

The product makes sense to us

Imagine a scheduling app with excellent availability logic. It handles overlapping calendars, time zones, and booking conflicts. Before someone can share a meeting link, though, it asks them to configure a resource, choose an allocation policy, and create an event schema.

Those concepts may make perfect sense inside the codebase. The person opening the app just wants someone to book a thirty-minute call.

We know why every option exists. We remember the decisions behind the labels. We have used the product hundreds of times. Familiarity can make us mistake our own understanding for something the interface communicates.

Nielsen Norman Group describes this as a gap between the builder’s and the user’s mental models: people bring expectations from previous experience, while creators have detailed knowledge of the system they built.

The interface has to bridge that gap. People should be able to make progress without first learning how we organized the software.

One person. One goal.

“Let someone book a thirty-minute call.”

System first

Scheduling configuration

Resource type

Select a resource

Allocation policy

Select a policy

Event schema

Select a schema

Save configuration

The user has to understand the system before they can start.

User goal first

Let people book a call

How long?

30 minutes

Which days?

Monday to Friday

What times?

9:00 am – 5:00 pm

Create booking link

Familiar choices lead to a clear outcome. Advanced controls can wait.

Great UX is a series of decisions

Good typography and careful spacing help. So does a beautiful interface. But much of the experience comes from less visible decisions: what appears first, which choices have sensible defaults, whether an action gives clear feedback, and how easily someone can recover from a mistake.

In the scheduling example, a better starting point might be: choose a duration, set when you are available, then create a booking link. More specialized controls can appear when someone needs them.

That takes judgment. Hiding every setting would create problems for people with complicated schedules. Showing every setting immediately creates problems for people trying to book their first call. We need to understand who is doing the task and which decisions they are ready to make.

The work includes listening to the words people use, noticing where they hesitate, and questioning whether a step needs to exist at all. Sometimes the most useful change is removing a decision we unnecessarily handed to the user.

Engineering still carries the experience

Experienced engineering remains essential. Someone has to assess the architecture, data model, permissions, failure cases, and cost of maintaining what gets built. Generated code needs to fit the actual system and its constraints.

Those decisions reach the user. A booking flow that looks effortless but loses appointments is a poor experience. So is a fast interface that exposes someone’s private calendar. Reliability, security, accessibility, and speed all shape whether people can trust and use a product.

Engineers also help make simplicity possible. A clear confirmation, a reliable undo, or a useful error message may require careful work underneath.

We need that technical judgment alongside attention to how people experience the result.

DORA’s research on user focus supports this connection. It reports that teams’ user focus influences the results associated with AI adoption. Faster feature production can amplify existing problems when the team loses sight of user needs.

A finished feature still has something to prove: can someone use it successfully?

The value of someone who asks better questions

This is where a critical thinker who understands UX remains valuable.

They can examine a convincing implementation and ask what it assumes about the person using it. They can notice that a request for another dashboard might really be a need to know whether anything requires attention. They can distinguish a useful default from an assumption that should be checked with the user.

AI can help explore these questions too. It can suggest alternatives, identify potential confusion, and help prototype a different approach. We still need evidence from the people and circumstances the product is meant to serve.

A CHI study of 319 knowledge workers found participants describing a shift toward checking information, integrating AI output, and overseeing the result. It is self-reported research, but it points to an important kind of work: evaluating what comes back and deciding whether it belongs.

For product work, that means connecting user needs to technical choices, then checking what actually happens. An engineer, designer, founder, or product manager can develop this ability. The title matters less than the habit of examining assumptions and changing your mind when the evidence calls for it.

Watch someone try

I would start with a small exercise. Give someone who resembles your intended user a realistic task. Let them attempt it without explaining the interface first.

Notice their first move. Listen to what they expect. Pay attention when they hesitate or ask whether something worked. If they need a hint, record that too. Completing a task with help tells you something different from completing it independently.

1. 01
   Observe a real taskWatch someone try, without coaching.
2. 02
   Identify the frictionNotice where they hesitate or get lost.
3. 03
   Change one thingMake a focused change you can assess.
4. 04
   Watch againFind out whether the task became easier.

Fix the friction you observed, then try again. The useful result is that someone can finish their task, understand the outcome, and recover when something goes wrong.

I have written before about choosing something worth building. This is the next responsibility: making the solution understandable to the people who need it.

As our tools change, I want to keep asking what the person on the other side of the screen needs from us. The code working is a necessary beginning. Their successful experience is what makes the work useful.