Guided selection tracks

What the Tracks screen manages — and why the buyer experience is a guided path rather than a filter.

What it is

A track is a persona path through the guided selection flow: an ordered sequence of factors tuned to one kind of buyer (homeowner, architect, contractor, …), published at /select/<slug>. The track decides which questions its audience is asked and in what order; the answers feed the recommendation engine, which converges on a recommended system plus right-sized alternatives.

Tracks have a lifecycle — draft (admin-previewable at its real path), published (buyer-routable), retired — so a path can be built and reviewed before anyone is sent down it.

Why it exists

The root failure in door selection is uninformed choice under complexity: an open filter hands a novice dozens of undifferentiated options and no framework to evaluate them. A guided path externalises that framework — it sequences the decisions, teaches each trade-off at the moment it's asked, carries context forward, and terminates in an answer instead of an endless comparison ("guide, don't just filter" — see why it works).

Tracks exist as first-class, admin-editable entities because different audiences need different scaffolding: the questions an architect needs differ from a homeowner's. Making the path data rather than code lets product experts add or tune a persona path without a deploy — and lets experiments test one path against another.

In the admin

Screen	How-to
Tracks	Managing tracks

Learn more

• Guided-selection stepper — the buyer-facing flow mechanics.
• Track conditional display — showing/hiding steps by prior answers.
• Recommendation API — what a completed track produces.