The Problem Reported Is Not Always the Problem

A recent review note appeared to identify two problems in a live commerce experience.

The first was that a logo seemed to lead to the wrong place. The second was that only three products appeared to be available.

Both observations were useful. Neither diagnosis was quite complete.

The broader storefront logo already led to the store. A second brand mark inside a collaboration experience returned to the beginning of that collaboration. The destination was intentional, but the control did not explain itself clearly enough.

The three products were also intentional: a selected set representing three categories. The larger catalog and checkout remained available. But the presentation did not make the difference between featured and available obvious.

The report was accurate as experience even though its implied diagnosis was incomplete.

That distinction matters.

When someone says the logo goes to the wrong place, I can defend the route because it matches the specification. Or I can hear the more useful information: the interface created an expectation and then violated it.

When someone asks why there are only three products, I can explain the assortment strategy. Or I can recognize that the strategy failed to announce itself.

The person is telling us what the system made available to perceive.

That is evidence.

It does not automatically tell us which layer should change.

A report may point toward routing, labeling, information architecture, inventory, content strategy, or an expectation established somewhere earlier in the journey. Acting on the first interpretation can create new problems while leaving the actual confusion intact.

This is why I want to separate observation, inference, and authorization.

The observation: the mark behaved unexpectedly.

The inference: it must be linked incorrectly.

The diagnosis: two similar marks were doing different jobs without enough distinction.

The authorization: still a separate decision about whether and how the live experience should change.

That last separation protects the work from frantic correctness. A text message can contain valuable evidence without becoming permission to redesign a functioning journey immediately.

The same discipline applies when working with agents. An agent can inspect the live page, compare implementation records, and locate the behavior quickly. Speed makes it easier to jump from report to repair. The useful role is more demanding: preserve the report, test the implied cause, identify the smallest responsible change, and keep the boundaries of authority visible.

Sometimes the bug is technical. Sometimes the system is doing exactly what we told it to do and communicating that decision poorly.

Those are different failures.

The first asks for correction. The second asks for clarity.

Both begin by believing the person who encountered the problem. Belief does not require treating their first explanation as the final architecture of the fix.

The report belongs in the evidence. The diagnosis belongs in the work.

Good revision keeps them connected without pretending they are the same thing.