Habit-forming products: design the return, not the compulsion

Search for habit forming products and almost every result is about one book. Nir Eyal's Hooked gave product teams a four-step loop of trigger, action, variable reward and investment, and plenty of teams read it as a manual for getting people stuck. A designer needs to know where the line is, and it is easier to find than the debate suggests: it sits on the screen someone sees when they come back.

Compulsion makes leaving expensive. A healthy habit makes coming back worth it. Both lift the same retention chart, so the difference has to be designed on purpose: a count that rewards returning and never punishes a missed week, and a reason to return that comes from the product, not the notification layer. This post works it through on one of the practice briefs on Quest, an indie studio that builds its game in public.

Compulsion and return look the same on a dashboard

An active-users chart cannot tell you why someone opened the product. The person who came back because something they care about changed and the person who came back to stop a counter from resetting draw the same line. Optimise the chart alone and you drift toward whichever is cheaper to produce, and a small fear usually is.

The difference shows up in one place: the moment after an absence. Look at what your product says to someone who has been away for two weeks. If the first thing they meet is a loss, such as a reset counter, a message that performs disappointment or a list of what they failed to do, the habit runs on the cost of leaving. If the first thing they meet is what changed while they were gone and what their last action did, it runs on the value of returning.

That moment is a screen, which makes it a design problem rather than an ethics seminar. Every visit after the first is a return, and for a product people use for months that is nearly all of them, so it deserves the care the first visit gets.

Meet the trigger, do not manufacture it

Eyal's most important claim is about internal triggers: a product becomes a habit when a feeling, not a notification, sends someone to it. The internal trigger page lists the usual ones, and they are unglamorous: boredom, loneliness, indecision, mild anxiety, fear of missing out. They are frequent and uncomfortable, and that is exactly why they can anchor a loop.

That is also where the line runs. The skill page puts it plainly: there is a difference between meeting an emotion the user already has and cultivating one. A meditation app that answers anxiety someone already lives with is doing legitimate work. A product that manufactures social anxiety in order to relieve it is, in the page's own words, engineering the wound it sells the bandage for.

The practical version is a question for any return trigger: did this feeling exist before our product, or did we put it there? Curiosity about something you care about existed before. The worry that you are falling behind, or that your rank is slipping, usually did not. Eyal's own test, quoted on the same page, is blunter: would you be a willing user of the thing you are building?

Worked exercise: a studio that builds in public

Black Salt Games is one of the practice briefs on Quest: a five-person indie studio on its second title, a narrative roguelike, eighteen months into development and six months from launch. It builds the game in public. Discord members get a weekly devlog with a playable build, the community votes on cosmetic and lore decisions, every member of the team is visible in the Discord, and launch-day buyers are credited by name in the game's outro.

The brief is the pre-launch page, and it names the problem: the page only converts to Steam wishlist clicks. Visitors wishlist and forget, and there is no second loop to bring them back. One of its sub-objectives is to add a return trigger so visitors come back during development. The player it describes wishlists more than fifty games a year, watches devlogs, wants to be early to a cult classic and forgets about games between trailers.

The Hooked model for designers already drew the whole loop on this brief and found the leak in investment. This exercise goes one screen further, to a moment that post does not draw. A fan joined three weeks ago, missed the last two devlogs and comes back. What do they see? Whether this product forms a habit or a compulsion is decided on that screen.

A weekly product has no daily unit

The reflex is a streak: weeks in a row you opened the devlog, with a flame next to the number. The Duolingo streak teardown explains why that reflex fails here. A streak works when the behaviour is small, daily and identical, so it can become part of who you are. Black Salt ships once a week, to fans who wishlist fifty games a year. On that rhythm, a consecutive count becomes a number that makes people feel bad for having played something else.

It also fails on its own terms. The force of a consecutive streak comes from the cliff: the longer it runs, the more you lose by missing once. That is precisely the cost of leaving, and it lands hardest on the fan you most want back, the one who drifted for two weeks. They return to a reset, and the first thing the product tells them is that they failed.

The decision for this brief is a count that only goes up: builds you have played, votes you have cast, devlogs you have read. None of them resets, so a missed week costs nothing and every return adds to something. You give up the cliff, and with it the most compulsive part of the mechanic. What you keep is the part the teardown calls investment: an asset the fan built and the product remembers, placed where they will see it.

It will pull fewer people back out of fear, and that is the point: the people it brings back came for the build, so they are the ones still there on launch day.

The reason to come back has to be in the product

A count is a receipt, not a reason. Nobody returns to watch a number go from nine to ten. The reason has to be something that changed in the product while they were gone, and the brief already has three: a new playable build every week, the result of a vote they may have cast and, if they buy on launch day, their name in the outro. Each one is true, each one can be checked, and none of them needs the fan to feel anxious first.

