Friction, on purpose

The person who installs a focus app at nine in the morning and the person who wants to open Instagram at two in the afternoon are not the same person. They share a name, a phone, and a calendar. They do not share priorities, and the two o’clock version has one significant advantage: they are the one holding the device at the moment the decision gets made.

Almost every focus app on the market is designed by and for the nine o’clock person. It asks you to set intentions. It shows a gentle reminder when you drift. It congratulates you when you come back. All of this is addressed to someone who is already convinced, and none of it survives contact with the person who is not.

We built Rune on the opposite assumption: that the user will try to get around it, that they will be clever about it, and that the product’s job is to lose that argument on their behalf.

The feature is the refusal

Rune’s central mechanic is that a session, once started, holds. Apps and websites are genuinely unavailable for the duration — not hidden behind a confirmation dialog, not delayed by a five-second timer, not restored by force-quitting. The commitment is made once, by the version of you that meant it, and the product enforces it against every later version of you that does not.

This is an uncomfortable thing to build. Every instinct in product development pushes toward removing obstacles. A blocked action is a failed action; a user who wants to do something and cannot is, by every conventional measure, a problem. We spent a long time resisting the urge to add an escape hatch, and the arguments for one were always reasonable: what about emergencies, what about a mistake, what about the user who genuinely needs the thing they blocked.

The honest answer is that an escape hatch is used for emergencies approximately never and for boredom approximately always. Once it exists, it becomes the path, and the product quietly reverts to being a reminder with extra steps. The people who chose Rune chose it precisely because it says no. Making it easier to overrule would have removed the only thing it does that its alternatives do not.

Friction has to be aimed

The mistake would be concluding that friction is generally good. It is not. Friction is a tool with a very narrow correct application: it belongs on the action the user has told you, in advance and in a calmer state, that they want to make harder. Everywhere else it is just bad design.

So the same product that refuses to unblock Instagram works extremely hard to remove friction everywhere else. Starting a session is one tap, because we found that almost nobody builds a custom one — Gym Mode, Social Detox, and Deep Study cover the overwhelming majority of use, and the effort we might have spent on a better configuration screen went into making the three defaults good enough that configuration is unnecessary. Recurring routines start sessions without being asked, on the theory that the most reliable habit is the one you stop having to choose. Location triggers do the same thing with context instead of time.

The pattern is: make the decision expensive to reverse, and make everything around the decision as cheap as possible. Products that get this backwards — easy to abandon, tedious to start — are the reason people have four abandoned focus apps on their phone.

The screen you see when you fail

The most carefully designed screen in Rune is the one users hit when they try to open something blocked. It is the moment of maximum frustration, and it is where the product either keeps the user or loses them permanently.

A hostile version of that screen is easy to write and disastrous. Nobody responds well to being scolded by software, and the natural reaction to a smug blocking message is to delete the thing that produced it. We made it calm, we let it be customised, and we treated the copy on it as product surface rather than as an error state. That single screen does more for retention than any feature we could have added in the same time.

This generalises further than it looks. The screens users see when something goes wrong get a fraction of the design attention of the screens they see when everything works, and they carry more weight. In business software this is even more pronounced, because the failure states are where the users actually live — the validation error, the permission denial, the record that will not save.

One number, not a dashboard

Rune calculates a focus score from real sessions. It is one number. It does more for the product than any chart we built, and for a while we did not understand why.

The reason is that a dashboard asks the user to do analysis, and users do not want to do analysis about themselves. They want to know whether things are going well. A chart of session lengths over time is more information and less useful, because extracting the answer from it is work, and the work happens at exactly the moment the user is deciding whether this app is worth keeping.

We now start reporting work from the other end. Before designing any analytics surface, the question is which single number the user should be able to read in one second, and what they should do differently based on it. Everything else is supporting material for the people who want to dig, and it goes behind the number rather than in front of it.

What this has to do with business software

Internal tools are full of actions that should be hard and are not. Deleting a record that six other teams depend on. Changing a permission that silently widens access. Running an export that quietly contains everything. Most business software treats all of these identically to changing a display name, and then manages the consequences through training documents and a shared understanding that certain buttons are not to be pressed.

That is the same design failure as a focus app with an easy escape hatch, and it has the same fix. Find the actions that are expensive to undo, and make them proportionally expensive to take. Make everything else instant. The result is software people trust with real work, because it visibly understands which parts of that work matter.

Constraints, honestly chosen and clearly explained, are not a limitation on a product. Quite often they are the product.