The Habit Loop

The previous lesson established the conditions for a single behavior to occur: the product of motivation, ability, and trigger must clear a threshold. This framework explains the first borrow. The catalog interface’s real question is repetition. Does the user come back a second time, a fifth time, a twentieth time?

A repeated behavior is not recomputed from scratch every time. Once repeated enough, the behavior stops being a matter of clearing the motivation threshold and becomes a direct response to a signal. This lesson builds the structure of that transformation and discusses under what condition the designer has the right to build that structure.

The Loop’s Three Parts

The habit loop consists of three parts.

A cue is the signal that starts the behavior. Its difference from the trigger in the previous lesson is that the cue is recurring and tied to context: a due-date reminder that arrives every Tuesday is a cue; it is not a one-time announcement. The cue’s power comes from its predictability.

A routine is the behavior performed after the cue. In the catalog interface, the routine is extending the duration of a borrowed book or adding a new book to a shelf. The routine’s cost was the subject of the previous two lessons: the number of decision points, decision time, ability.

A reward is the outcome that follows the routine and reinforces the behavior. A reward does not have to be a gamification element; finding the book they wanted on the shelf, having a duration extension confirmed instantly, or knowing they no longer have to track the due date are also rewards.

The three parts form a loop: the cue starts the routine, the routine leads to the reward, and the reward strengthens the effect of the next cue. Habit strength is a quantity that grows with how many times this loop has been completed.

The Loop’s Strengthening Through Repetition

The simulation below follows five hundred users over twenty-six weeks. Each week the cue may or may not arrive; when the cue arrives, the user may or may not complete the routine; when they complete it, the reward may or may not follow. Habit strength grows with a rewarded repetition and decays in a week without repetition.

Five designs are compared. Four of them weaken one part of the loop; the fifth strengthens all three parts but lowers the rate at which a visit delivers a benefit to the user.

// habit.mjs — how the cue, routine, and reward loop strengthens with repetition

function generator(seed) {
  let s = seed >>> 0;
  return () => { s = (s * 1664525 + 1013904223) >>> 0; return s / 4294967296; };
}

const ALPHA = 0.22;  // strength gain from each reinforced repetition
const DELTA = 0.06;  // decay in a week without repetition
const WEEK = 26;
const PEOPLE = 500;

// A design: cue reliability, routine cost (0-1), reward reliability, and the rate
// at which a visit actually delivers a benefit to the user.
const DESIGNS = [
  { name: "no cue", cue: 0.15, cost: 0.45, reward: 0.90, benefit: 0.85 },
  { name: "unreliable reward", cue: 0.90, cost: 0.45, reward: 0.30, benefit: 0.85 },
  { name: "heavy routine", cue: 0.90, cost: 0.80, reward: 0.90, benefit: 0.85 },
  { name: "all three in place", cue: 0.90, cost: 0.25, reward: 0.90, benefit: 0.85 },
  { name: "frequent cue, irrelevant content", cue: 0.98, cost: 0.20, reward: 0.95, benefit: 0.18 },
];

// One person's 26 weeks. If a cutoff is given, the cue thins out after that week.
function person(design, rnd, cutoff = null) {
  let h = 0.05;
  let visits = 0, useful = 0, threshold = null;
  const hByWeek = {};
  for (let week = 1; week <= WEEK; week++) {
    const cueRate = cutoff !== null && week > cutoff ? 0.15 : design.cue;
    const cueArrived = rnd() < cueRate;
    // Completing the routine: requires the cue; probability rises with habit strength, falls with cost
    const completes = cueArrived && rnd() < (0.35 + 0.6 * h) * (1 - design.cost);
    if (completes) {
      visits++;
      if (rnd() < design.benefit) useful++;
      h = rnd() < design.reward ? h + ALPHA * (1 - h) : h * (1 - DELTA);
    } else {
      h = h * (1 - DELTA);
    }
    if (threshold === null && h >= 0.5) threshold = week;
    hByWeek[week] = h;
  }
  return { hByWeek, visits, useful, threshold };
}

function population(design, cutoff = null) {
  const rnd = generator(20250115);
  let visits = 0, useful = 0, thresholdCount = 0, thresholdTotal = 0;
  const h = { 6: 0, 12: 0, 18: 0, 26: 0 };
  const cutoffH = {};
  for (let i = 0; i < PEOPLE; i++) {
    const p = person(design, rnd, cutoff);
    visits += p.visits; useful += p.useful;
    for (const w of [6, 12, 18, 26]) h[w] += p.hByWeek[w] / PEOPLE;
    if (cutoff !== null) cutoffH[cutoff] = (cutoffH[cutoff] ?? 0) + p.hByWeek[cutoff] / PEOPLE;
    if (p.threshold !== null) { thresholdCount++; thresholdTotal += p.threshold; }
  }
  return {
    h, visits: visits / PEOPLE, useful: useful / PEOPLE,
    thresholdRate: (thresholdCount / PEOPLE) * 100,
    thresholdWeek: thresholdCount === 0 ? null : thresholdTotal / thresholdCount,
    cutoffH: cutoff === null ? null : cutoffH[cutoff],
  };
}

