Technology is the medium. Behavior is the outcome.

This is the sentence I come back to when I'm lost.

Not because it's clever. Because it reorders my priorities when they drift (which they do, constantly) toward the thing I'm comfortable with (building) and away from the thing that actually matters (whether anyone uses what I built).

We confuse the medium for the outcome

Technology teams celebrate shipping. Launch parties. Version numbers. App Store approvals. Sprint velocity. Lines of code. Features marked done.

None of those are outcomes. They're activities. Evidence that the medium was produced.

The outcome is behavior. Did someone come back? Did they complete the task? Did they trust the institution behind the product? Did they tell someone else? Did their life get measurably easier?

When I review products that aren't working (and I've reviewed a lot of them), the team almost always knows what's wrong at the engineering level. Crashes. Slow load times. Missing features. What they often can't articulate is what behavior they expected and why it didn't happen.

Technology should adapt to people

The default assumption in software is that people will adapt to technology. Read the manual. Learn the workflow. Tolerate the friction. Come back after we fix it in the next release.

Sometimes that works for captive audiences (employees required to use internal tools, for example). It almost never works for citizens, consumers, or anyone with a choice.

Every product I respect starts from the opposite assumption: the technology adapts to the person. Their context. Their anxiety. Their habits. Their limited attention. Their phone on a bad connection at 7 AM.

That assumption changes everything about how you prioritize. It puts stability before growth. It makes every feature earn its place. It explains why simplicity creates trust.

One question

Everything on this site flows from one question:

How can we design technology that people actually use?

Not download. Not sign up for. Not praise in a stakeholder meeting. Actually use: repeatedly, willingly, in a way that creates value for them and for the organization behind the product.

That's a harder question than "how do we build this feature?" It requires sitting with discomfort. Watching people struggle with something you made. Admitting that your elegant architecture doesn't matter if the behavior never forms.

Why I write this down

I forget this constantly. Building is tangible. Behavior is slow and ambiguous. It's easier to open an IDE than to watch a user session recording and accept that your assumptions were wrong.

Writing is how I hold myself accountable. This site is a digital garden: ideas I'm tending over time, revisiting, refining. Some will grow. Some will be wrong and get replaced by better ones.

But this sentence stays: technology is the medium. Behavior is the outcome. If I'm not designing for the outcome, I'm just making things.