Justifying the Need for a System

The previous lesson measured that a component library covers only a quarter of an interface’s decisions. The existence of the uncovered three-quarters shows a gap; it does not show that filling the gap pays off. Building a system is not free: defining the token layer, writing components, maintaining documentation, and migrating existing screens all demand measurable effort.

This lesson compares that effort against the effort it saves in return, in the same unit. The question is not “is consistency good”; that consistency is good was already shown in the Repetition and Consistency lesson. The question is: after how many screens does the system pay for itself, which input moves that point the most, and under which conditions is not building a system the right call.

Two Paths, One Unit

For the comparison, both paths are written in the same unit. On the systemless path, every new screen makes from scratch the decisions that have no counterpart in a system; an inconsistency debt also builds up over time, because the same decision gets answered differently on different screens, and those deviations have to be found and reconciled later. On the systematic path, a setup cost is paid up front; after that, most decisions are referenced, a small share are genuinely new, and every screen adds a maintenance share to the system.

The inputs come from an institution’s own measurement. The numbers below are this catalog institution’s measurement; another institution would produce different numbers. What is portable is the calculation itself.

// justification.mjs — cost comparison of the systematic and systemless paths and the break-even point

// Inputs are in hours and come from this institution's own measurement; another
// institution would produce different numbers. What is portable is the calculation itself.
const G = {
  decisionNew: 0.7,          // cost of making a decision from scratch (options + review + implementation)
  decisionReference: 0.1,    // cost of referencing an existing decision
  decisionsPerScreen: 18,    // from What Is a Design System: 18 of 24 decisions sit in the value/pattern/rule layers
  newDecisionRatio: 0.15,    // share of decisions that are genuinely new on each screen, even on the systematic path
  setup: 90,                 // token layer + components + documentation + distribution
  maintenanceRatio: 0.08,    // maintenance cost fed back into the system per screen (hours)
  deviationProbability: 0.2, // probability that a decision is remade independently and deviates on a new screen
  deviationFix: 1.5,         // finding and reconciling a deviated value later (search + change + verification)
};

function systemless(screens, g = G) {
  const decisionCost = screens * g.decisionsPerScreen * g.decisionNew;
  // Expected number of distinct values per decision: 1 on the first screen, then each
  // further screen has probability p of introducing a new value.
  const distinctValues = 1 + (screens - 1) * g.deviationProbability;
  const debt = g.decisionsPerScreen * (distinctValues - 1) * g.deviationFix;
  return { decisionCost, debt, total: decisionCost + debt, distinctValues };
}

function systematic(screens, g = G) {
  const fresh = screens * g.decisionsPerScreen * g.newDecisionRatio * g.decisionNew;
  const reference = screens * g.decisionsPerScreen * (1 - g.newDecisionRatio) * g.decisionReference;
  const maintenance = screens * g.maintenanceRatio * g.decisionsPerScreen;
  return { setup: g.setup, fresh, reference, maintenance, total: g.setup + fresh + reference + maintenance };
}

console.log("screens  systemless decisions  inconsistency debt  systemless total  systematic total  diff");
for (const e of [1, 2, 3, 5, 8, 10, 15, 20, 30, 50]) {
  const a = systemless(e);
  const b = systematic(e);
  console.log(
    `${String(e).padStart(7)} ${a.decisionCost.toFixed(1).padStart(19)} ${a.debt.toFixed(1).padStart(20)} ` +
      `${a.total.toFixed(1).padStart(17)} ${b.total.toFixed(1).padStart(17)} ${(a.total - b.total).toFixed(1).padStart(6)}`
  );
}

function breakEven(g = G) {
  for (let e = 1; e <= 2000; e++) {
    if (systemless(e, g).total >= systematic(e, g).total) return e;
  }
  return null;
}
console.log(`\nbreak-even screen count (base inputs): ${breakEven()}`);

// Sensitivity: how much does each input move the break-even point?
console.log("\ninput                   value  break-even screen");
const trials = [
  ["setup", [45, 90, 180, 360]],
  ["deviationProbability", [0.05, 0.1, 0.2, 0.4]],
  ["decisionsPerScreen", [6, 12, 18, 30]],
  ["decisionNew", [0.35, 0.7, 1.4]],
];
for (const [key, values] of trials) {
  for (const d of values) {
    const g = { ...G, [key]: d };
    console.log(`${key.padEnd(23)} ${String(d).padStart(6)} ${String(breakEven(g)).padStart(17)}`);
  }
}

