Habit Is The Interface

I’m from Edinburgh, which is useful, because it gives me a convenient excuse to borrow from David Hume.

Not the polite version. The uncomfortable one.

People don’t make decisions because they understand things. They understand things because they’ve repeated them enough times that they feel true.

And yet most software is still built as if they don’t.

We design for rational users. Users who read, compare, weigh options, and arrive at a conclusion.

So we build flows that explain, interfaces that clarify, and systems that assume better understanding leads to better behaviour. We optimise for comprehension, for visibility, for the sense that everything is knowable if presented cleanly enough.

It sounds responsible. It sounds like good practice.

It is also, in most cases, wrong.

Not because users are incapable of reasoning, but because reasoning is not where behaviour settles. It’s where we justify behaviour after it has already stabilised.

Rationality is often just behaviour, explained after the fact.

Nobody reads the cookie options.

Not because they can’t, and not because they don’t understand them, but because they’ve learned the fastest way through. “Accept all” isn’t a decision. It’s a pattern that has proven reliable enough to repeat.

And once something becomes habit, explanation becomes irrelevant. Not useless, exactly, but secondary. Decorative, even. Something that exists alongside behaviour rather than shaping it.

Once behaviour stabilises, explanation becomes commentary.

This is the part we tend to avoid.

When behaviour doesn’t change, we add explanation. Onboarding, tooltips, helper text, progressive disclosure, empty states that gently suggest what should happen next. Layer after layer, each one well intentioned, each one quietly admitting the same thing.

The system is not doing what it should do on its own.

Explanation layers are what we add when behaviour doesn’t stabilise. They are not a sign of clarity. They are a sign that clarity failed.

Explanation is what we add when design doesn’t land.

But explanation persists, not because it works, but because it fits how organisations operate.

It is easier to explain than to change behaviour. Easier to add a sentence than remove a choice, easier to document intent than reshape a flow, easier to justify in a meeting where everyone is looking for something visible to improve.

Explanation travels well internally. It can be reviewed, approved, signed off. It gives the impression of progress without requiring the system itself to change in any meaningful way.

Explanation scales politically better than behaviour change.

And so explanation accumulates. Not as a design choice, but as a byproduct of how decisions get made.

David Hume didn’t argue that people are irrational in the way we often frame it. He argued something more awkward.

We don’t derive our understanding of the world through logic. We inherit expectations through repetition. We see something happen often enough, and we begin to believe it is how things work — not because we proved it, but because we got used to it.

We don’t believe things because they are true. We believe them because they have been true enough, often enough.

That shift matters, because it moves behaviour out of the realm of reasoning and into the realm of familiarity.

Software doesn’t change this. It industrialises it.

It gives us environments where repetition can happen faster, more consistently, and at greater scale than almost any other human system we’ve built.

Which means habits form quickly. Sometimes within minutes. Sometimes without being noticed at all.

Software is a habit engine.

Most interfaces are not decision environments. They are repetition environments — places where behaviour either stabilises quickly or never stabilises at all.

And when it doesn’t stabilise, we reach for explanation. We try to teach the user what the system failed to make obvious through use.

But teaching is slow. Repetition is fast.

And systems tend to follow the faster path.

You can see this most clearly in internal systems, where the gap between understanding and behaviour is hardest to ignore.

Dashboards that are perfectly clear, metrics that are well defined, filters that behave exactly as expected. Everything is understandable. Nothing changes.

Because the system assumes that insight leads to action.

But insight does not produce behaviour. Repetition does.

Insight informs. Habit decides.

A dashboard viewed daily without consequence becomes background noise. A report read weekly without action becomes ritual. Over time, these patterns stabilise — not as decisions, but as habits that sit alongside the work rather than shaping it.

This is where habit stops being just a behavioural quirk and starts to look more like infrastructure.

It becomes the underlying layer that everything else rests on. The thing that determines what actually happens, regardless of what the system is designed to encourage.

You can change the interface. You can improve the clarity. You can even change the stated intent of the system.

But if the habit remains, the behaviour remains.

If you don’t change the habit, you didn’t change the system.

So we ask the wrong questions.

Do users understand this? Is this clear? Have we explained it well enough?

These are questions about thinking. They assume that behaviour follows understanding, that if we can just make things clear enough, the right actions will follow.

But behaviour does not sit downstream of thinking. It sits downstream of repetition.

A better question is simpler, and harder to answer:

What will someone do the third time they see this?

Because the third time is where design reveals itself. The first time is exploration, the second is recognition, and the third is where habit begins to form. After that, it’s no longer a decision in any meaningful sense. It’s just what happens.

The third interaction is where design becomes behaviour.

And once something becomes “just what happens,” it becomes very difficult to dislodge.

This is where design actually operates. Not in moments of choice, but in the quiet accumulation of repeated behaviour.

Good systems don’t persuade people to behave differently. They make existing behaviour easier to repeat, or they gently redirect it until a new pattern stabilises.

You are not designing decisions. You are designing repetition.

Bad systems do the opposite. They require effort each time, attention each time, thought each time. So behaviour never stabilises, and explanation fills the gap.

We tend to optimise for explainability because it is visible, defensible, and looks like progress. But explainability is not the same as influence.

You can explain something perfectly and still fail to change what people do.

Clarity does not create change. Repetition does.

So we add more explanation, and each time we do, we move a little further away from the real problem, which is not what people understand, but what they repeat.

The shift is not from bad design to good design. It is from decision design to behaviour design.

From asking whether users understand this, to asking whether it becomes automatic. From asking whether it is clear, to asking whether it gets repeated. From focusing on moments of choice, to focusing on patterns of use.

Call it Habit-Led Design. Not designing for what users think, but for what they will repeat.

We like to believe we are designing for better decisions. It sounds responsible, measured, controlled.

But most systems don’t change how people think. They change what people get used to.

And habit, once established, doesn’t feel like influence. It feels like reality. It feels like the way things are, rather than the result of design choices made somewhere upstream.

Habit is how design hides itself.

So that’s the part we should be paying attention to. Not what users decide, but what they stop deciding.

Because that is where design does its real work.

And if habit is the interface, it’s worth asking what happens when the interface disappears into language.