Ship good enough, and write the debt down

6.4aSatisficing, and why it ends the searchsrc 01

Herbert A. Simon introduced satisficing · thỏa mãn vừa đủ in a 1956 paper: choosing the first option that reaches a set level, in place of comparing every option for the best. As I read his paper, the path he describes clears a set level on each of the organism's needs, with no search for the best. Three things make it sound for a team that ships:

• The level comes before the search. A bar named in advance says when to stop. "Best" never does, because one more option can always be compared.
• Every need gets a level. I read the level on each need as the strict half of the rule: !no need is allowed to go unmet.Surprising: I expected satisficing to mean lowering the bar. Simon's version keeps a bar on every need, so it rules out shipping with one need unmet.
• The best is unknown at ship time. In my reading, the best design depends on use that has not happened yet, so polishing toward it is a guess.

6.4bThe floor, and the debt above itsrc 02

Satisficing needs a floor first: the needs no bar may drop below, such as safety, the core task and the accessibility level the team commits to. As I read it, a gap there locks people out, so it cannot be traded for time.

Above the floor, every shortfall is UX debt · nợ UX. Anna Kaley defines it as ongoing problems in the experience "due to launching a fast, easy, or careless solution," modeled on the technical debt Ward Cunningham devised in 1992.

• It compounds. The longer it stays unpaid, Kaley writes, the more its costs mount; she compares it to ?compound interest.Confused: If debt compounds, at what size should a team stop borrowing and spend a whole sprint repaying?
• Unwritten debt is invisible. Her process starts with tracking: a backlog item with the same severity scale as other work, or a spreadsheet first.

6.4cFour moves that ship good enoughsrc 02

1. Name the floor first. Write down the needs that cannot drop. A floor named after the work tends to match whatever the work reached.
2. Set the bar above it. One line per area on what good enough means there: the stopping rule from 6.4a.
3. Log each gap as UX debt. Use Kaley's columns: the issue in the user's words, where it occurs, how often, who reported it, and the effort to fix. ★One item per shortfall.Actionable: On my next release, add a 'shipped short' label to the backlog and file every known gap under it before launch.
4. Book the repayment. Kaley suggests at least one or two debt items a sprint, a quarterly cleanup sprint, or a single "cheese day." A gap with a date stays a decision the team made.

6.4dAt work: three situationssrc 03

• "One more week and it will be perfect." That week is a search with no stopping rule. I ask which need still sits below its bar. If none does, we ship and log the rest.
• A known contrast failure is on the release list. Contrast belongs to the floor. →I fix it, or a named person accepts it in writing.Connection: Same test as 6.4b: a floor item cannot move to the debt log quietly; someone has to sign for it.
• "We'll crunch to get it all in." The Agile principles say sponsors, developers and users should be able to "maintain a constant pace indefinitely." I read a polish crunch as borrowing from the next release.

6.4eAmazon returns page, 2018src 02

Kaley reports a return of four pairs of pants where the shipping page said 2 items and the refund summary said 3. The user went back to check the refund.

6.4fSymantec press release, 2018src 02

The body text of a Symantec press release measured 3.2:1 against its background. WCAG calls for 4.5:1 on normal-size text, so the copy was not accessible.