Main idea

An upcoming billing instalment appears in a customer's payment schedule. Yet it doesn't exist as a document: it will only have an existence of its own at the moment the invoice is issued. Immediate consequence — it is absent from search results. The user, though, saw it on screen; they look for it, don't find it, and open a ticket.

This isn't a one-off defect, it is an entire family of complaints, handled case by case for years by a support team that has no formulation of the cause. Each ticket is closed on an improvised explanation, and the next one starts over.

The origin is a gap between two models: what the interface shows and what the product handles as objects. A thing seen by the user is an object for them, whatever its technical existence.

Why it matters

This provides an enumeration angle in its own right: go through what the user handles every day and check that each element exists somewhere as a product object. Screens bring back what neither the code nor the database flags.

It also changes how repetitive tickets are treated: a family of complaints with no written cause is the signal of a missing model, not a volume to absorb.

Nuances and limits

Not everything displayed has to become an object: a total, a display grouping, a summary line can stay views without anyone suffering. The test isn't presence on screen, it is whether the user needs to find the thing again, talk about it, or act on it.

And the fix isn't necessarily to create the object: naming the ambiguity and explaining it in the interface may be enough.

Open questions

• How do you spot these cases other than by reading the screens one by one, on a product that has several hundred of them?