Zero problems should not need a dashboard section.
There were no duplicate guests to review. The interface still gave the restaurant owner a paragraph about it.
this is tech jargon that restaurant owners would feel confused with.. these operations just need to happen as an amazing UX and backend
The customer screen had a section called Quality control. Inside it: Duplicate review. Then a paragraph about records, merging, and audit history. After all of that, the useful information was zero candidates.
Nothing needed doing. We had still given the restaurant owner something to read.
See the original requestFrom the development record
An empty exception list is a state.
A diagram of the display decision described in the development record. Customer captures are omitted because they contain contact details.
- 01
Check possible overlaps
Evaluate whether there is a useful candidate pair to review.
- 02
Show the appropriate state
With no candidates, keep the customer list quiet. With a candidate, offer a comparison. A failed check is a separate state.
- 03
Confirm before combining
If the person chooses to merge, explain which profile stays and refresh the list after the operation.
The goal is less noise without hiding real work. Both branches need review.
The original request27 Apr 2026 · excerpt
this is tech jargon that restaurant owners would feel confused with.. these operations just need to happen as an amazing UX and backend
Excerpted from the development conversation. Punctuation is lightly edited; the surrounding story is an edited retrospective.
01
The most useful screenshot is the one with less in it.
I do not want a restaurant owner to learn the internal organisation of my code before using their guest book. Quality control and duplicate review described the implementation’s concerns. In the ordinary state, there was no guest decision to make. The AI task became much clearer once I named that mismatch: preserve the matching capability, but only ask for attention when there is a useful possibility to review.
That is why hiding the empty section was more precise than deleting the feature. With no candidates, the person can carry on with customers. With a possible overlap, the interface can show the two profiles and ask a deliberate question. The amount of friction should follow the consequence of the action. Reading a customer list and combining customer records should not require the same level of ceremony.
02
Quiet by default, deliberate at the decision
The actual merge still needed care. The review used a side by side comparison, followed by explicit confirmation of which profile would stay and which would be merged into it.
Those states deserved different amounts of attention. With nothing to review, the interface could stay quiet. Before combining guest information, it needed to slow down and show the consequence clearly.
03
The final state is part of the interaction.
After a merge, the customer view had to refresh. Otherwise the user could do the careful part correctly and still see the old pair of records. That creates an especially frustrating kind of doubt: did the action fail, or is the screen behind? The recorded implementation reused the existing audited operation and brought its result back into the visible list.
For this review I care about both states. Zero useful matches should not create a maintenance task. A real match should explain which information remains before confirmation. A failed load would be a different state again; silence must not pretend a check succeeded. The saved browser check established that the empty section and its jargon were gone. The focused merge checks covered the operation behind that quieter normal view.
Removing visual noise helps the current task stay visible. I return to that question in Let the answer change the interview. Keep the question still.
Where this chapter landed
What changed.
Empty duplicate review was hidden. Useful matches retained comparison and explicit merge confirmation, with the refreshed result reflected in the customer screen.
Added while revisiting this story · September 2026
The thinking behind the detail.
Research notes to take these decisions further. These sources were reviewed for this retrospective.
A changed result should be perceivable
W3C explains how status updates can be communicated to assistive technology without moving focus. After a merge, the refreshed result should be understandable beyond the visual removal of a row.