← Back

Behavior is the point

I first encountered the idea that behavior is a function of the person and their environment years ago in design school. It stuck because it clarified something I'd seen repeatedly in practice and was frustrated by: when people don't behave the way we expect, the failure is usually attributed to the person, not the system that shaped the situation they were acting in.

That framing is critical. But the environments we're designing today — especially in crypto and developer infrastructure — have changed enough that it's worth being more precise about what we mean by "environment," and what kinds of behavior we're actually designing for.

The original argument is straightforward: If people aren't behaving the way you expect, don't blame them. Look at the environment you created.

Teams still:

  • Reach for education when something doesn't work instead of reducing friction
  • Explain away drop-off as "the wrong users"
  • Treat repeated mistakes as user failure rather than system feedback

When actions are irreversible and the cost of being wrong is high, "they should've known better" is not a serious design position. But the environments we're building in and for now are more than interfaces, and more than flows.

In crypto products and developer platforms, the environment includes:

  • Network conditions, latency, and community activity
  • APIs, SDKs, and documentation
  • Economic incentives and protocol mechanics
  • What happens when something goes wrong — and how visible that is
  • What people around you are doing, copying, and normalizing

Crucially, many users — especially developers — aren't just interacting with this environment. They're building inside it. That means the system doesn't just influence behavior once. It shapes patterns that get reused, adapted, and shipped forward. When something "odd" becomes normal, or a workaround becomes standard practice, that's not a culture problem. It's the environment doing exactly what it was set up to do.

I want to be explicit about something: *design shapes understanding*, and understanding is how people make judgments under uncertainty.

In high-stakes systems, understanding is not about memorizing rules. It's about:

  • Knowing what matters right now
  • Knowing what could go wrong
  • Knowing what will happen if you proceed

If someone hesitates, abandons a flow, or double-checks something "obvious," that's not friction for friction's sake. It's someone trying to get enough footing to act responsibly in an environment that doesn't fully have their back. Understanding is not separate from outcomes. It's how outcomes are produced when trust and risk are involved.

Crypto strips away a lot of the safety nets traditional software relied on:

  • There's no undo
  • There's no simple correction later
  • There's no support agent who can reverse the mistake

If the environment is confusing, people stall. If it's opaque, they get anxious. If it's brittle, they avoid it or route around it. A lot of what we call "bad UX" in crypto is actually people responding rationally to systems that demand more certainty than they provide.

When this breaks down, you see it first with developers — not because they're careless, but because they're pragmatic.

Developers:

  • Follow the path that gets them unstuck fastest
  • Rely on examples to understand how something is meant to be used
  • Avoid tools that make it hard to tell whether they're doing the right thing
  • Lose trust quickly when behavior doesn't match documentation

If an API or SDK makes it unclear what's happening, people don't philosophize about abstractions. They guess. They test. They move on. That's not a character flaw. It's a reasonable response to incomplete feedback. And once a pattern works — even if it's clumsy — it spreads. Not because it's "canonical," but because it reduced uncertainty in a moment where uncertainty was expensive. That's how environments teach behavior.

Recent work at the intersection of crypto and AI sharpens this idea in an interesting way.

LLMs demonstrated that intent can be translated into execution. You can describe an outcome in natural language, and software can determine the steps. DeFi demonstrated something different but complementary: financial actions can exist as callable primitives. Borrowing, lending, liquidation — not behind products, but as executable operations.

Put together, this reveals something that reframes a lot of financial UX debates: Many "UX problems" aren't really about interfaces. They're about coordination.

We've historically forced humans to:

  • Track state across systems
  • Sequence actions correctly
  • Reason about risk propagation

Not because that's desirable, but because software couldn't do it. As that constraint loosens, the design problem doesn't disappear — it shifts. The question becomes less about how someone clicks through a flow, and more about how intent is interpreted, constrained, and acted on.

Sitting with this idea again makes me think a few things feel clearer than they used to:

  • If behavior scales, the environment enabled it
  • Understanding is a prerequisite for trust, not a nice-to-have
  • Systems teach people how to behave whether we plan for that or not
  • Delegating action to software raises the stakes on clarity, boundaries, and failure modes

The original idea pushed me to stop blaming users. What's changed is my sense of responsibility for the systems we're building — especially the parts users are expected to reason about when things don't go perfectly.

That's where design shows up. Not just in what works when everything is fine, but in how people orient themselves when it isn't.

Wodtke, Christina. "The Formula That Changed How I Think About Design." Eleganthack, n.d., https://eleganthack.com/the-formula-that-changed-how-i-think-about-design/. Accessed 11 Jan. 2026.

Goldberg, Omer [@omeragoldberg]. "Most of the crypto × AI narratives you hear are backwards…" X (formerly Twitter), 20 Oct. 2025, https://x.com/omeragoldberg/status/2010246217482035537?s=20. Accessed 11 Jan. 2026.