The Gap Between Users and Systems (and Why It Still Exists)
Picture it: You’ve spent weeks and weeks building a new observability stack. Everything is in there: metrics from servers, traces from various applications, details about APIs, synthetic transactions, even NetFlow. You’ve reached monitoring nirvana – everything is in there and it looks beautiful. You present it to the management, the application owners, the other teams, and… crickets. Until at last, someone finally says it the quiet part out loud: “But how does this help me go my job?” Cue the floodgates.
This isn’t a training problem – your users don’t need to know the ins and outs of the monitoring solution. It’s a Layer 8 problem – you didn’t account for the jump between application and users.
In a nutshell, the system works, and yet the users aren’t wrong. The two still don’t meet. It’s not a new problem, but it’s persistent enough that teams start treating it like weather — something you deal with, not something you fix.
The gap isn’t caused by complexity. It’s caused by mismatched mental models. A system is built around its internal logic; a user approaches it with their own logic. It’s a matter of perspective and you – as the owner of the solution – didn’t think about your audience.
The Delta
Most systems are designed from the inside out. Architecture, constraints, data flows, operational realities — all of it makes perfect sense to the people who built it. But users don’t think in those terms. They think in things like:
- goals
- risks
- time
- confidence
- familiarity
If the system doesn’t meet them where they are, they’ll invent their own interpretation of how it works. And once that interpretation sets, it’s damn near impossible to remove it.
This is why users build mental models faster than teams expect. They don’t wait for documentation or onboarding. They touch the system, make a few assumptions, and those assumptions become the framework they use to navigate everything that follows. If the system doesn’t actively shape that model, the user will fill in the blanks themselves. Sometimes they guess right. Often they don’t.
The increasing volume of signals makes this worse when they’re inherently designed for machines instead of humans. Logs, metrics, events, alerts — they’re all technically correct (the very best kind of correct), but they don’t answer the questions users actually have.
- “Am I doing this right?”
- “Did the system respond the way I expected?”
- “What matters here?”
- “What can I safely ignore?”
When a system doesn’t reinforce the right mental model, users fall back to guesswork, and the gap widens.
This is the part that keeps repeating across products, platforms, and teams. The gap isn’t about complexity. It’s about translation. Systems don’t become intuitive over time; they become interpreted. If you don’t design the human layer intentionally, users will create their own version of the system, and they’ll defend it because it’s the only version that makes sense to them.
Translation, not Training
The real reason the gap persists is simple: translation is treated as a post‑launch activity. Something you do after the system is “done.” But translation isn’t documentation. It’s not marketing. It’s not onboarding. Translation is a design discipline. It’s the act of shaping how people understand the system so their mental model matches the system’s actual model.
In my experience, it can be crafted two ways:
- The solution itself does an excellent job in providing clear understanding of what it’s presenting
- It’s your responsibility to customize views/charts/tables/etc. to tell the story that’s important to the consumers of the solution.
When translation is optional, the gap between knowing and understanding becomes inevitable. Users invent their own story. Monitoring teams fight user behavior instead of shaping it. Adoption stalls. Support spikes. Leadership questions the system’s value. And the same gap reappears in every new feature, no matter how well‑intentioned the design.
The Way Forward
For a solutions provider, closing the gap requires treating translation as part of the system itself. Build with a narrative baked in. Design signals that reinforce the right mental model. Create demos that reveal the system’s shape instead of hiding it behind features. Teach users how to think, not just what to click. When you do that, the gap doesn’t just shrink — it becomes a competitive advantage.
