Behavior Is the Point, Part 2: The Responsibility
We keep blaming users for predictable outcomes
When systems don't behave the way we want, we tend to explain it away with user failure.
- Developers "don't read the docs."
- An SDK collapses distinct error states into a single generic failure.
- A platform optimizes for the happy path and makes recovery opaque.
- Irreversible actions ship without consequences being obvious at the moment of use.
This framing is everywhere in developer tooling and infrastructure. It's convenient, and it's wrong. Because the behavior we see is not an accident. It's the most honest signal the system gives us.
Blaming users feels rational when you're close to the system. You know how it should be used. You understand the abstractions. You've internalized the constraints.
But from the outside, none of that exists.
Developers respond to what the system makes easy, not what it claims to support. They follow the happy path that documentation, defaults, dashboards, and examples quietly encode. If something is confusing, brittle, or risky, and it still gets used—that's not misuse. That's a design decision expressing itself at scale.
This is especially dangerous in software and crypto infrastructure.
At platform scale, every rough edge becomes a behavioral nudge. Every missing guardrail becomes an incentive. Every ambiguous abstraction teaches developers what the system actually values. When we dismiss behavior as user error, we don't just miss insight—we lock it in. We ship the same assumptions again, reinforce them with more tooling, and then act surprised when the same patterns repeat. The cost isn't just frustration. It's lost trust, fragile integrations, security risk, and a widening gap between how a platform is intended to work and how it actually operates in the world.
Behavior isn't something to fix after the fact. It's something the system produces.
If developers consistently reach for a workaround, that workaround is the product.
If teams build on unsupported paths, those paths are already supported—just unofficially.
If misuse is common, the system has taught it.
The work, then, is not to correct users—but to study the environment that shaped them.
When we design with this lens, success stops being "did they follow the rules?" and becomes "did the system reliably produce the behavior we wanted?" That shift changes how we evaluate quality. It changes how we interpret metrics. It changes how we assign responsibility. And most importantly, it makes behavior legible—not something to argue about, but something to learn from.
Because in complex systems, behavior isn't the problem.
Behavior is the point.