console.log("design                              h(6)  h(12)  h(18)  h(26)  crosses 0.5  avg. crossing  visits");
const S = {};
for (const d of DESIGNS) {
  const s = population(d);
  S[d.name] = s;
  console.log(
    `${d.name.padEnd(35)} ${[6, 12, 18, 26].map((w) => s.h[w].toFixed(2)).join("   ")}` +
    `  ${(s.thresholdRate.toFixed(1) + " %").padStart(11)}  ${(s.thresholdWeek === null ? "-" : "week " + s.thresholdWeek.toFixed(1)).padStart(10)}  ${s.visits.toFixed(1).padStart(7)}`
  );
}

// Cost of weakening one of the loop's three parts
console.log("\nreference: all three in place (h(26) = " + S["all three in place"].h[26].toFixed(2) + ", visits " + S["all three in place"].visits.toFixed(1) + ")");
const ref = S["all three in place"];
for (const name of ["no cue", "unreliable reward", "heavy routine"]) {
  const s = S[name];
  console.log(`${name.padEnd(35)} h(26) is ${(s.h[26] / ref.h[26] * 100).toFixed(0)} % of reference, visits ${(s.visits / ref.visits * 100).toFixed(0)} % of reference`);
}

// Number of visits and benefit delivered to the user are not the same thing
console.log("\ndesign                              visits  useful  wasted  useful rate");
for (const d of DESIGNS) {
  const s = S[d.name];
  console.log(
    `${d.name.padEnd(35)} ${s.visits.toFixed(1).padStart(7)}  ${s.useful.toFixed(1).padStart(7)}` +
    `  ${(s.visits - s.useful).toFixed(1).padStart(8)}  ${((s.useful / s.visits * 100).toFixed(1) + " %").padStart(12)}`
  );
}

// How long the habit lasts if the cue is thinned out after week 14
console.log("\nif the cue is thinned out after week 14");
for (const name of ["all three in place", "frequent cue, irrelevant content"]) {
  const d = DESIGNS.find((x) => x.name === name);
  const s = population(d, 14);
  console.log(`${name.padEnd(35)} h(14) ${s.cutoffH.toFixed(2)} -> h(26) ${s.h[26].toFixed(2)}  (${(s.h[26] / s.cutoffH * 100).toFixed(0)} % remains), visits ${s.visits.toFixed(1)}`);
}

design                              h(6)  h(12)  h(18)  h(26)  crosses 0.5  avg. crossing  visits
no cue                              0.06   0.07   0.08   0.10        1.0 %   week 19.4      0.9
unreliable reward                   0.10   0.12   0.14   0.18       10.0 %   week 17.1      5.4
heavy routine                       0.10   0.14   0.16   0.20       13.2 %   week 15.5      2.0
all three in place                  0.30   0.49   0.61   0.69       95.4 %   week 11.1     10.8
frequent cue, irrelevant content    0.36   0.59   0.72   0.81       98.8 %    week 9.3     13.6

reference: all three in place (h(26) = 0.69, visits 10.8)
no cue                              h(26) is 14 % of reference, visits 8 % of reference
unreliable reward                   h(26) is 25 % of reference, visits 50 % of reference
heavy routine                       h(26) is 29 % of reference, visits 19 % of reference

design                              visits  useful  wasted  useful rate
no cue                                  0.9      0.7       0.1        86.0 %
unreliable reward                       5.4      4.6       0.8        85.6 %
heavy routine                           2.0      1.7       0.3        85.9 %
all three in place                     10.8      9.2       1.6        85.5 %
frequent cue, irrelevant content       13.6      2.4      11.2        17.8 %

if the cue is thinned out after week 14
all three in place                  h(14) 0.51 -> h(26) 0.31  (62 % remains), visits 5.6
frequent cue, irrelevant content    h(14) 0.64 -> h(26) 0.39  (61 % remains), visits 7.2

All Three Parts Are Required, But Not in the Same Way

The first table gives the result of weakening the loop’s parts one at a time. In the design with all three in place, habit strength is 0.30 at week six and 0.69 at week twenty-six; 95.4 percent of users cross the 0.5 threshold. When one part is weakened, strength at week twenty-six drops to between 14 and 29 percent of the reference.