// Effect of team count on deviation probability: each additional team is an
// independent source of interpretation.
// q is the probability that a single team interprets a decision differently.
const q = 0.08;
console.log("\nteams  deviation prob  break-even screen  expected distinct values at 20 screens");
for (const n of [1, 2, 3, 4, 6, 8]) {
  const p = 1 - Math.pow(1 - q, n);
  const g = { ...G, deviationProbability: p };
  const distinct = 1 + (20 - 1) * p;
  console.log(
    `${String(n).padStart(5)} ${p.toFixed(3).padStart(15)} ${String(breakEven(g)).padStart(19)} ${distinct.toFixed(2).padStart(36)}`
  );
}

// When does a single decision pay off entering the system? For a decision used u times:
//   systemless = u * decisionNew,  systematic = definition + u * decisionReference
const DEFINITION = 1.5; // cost of naming, documenting, and publishing a decision
console.log("\nusage  systemless  systematic  pays off?");
for (const u of [1, 2, 3, 4, 6, 10]) {
  const a = u * G.decisionNew;
  const b = DEFINITION + u * G.decisionReference;
  console.log(`${String(u).padStart(5)} ${a.toFixed(2).padStart(11)} ${b.toFixed(2).padStart(11)}  ${a >= b ? "yes" : "no"}`);
}
console.log(`usage threshold: ${(DEFINITION / (G.decisionNew - G.decisionReference)).toFixed(2)} -> ${Math.ceil(DEFINITION / (G.decisionNew - G.decisionReference))} uses`);

// Retroactive fix: how much debt has accumulated by the time the system is built late?
console.log("\nscreen system is built at  debt accumulated by then (hours)  debt-to-setup ratio");
for (const e of [1, 5, 10, 20, 40]) {
  const debt = systemless(e).debt;
  console.log(`${String(e).padStart(26)} ${debt.toFixed(1).padStart(31)} ${(debt / G.setup).toFixed(2).padStart(19)}`);
}

screens  systemless decisions  inconsistency debt  systemless total  systematic total  diff
      1                12.6                  0.0              12.6              94.9  -82.3
      2                25.2                  5.4              30.6              99.7  -69.1
      3                37.8                 10.8              48.6             104.6  -56.0
      5                63.0                 21.6              84.6             114.3  -29.7
      8               100.8                 37.8             138.6             128.9    9.7
     10               126.0                 48.6             174.6             138.6   36.0
     15               189.0                 75.6             264.6             162.9  101.7
     20               252.0                102.6             354.6             187.2  167.4
     30               378.0                156.6             534.6             235.8  298.8
     50               630.0                264.6             894.6             333.0  561.6

break-even screen count (base inputs): 8

input                   value  break-even screen
setup                       45                 4
setup                       90                 8
setup                      180                15
setup                      360                28
deviationProbability      0.05                11
deviationProbability       0.1                 9
deviationProbability       0.2                 8
deviationProbability       0.4                 6
decisionsPerScreen           6                21
decisionsPerScreen          12                11
decisionsPerScreen          18                 8
decisionsPerScreen          30                 5
decisionNew               0.35                13
decisionNew                0.7                 8
decisionNew                1.4                 5

teams  deviation prob  break-even screen  expected distinct values at 20 screens
    1           0.080                  10                                 2.52
    2           0.154                   8                                 3.92
    3           0.221                   7                                 5.20
    4           0.284                   7                                 6.39
    6           0.394                   6                                 8.48
    8           0.487                   5                                10.25

usage  systemless  systematic  pays off?
    1        0.70        1.60  no
    2        1.40        1.70  no
    3        2.10        1.80  yes
    4        2.80        1.90  yes
    6        4.20        2.10  yes
   10        7.00        2.50  yes
usage threshold: 2.50 -> 3 uses

screen system is built at  debt accumulated by then (hours)  debt-to-setup ratio
                         1                             0.0                0.00
                         5                            21.6                0.24
                        10                            48.6                0.54
                        20                           102.6                1.14
                        40                           210.6                2.34

Break-Even Is the Eighth Screen

The first table puts the two curves side by side. The systematic path starts at 94.9 hours on the first screen; the systemless path finishes at 12.6 hours. At the fifth screen the difference still favors the systemless path: 84.6 against 114.3. At the eighth screen the sign flips, and by the twentieth screen the systematic path is 167.4 hours ahead.

The source of the difference is the slopes. The systemless path’s per-screen cost is 12.6 hours of decisions plus a growing debt; the systematic path’s per-screen cost is 4.9 hours. The setup cost is a one-time payment and stays fixed, so its share shrinks as the screen count grows.

The inconsistency debt column also has to be read on its own. At fifty screens the debt reaches 264.6 hours — close to three-quarters of the systematic path’s total cost (333.0). The debt line item is usually left out of the accounting because it is invisible: no one keeps a log that says “I spent 3 hours fixing inconsistency this week.” Being invisible does not mean it does not exist.