Compare the triggers a generator will suggest for a return loop: a badge available this week only, a countdown to a reward that resets, a message saying the community is moving on without you. Each of those is a reason that lives in the notification layer, not in the product. They work because they borrow a feeling the product did not earn.

This is where the line between dark patterns and persuasive design becomes practical. That post puts the line in the claim: is it true, and could the user check it at the moment of choice? A message saying the new build is up and the lore choice they voted on is in it makes a claim the fan can check in one click. A message saying their place in the community is at risk makes a claim about nothing.

The sample brief asks the same question in another shape: a release page for an indie label, where one objective is to make returning visitors feel progress. Draw its return screen before reading on.

One screen beyond the brief: the fan who missed two devlogs

Here is the return screen, in the order the fan meets it. It can be the top of the page they wishlisted from or the first Discord message after a gap; the content is the same.

1. What changed while you were away. Two builds, one line each: what is new and what was cut. The brief describes a devlog-honest voice that shows broken builds and talks about cuts, so the catch-up can say what did not work as well.
2. What your last action did. If they voted before they left, the result of that vote and where it shows up in the build. If they did not, the vote that is open now.
3. One action, in the same place as last time. Play the new build, or cast this week's vote, with the same button, in the same position and with the same words as on the first visit.
4. Your count, quietly. Builds played, still there, and one more if you play today. No flame, no reset and no comparison with other fans.

The third item is where practice comes in. In Fogg's terms, prior familiarity is borrowed ability: an action you have done before costs almost nothing, because you paid for the learning on an earlier visit. A habit is partly that, an action made cheap by repetition. Redesign the door people come back through and you charge them for the learning again, at the moment their motivation is lowest.

What the screen leaves out matters as much: no list of missed devlogs framed as a debt, no copy performing disappointment, no message that the community moved on. It assumes they had a reason to be elsewhere and gives them a reason to be here.

Where the line sits

Put the two versions of the return side by side and the line is easy to state: compulsion charges for the absence, a habit pays for the return. Three questions find it on any screen. Two come from the persuasion principles for product designers and one from the internal trigger page.

• Would it survive disclosure? Tell the fan exactly how the return screen works. Showing what changed and what their vote did survives. Resetting their count so they feel the loss does not.
• Did the feeling exist before the product? Curiosity about the build did. Fear of falling behind other fans would have to be manufactured.
• Is the claim true right now? A new build can be checked in one click. Urgency about a reward that resets every week cannot.

There is a fourth question, for whoever decides whether it ships: what does the product gain from the user's discomfort? If the answer is anything at all, the mechanism has crossed. The Duolingo teardown draws the same boundary around streak repair: once a product charges you to fix a loss it made you afraid of, the fear is the product. A count that only goes up has nothing to repair.

What you train, and how you measure it

Knowing the Hook Model is not the trained part: any model can recite it, and any generator will draw a streak, a badge and a countdown on request. What it will not do is notice that a weekly product has no daily unit, or that the reset lands on the fan you most want back. That judgement comes from making the call on real briefs, and no generator supplies it.

Measure the return, not the streak. The number for this brief is the share of fans who come back after missing at least two devlogs and then do something real: play the build or cast the vote. It leaves out the fans who never left, who would look healthy under any design.

Two more readings keep it honest. The internal trigger page suggests looking at when sessions happen: habit shows up as concentration around recurring moments, here the devlog day, rather than as raw volume. And watch the exits. If returns rise and Discord mutes, leaves or email unsubscribes rise with them, the trigger is pulling people back against their will, which is the compulsion you set out to avoid. Decide that threshold before you ship.

The last reading is a conversation. Ask a few returning fans what they were doing just before they came back: a situation or a feeling means the coupling exists, and a notification means the habit has not formed yet.

Take a product you work on, or any product people use more than once. Open it as someone who has been away for two weeks and write down the first three things it tells them. Mark each one as a cost of having left or a reason to have come back. Then redesign that screen in four lines: what changed, what their last action did, one familiar action and a count that cannot go down.

To do it on a full brief, the sample brief shows the format, with a starting design to beat and a return loop in its objectives. The skills library has the mechanism, the failure mode and the ethical line for every trigger you might reach for, which is the part to read before the pattern.

DiagramCopy

You are a senior product designer helping me design the return to a product, not the hook. Ask me, one at a time, for: [the product and how often people naturally use it], [what changes in the product between visits], [what a returning user sees today after two weeks away, in order] and [the triggers we send to bring people back]. Then: 1) name the internal trigger each return relies on and say whether that feeling existed before the product or we create it; 2) mark every element of the return screen as a cost of having left or a reason to have come back; 3) say whether a consecutive streak fits our natural rhythm and, if not, propose a count that only goes up; 4) redesign the return screen in four lines: what changed, what their last action did, one familiar action and the count; 5) give me the metric for returns after a gap and the side effect to watch. Reject any trigger whose claim the user could not check.