The second table shows that the parts fail in different ways. Without a cue, the user comes on average 0.9 times over twenty-six weeks: the loop never starts. With an unreliable reward, the number of visits stays at 50 percent of the reference but habit strength stays at 25 percent — the user comes, does the routine, and no reinforcement occurs. With a heavy routine, visits drop to 19 percent, but those who do come get reinforced; the strength ratio (29 percent) is higher than the visit ratio (19 percent).

The design conclusion is this: which part is weak can be read from the observed pattern of numbers. If visits are low and strength is low, the cue is missing. If visits exist but strength does not, the reward is missing. If visits are low but those who come stay, the routine is heavy. All three collapse into the same “low repetition” indicator, and intervention is not possible without separating them.

Habit Strength Is Not a Success Metric

The third table is the center of gravity of this lesson. The “frequent cue, irrelevant content” design ranks first on every habit indicator: the highest strength (0.81), the highest threshold-crossing rate (98.8 percent), the earliest crossing (week 9.3), and the most visits (13.6). It beats the design with all three in place in every column.

In that same table, the last column says the opposite. Of the thirteen and a half visits, only 2.4 deliver a benefit to the user; eleven visits are wasted. In the design with all three in place, 9.2 of 10.8 visits are useful. The second design produces fewer visits but four times as many useful visits.

Visit count, session duration, and return frequency measure habit, not benefit. If an interface is optimized for these indicators, a design that takes the user’s time but gives them nothing looks “successful.” The criterion has been the same throughout this course: if the user knew they were sent a cue twice a week and that only two out of ten of those cues were useful to them, would they keep receiving those cues? If the answer is no, the habit serves the indicator, not the user.

This does not mean it is wrong for the designer to build a habit. A library user’s habit of never missing a due date serves the user’s interest; the user would want this reminder even knowing about it. The distinction is who the habit serves, and it is measured by the last column of the third table.

A Habit Does Not Carry Itself

The last table tests an assumption often stated: once a habit is established, does it continue on its own?

When the cue is thinned out after week fourteen, habit strength drops to roughly 61 percent in both designs. In the design with all three in place, from 0.51 to 0.31; in the other, from 0.64 to 0.39. There is no meaningful difference between the two designs.

The conclusion is this: in this model, the habit stays dependent on the cue. When the cue is cut, the behavior fades. This has two implications. For design: removing a reminder does not mean the user will keep up the behavior; the removal decision is made by measurement. For ethics: a design that makes the user dependent on a cue also holds the power to cut that cue. That power is a service when the cue serves the user’s interest; it is a dependency when it does not.

The model’s limit should be stated here. The simulation does not account for the user’s own internal reasons: a real user may look for the book they want even without the reminder. What the model shows is that the interface-produced portion of the habit is dependent on the cue; the portion that comes from the user’s own motivation is outside this simulation.

The Rules for Building the Loop

The legitimate way to build a habit in the catalog interface is summarized by four rules.

The cue is tied to the user’s calendar, not the designer’s calendar. A reminder that arrives as a due date approaches arises from the user’s own situation. Sending “new arrivals” on a fixed day of the week arises from the interface’s schedule; it does not assume the user has a need at that moment.

The routine is shortened, but the decision is not deleted. As measured in the previous lesson, lowering the routine’s cost strengthens the loop. What gets lowered is the number of decisions, not the user’s opportunity to notice what they are borrowing.

The reward is the routine’s natural consequence. The reward for extending a duration is the duration having been extended. A reward unrelated to the routine (badge, counter, streak) feeds the loop but, because it is not tied to the user’s benefit, lowers the last column of the third table.

The useful-visit rate is tracked as a separate indicator. If visit count is reported alone, every change that produces wasted visits looks like an improvement.

Summary

• The habit loop consists of cue, routine, and reward; the three reinforce each other through repetition, and habit strength accumulates through those repetitions.
• The parts fail in different patterns: if the cue is missing, both visits and strength drop; if the reward is missing, visits exist but strength does not; if the routine is heavy, visits are few but those who come get reinforced.
• A design that ranks first on every habit indicator can stay at a useful-visit rate of 17.8 percent; habit strength is not a success metric.
• If the useful-visit rate is not tracked as a separate indicator, every change that takes the user’s time looks like an improvement.
• In the simulation, the habit stays dependent on the cue: when the cue is thinned out, strength drops to roughly 61 percent; a habit does not carry itself.
• The legitimacy criterion is the same: would the user keep receiving the cues if they knew what proportion of them actually served them?

Next Step

This lesson addressed repeating a behavior and showed that lowering the routine’s cost strengthens the loop. The most powerful tool for lowering cost appeared in the previous lesson but was not measured: binding decision points to a default. A default is the value the user holds when they do nothing, and its effect is both surprisingly large and the most contested power in the designer’s hands. The next lesson computes that effect in two scenarios and ties the criterion that makes a default legitimate to a number.