Doomscrolling isn't a user problem.
It's a design decision.

When people scroll too much, the conversation usually turns to self-discipline. Digital diet. Phone-free hours. The weakness of attention in the information age. That's the wrong level.

Doomscrolling isn't a character flaw. It's the direct result of decisions made by designers and product managers — deliberately, documented, backed by efficacy studies. Once you see that, you stop blaming yourself. And you start asking different questions.

The decisions that produce the stream

Start with the simplest one: the endless feed.

Introduced around 2006 as an interface fix for a technical problem — page breaks slow down loading, interrupt flow, cost clicks. The solution: the feed never ends. No bottom of the page, no pause, no natural prompt to stop.

That's a design decision with a clear consequence: it removes the stopping point. A reader who reaches the last line pauses. A scroller who never reaches the last line — keeps scrolling.

The second decision is algorithmic sorting. Chronological feeds — the oldest post at the bottom, the newest at the top — were replaced from the mid-2010s onward with relevance algorithms. The official rationale: show users the best content, not the newest.

The actual consequence: the algorithm optimizes for engagement. And engagement is not the same thing as satisfaction.

Research from behavioral science — including work from the Stanford Persuasive Technology Lab — has shown for years what platforms knew internally even earlier: negative emotions produce more interaction than positive ones. Outrage holds attention longer than joy. Fear scrolls further than calm.

The algorithm learns this. Not because anyone explicitly programmed it to. Because it was optimized for engagement — and engagement is fed by certain emotions.

The third decision: notifications as an interruption architecture

Push notifications were introduced as a convenience feature. You don't have to actively go to the platform; the platform comes to you.

That's an inversion of usage patterns. Instead of you deciding when to open the platform, the platform decides when to claim your attention. Multiple times a day. Optimized for open rate.

The result is an interruption architecture: daily life is no longer structured by attention decisions of the user, but by trigger points the system sets. The user reacts instead of acts.

These three decisions — no stopping point, engagement optimization, notification triggers — didn't come together by accident. They were developed as a complex that reinforces itself. No end means: you're already in. Algorithm means: the next thing is always more interesting than the current. Notification means: you come back, even when you'd gone.

Why "self-control" is the wrong answer

When the architecture is built to remove natural stopping points and actively interrupt your stops, self-control is not a fair counter-strategy. It shifts the burden of confronting a structural decision onto the individual user.

That's not just dishonest. It's also ineffective. Individual decisions against systematic design only work for those with the time, knowledge, and capacity to opt out actively. That's a small minority. Everyone else keeps scrolling.

The question that should be asked instead is a design question: what if interface decisions optimized for different targets?

Not engagement. Something else.

Design for other goals

There is no neutral design decision. Every interface optimizes for something — consciously or not. Endless scrolling optimizes for time-on-platform. An interface with stopping points optimizes for completion. A chronological feed optimizes for transparency. A relevance algorithm optimizes for engagement.

What if an interface optimized for encounter? Not for reach, not for engagement rate, but for the question: who is here right now, and what happens when people share a place?

That's not a hypothetical question. It's a design decision — just like the others. It has different consequences. It produces different behaviors. It needs different metrics to know whether it works.

weblin asks that. Not as an answer to doomscrolling — the architecture is different, the context is different. But as a demonstration that interface decisions are not inevitable. That what we experience as the default state of the web is the result of decisions. And that other decisions are possible.

Doomscrolling is not a law of nature. It's product design. Which, when you follow it through, is good news.