R2.04.3Debt repayment triggerdesign

Repayment needs an explicit trigger

Aliases: repayment trigger · later is not a date · firing condition · debt ignition

What it is

“Pay it back later” is not a date and not an event. Repaying design debt needs an observable trigger: the next time this flow is touched, when a given component lands, when a class of support contacts crosses a threshold. Without a trigger, the work system never asks “is this the moment” at any step, so repayment is never pulled onto a queue. Skipping the trigger must be a visible exception, not an intention that quietly expired.

A trigger names ignition, not a wish. A wish is “when we are less busy”. Ignition is “the next time this file is opened”.

Why it happens

Planning tools pull work by events: an iteration starts, a defect arrives, a dependency merges. Repayment that belongs to no event has no hook to be pulled by. A spoken “later” depends on someone remembering, and remembering is not a step in the process. The debt then sleeps in the tracker while feature trains pass, none required to stop and check.

Observable means a skip can be caught. If the trigger is “next time someone edits Settings”, the Settings change list should have a cell asking “is this page’s debt repaid with this change”. Someone edited Settings and did not repay: the missing cell is visible. If the trigger is “when we have time”, no list ever asks whether time has arrived; skip and not-yet-happened cannot be told apart. A trigger can also be a meter (a contact class over n for two weeks), which opens a repayment ticket when the meter trips, without waiting for memory. In every case what is missing is the hook, not virtue.

Where it stops holding

An inconsistency that can still be closed inside the current iteration does not need a separate trigger; the existing definition of done is the trigger. A trigger written as an event that will never occur (“when we do the full redesign”, and the redesign is not on the roadmap) is a wish under another name. Several debts bound to one oversized trigger (“pay them all at the next redesign”) all fail to fire when that redesign is scoped down; bind each to the surface that would actually be touched. An automatic trigger with no cap will flood repayment tickets from meter noise; it needs cooldown or merge rules, or the trigger itself becomes noise.

Applying it

  • Every open design-debt ticket writes one observable trigger: which surface next changes, which dependency lands, which meter crosses which line. A ticket that cannot write that sentence is not finished being filed.
  • Embed the trigger in the matching change check: a pull request or walkthrough for that surface has a cell asking “debt on this surface handled or explicitly skipped”.
  • A skip must leave a record (who, which change, why not this time), and the same trigger must ask again next time.
  • How to check: sample five still-open design-debt tickets. If the next step is “later” with no event, filing failed. Then find a trigger that already fired (that surface was in fact edited): if the change record has neither “repaid” nor “explicit skip”, the hook was never installed.

Related

  • Same group: R2.04.1 Unrecorded temporaries become permanent · R2.04.2 Design debt must be handled like engineering debt
  • Adjacent: R2.11 Identifying and repaying design debt · R2.12 Design–engineering cadence
  • Search terms: repayment trigger · later is not a date · observability · design debt

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/R2.04.3