Carrying a Recommendation Into the Next Screen

01 / 05

A correct recommendation can still lead to a poor journey

The selector used the intended setting, room conditions, handedness and experience goals to recommend a model. The old Builder link opened the generic entry point. The person then had to rediscover the choice they had just made, at exactly the point where the product should have reduced their uncertainty.

Browser testing exposed another layer: the Builder could restore a saved later step. Simply preselecting the recommended device was insufficient if the customer landed beyond the room check. The transition needed a clear precedence rule for incoming context and saved local state.

02 / 05

Carry only the context the next flow understands

The recommendation links used an allowlisted public model identifier. The Builder accepted the known identifiers and ignored unknown values, rather than treating an arbitrary query parameter as a valid configuration. The handoff did not import a price, a completed compatibility judgment or permission to check out.

A valid recommendation entered custom configuration at the first room step and selected the suggested model as the starting point. The UI identified the selector as the origin of that suggestion. Room dimensions could still require a different result.

03 / 05

Starting over must clear every source of the old decision

The reset action cleared both the recommendation context and the URL parameter. Clearing only the in-memory selection could allow a reload to resurrect the recommendation from the address. Clearing only the URL could leave the local configuration looking as if the customer had already made a choice.

The product copy used starting point rather than final confirmation. That was a technical distinction expressed in the interface: a recommendation was useful evidence for a choice, while room size, mounting position and usage constraints still determined fit.

04 / 05

Reproduce the stale state before judging the fix

The local production-build browser check saved a later Builder step, then entered with a valid recommendation. It verified that the flow returned to the first room step with the intended device selected. The implementation also passed its focused checks, type checking and candidate production build.

The September 2 record explicitly describes a feature-branch candidate that had not yet been merged or published to the stable test site at that point. I describe that evidence as candidate implementation and local acceptance. The public interface image supplies product context, not proof that this exact candidate was deployed on that date.

05 / 05

Define precedence across navigation boundaries

This was a small feature with a broader state-management lesson. An incoming recommendation, a saved draft and the current physical constraints are three different authorities. Making their precedence explicit kept useful context without letting it bypass the checks that make the recommendation safe to act on.