Break-Even Is Most Sensitive to Setup Cost

The second table shows how much each input moves the result, and it says where the discussion should focus.

Setup cost is the most decisive input: going from 45 hours to 360 hours moves the break-even point from 4 to 28 screens — an eightfold change in the input produces a sevenfold change in the result. This means the system’s scope is the most important decision. A system built small pays off early; a system that tries to cover everything gets abandoned before it starts paying off.

Decisions per screen ranks second: going from 6 decisions to 30 decisions brings the break-even point down from 21 to 5. This number is the interface’s complexity, and it is measured, not chosen. A low-decision interface — a single read-only screen, a single form — benefits little from a system.

Deviation probability turns out to be less sensitive than expected: raised from 0.05 to 0.40, an eightfold increase, the break-even point drops only from 11 to 6. Fear of inconsistency is the weakest way to justify a system; the real justification is the volume of repeated decisions.

Team Count Multiplies Deviation

The third table treats a single input on its own: team count. Each additional team is an independent source of interpretation. Taking the probability that a single team interprets a decision differently as 8%, the combined deviation probability across eight teams climbs to 48.7%.

The final column gives this a concrete counterpart: a single decision — say, card inner padding — spreads across twenty screens into an average of 2.52 distinct values with one team, and 10.25 distinct values with eight teams. There is no longer such a thing as “card inner padding” at that institution; there are ten separate card inner paddings, and none of them knows about the others.

The rule here is: a system is built for decisions that cross team boundaries. For decisions a single team makes within a single product, the benefit a system provides is already supplied by the team’s own memory. The system’s real job is not memory, it is shared memory.

Not Every Decision Enters the System

The fourth table gives the arithmetic that ties scope to a decision. Naming, documenting, and publishing a decision costs 1.5 hours; each use after that costs 0.1 hours of reference. In the systemless case, each use costs 0.7 hours.

The usage threshold is the definition cost divided by the per-use saving: 1.5 / (0.7 − 0.1) = 2.5, meaning three times. A decision used twice loses money if brought into the system; used three times, it starts paying off.

This ties the scope principle from the previous lesson to a number. A layout that appears once on one screen does not enter the system. What enters the system is a question asked the same way in three separate places. The rule also carries a demand for patience: a decision is not brought into the system the first time it is made, it is brought in the third time it is encountered. Premature abstraction means freezing a decision that has not yet been verified.

A System Built Late Inherits Debt

The final table answers the timing question. When the system is built at the fortieth screen, the inconsistency debt accumulated by that point is 210.6 hours: 2.34 times the setup cost. This debt is not erased automatically once the system is built; every deviated value has to be found, a decision made about which one is correct, and the value changed.

At the twentieth screen the ratio is 1.14, at the tenth screen 0.54. Because the curve grows linearly, the cost of delay is also linear; but unlike setup, paying down the debt cannot be parallelized, because the context in which each deviation arose has to be understood.

This also reveals the conditions under which a system cannot be justified. A product whose screen count will stay below the break-even point, a single-team and short-lived effort, or a discovery phase where decisions are not yet verified: in all three cases, building a system is a cost that is never recovered. In such a case the right call is not to skip the system, but to defer it and keep an inventory — logging how many times each decision repeats makes naming it cheap once the third repetition arrives.

Summary

• The system decision is a cost comparison: setup and maintenance on one side, remaking decisions and inconsistency debt on the other; both can be written in hours.
• With the measured inputs, the break-even point is the eighth screen; before it the systemless path is cheaper, after it the systematic path is.
• The break-even point is most sensitive to setup cost; this shows that scope is the most important decision and that a narrowly built system pays off early.
• Deviation probability is less sensitive than expected; what justifies a system is not fear of inconsistency but the volume of repeated decisions.
• Team count multiplies deviation: the same decision spreads across twenty screens into an average of 10.25 distinct values with eight teams; a system is built for decisions that cross team boundaries.
• A decision earns its place in the system once it has been used as many times as the definition cost divided by the per-use saving — here, three times; a delayed setup inherits the accumulated debt.

Next Step

When the calculation says a system should be built, the first task is drawing the scope, and scope cannot be drawn by estimation. Which decision repeats how many times, how many distinct forms a value is used in, and how many of those values are genuinely separate decisions — all of that can only be known by counting the existing interface. The next lesson performs that count: it extracts color, spacing, font-size, and corner-radius values from the catalog products’ style source, clusters near-duplicates by threshold to find the true decision count, and shows which share of the inventory is unearned variety.