The walkthrough
61.4 seconds. Captions are burned in; an
.srt and .vtt sit beside the file.
The friction, as reported
“It saves users’ time from having to open the payment individually to check the customer’s name.”
Verbatim from the Xero Product Ideas board. Reproduced as a contiguous extract and checked against the harvested record.
What the walkthrough shows
- Row two names its payee. This row will not.
- The same row now names the payers it holds.
- Row height has not changed. The list still scans.
- The chip opens all five payers in place.
- They sum to 3,105.00, and the page stayed put.
- The next line pays 217 suppliers in one batch.
- It names three of them and counts the rest.
- 217 rows would not fit, so the panel scrolls and searches.
- Same mechanism. Payers on one row, payees on the other.
- The batch reconciles from the row, with no detour.
The assessment
The opportunity.
The names were already in the data. Only the row was withholding them.
The cheapest change in this set, and the one nothing argues against.
The reasoning
The job is real, the data already exists, the permission surface is unchanged, nothing else on the screen is disturbed, and Xero has already Accepted the same principle for the reference line at 65 votes.
There is no second-order cost to find here, and it would be dishonest to manufacture one.
The 200-payer case is a truncation problem, not a reason to reshape. Three names and a count still is customer names instead of “multiple items” — the placeholder is gone, and the common case of three to ten payers is fully answered without leaving the row. Calling that a reshape would be over-thinking a genuinely small fix.
Worth stating plainly: this is the cheapest idea in the selection and probably the highest ratio of relief to work. Not every real request is a hard one.