Most bad user experiences are not actually caused by ugly interfaces, bad colors, or too many buttons. More often than not, they are caused by disorientation.

The user loses track of where they are.

Not physically, but contextually.

What tenant am I in? What account am I looking at? What does this action apply to? Did I just change something globally or locally? Am I looking at all records or only records for this account? Why did the screen suddenly change behavior?

Once users lose that mental map, the entire application starts to feel confusing, fragile, and stressful. The interface itself may still look polished, but confidence disappears the moment orientation disappears.

This is something many engineering teams underestimate because developers and users think about software differently. Developers naturally think in terms of pages, components, APIs, tabs, routes, and data structures. Users think in terms of location.

They are constantly trying to answer a much simpler question:

“Where am I?”

Once you start looking at software through that lens, it changes how you think about nearly every product decision.

Every Feature Has a Cost

This realization surfaced during a product discussion about simplifying parts of a platform I am developing. The original conversation was fairly tactical. We were reviewing mockups, discussing unnecessary columns in data grids, and debating what information actually needed to be visible.

At one point, I made a simple observation:

“Every feature costs money.”

That statement applies far beyond engineering effort. Every field, widget, chart, aggregation, and “nice to have” feature creates a cascading set of costs. There is the obvious cost of implementation, testing, and maintenance, but there is also operational complexity, cloud compute usage, AI token consumption, and perhaps most importantly, cognitive load on the user.

This is one of the biggest misconceptions in software startups. Digital features often feel free because they are not physical objects. But every feature competes against every other feature for engineering bandwidth, roadmap priority, operational simplicity, and user attention.

That changes the way feature discussions should happen.

The question is not simply:

“Would this be cool?”

The better question is:

“Does this help the user accomplish their goal?”

Because every unnecessary element on a screen introduces noise. And noise creates confusion.

Users Think in Context, Not Pages

As the discussion evolved, the conversation drifted away from columns and grids and into something much deeper: context.

We started asking questions about AI interactions inside the platform. If a user is chatting with records while inside a tenant, what exactly is the AI operating against? Is it searching all records? One account? One topic? A selected subset of records? A single record?

That led to an important realization:

Context is layered.

A useful analogy emerged during the discussion. A person can simultaneously be in the United States, in Ohio, inside a building, and inside a room. All of those statements are true at the same time, but the immediate context is the room itself.

Software behaves the same way.

If a user is viewing a specific account, they are still technically operating inside a larger tenant, within an account hierarchy, and within a broader repository of records. But their active working context is that account.

That distinction matters because users continuously build mental models while navigating software. They form expectations around scope, navigation, search behavior, filtering, AI responses, tabs, breadcrumbs, and actions.

When software violates those expectations, users notice immediately, even if they cannot clearly articulate why the experience suddenly feels wrong.

Why Inconsistent UX Creates Anxiety

One of the fastest ways to break a user’s mental model is inconsistent interaction design.

If every page behaves differently, users are forced to constantly relearn the system. That repeated friction creates anxiety because the application stops feeling predictable.

During the discussion, I joked:

“It’s like walking up expecting someone to speak English and suddenly they start speaking Vulcan.”

Even if you technically understand what is happening, your brain still experiences friction because your expectations were violated.

That is exactly what inconsistent UX patterns do.

A tab that usually represents navigation suddenly changes filters instead. A breadcrumb unexpectedly resets search state. A detail page still displays a generic title like “Accounts” even though the user is now deep inside a specific account view.

At that point, the software’s context indicators are effectively lying to the user.

These details may sound subtle from an engineering perspective, but they are not subtle to users. Users are continuously trying to understand what they are looking at, what will happen if they click something, how to go back, and whether an action is global or local.

Well-designed software answers those questions continuously and almost invisibly.

Context Indicators vs. Context Controls

An important distinction emerged from these discussions: the difference between context indicators and context controls.

A context indicator tells the user where they are.

Examples include page titles, breadcrumbs, selected account names, and active tenant labels. These elements communicate a simple message:

“You are here.”

A context control, on the other hand, allows the user to change where they are.

Selecting a tenant, clicking an account, navigating through breadcrumbs, or changing scope inside an AI chat experience all fundamentally alter user context.

Not every interaction should be treated this way.

Expanding a row, collapsing a section, or sorting a table changes presentation, not context.

That distinction becomes critically important in enterprise software because users subconsciously build expectations around which interactions move them somewhere new and which interactions merely reorganize information already in front of them.

When software accidentally blurs the line between changing context and changing presentation, users become disoriented very quickly.

AI Makes Context Even More Important

Ironically, AI systems amplify this problem rather than solve it.

When users interact with AI inside enterprise software, they need to understand exactly what the system is operating against. What repository is being queried? What filters are active? What scope is currently selected? What information does the AI “know”?

Without those answers, AI starts to feel random.

And unpredictable software destroys trust.

This becomes especially important in systems dealing with records, policies, financial data, operational data, or regulated information. If users cannot clearly understand the AI’s active scope, confidence disappears almost immediately.

The challenge is not just making AI intelligent. It is making AI understandable.

Conclusion

I wrote this because it is something I have been actively trying to teach while designing enterprise software platforms. Engineering teams naturally focus on APIs, databases, front-end frameworks, infrastructure, and AI models. Business analysts naturally focus on the content, what’s on the screen, the text, the images, etc. Those things, while relevant, do not ground us in context — which, ultimately, is the source of every design.

But if users constantly lose their sense of context, the entire application feels incoherent no matter how technically sophisticated it may be underneath.

The most important lesson is this:

Users are building a mental map of your software every second they use it. Every title, breadcrumb, tab, navigation element, and interaction either strengthens that map or damages it.

Good UX is not simply about making software look clean.

Good UX is about helping users continuously answer one question:

“Where am I?”

Because once users lose that answer, they lose confidence in the system itself.