Sorting hat design
Sorting hat design is the work of building an in-product question flow that asks users a few questions up front and routes them, based on their answers, into the downstream experience that fits what they're trying to do. The work involves figuring out which user differences actually matter for routing, laying those differences out as a branching tree that resolves them in as few questions as possible, and writing each question in language users can answer plainly.
Definition
The three-step construction arc that turns validated intent clusters — filtered to intents the offering can actually serve — into a deployable sorting hat.
What the arc takes as input
The arc consumes the output of upstream intent clustering work: a set of validated intent categories, each with its characteristics already sorted into the Essential / Expected / Related tiers from condition tiering. Sorting-hat work operates on Essential and Expected conditions; Related conditions are too loose to bucket users against reliably.
Construction begins by filtering the category set. Categories whose intents the offering can't actually serve are dropped, per the qualification function of intent detection. Routing users into branches that lead to mismatched paths is extractive — the user is better served being told the offering isn't built for what they're trying to do than walked deeper into the wrong territory.
The three steps
-
Identify tell conditions. Across the tiered conditions, find the subset whose values vary meaningfully from category to category. Conditions shared across all categories don't sort; only the discriminating conditions do. This is the discriminating-conditions move applied at the cluster level rather than within a single cluster.
-
Construct a branching tree. Build the smallest tree that produces reliable classification — each additional question carries attrition cost — by choosing early questions whose answers collapse multiple categories at once. If product-is-post-launch is true for some categories and false for others, an early question on launch status excludes a whole cluster of categories cleanly; later questions resolve what remains. The discipline is algebraic — find the sequence that resolves the most categories per question — not exhaustive, which would check every tell condition individually.
-
Translate condition-checks into user-facing questions. Each tell-condition check becomes a question the user actually sees. The translation honors the factual-circumstances commitment (ask about what's true of the user's situation, not their mental state or identity), and each question requires an input-mode decision (preformed options, freeform text, or hybrid). Beyond those commitments, the wording craft is making questions answerable accurately and willingly — awkward, leading, or self-presentation-inviting wording produces instruments that classify users by their projected identity rather than their actual circumstances.
Disciplines that run across the arc
Three sibling disciplines apply throughout the arc, not just at the step where they first surface:
- Factual-circumstances questions over mental-state questions — surfaces in Step 3 but constrains tell-condition selection upstream as well.
- Input modes — the preformed / hybrid / freeform choice has different information-yield, friction, and intent cluster signal properties; the right choice depends on where the offering sits on the cluster-discovery maturity curve.
- Per-question attrition cost — every question in the tree carries measurable drop-off cost, which is what makes Step 2's "smallest tree" discipline structural rather than aesthetic.
Each step inherits the prior
Weak cluster discovery produces categories that don't actually segment intent. That yields tell conditions that don't discriminate. That yields questions classifying users into buckets that don't reflect what they're trying to do. Output quality reflects input quality at every transition; the arc has no step that can recover what an earlier step didn't get clean.
Example
A product-analytics SaaS runs cluster discovery and validates three intent categories: pre-launch founders validating an idea, post-launch founders tracking early retention, and growth teams at established companies optimizing conversion.
Step 1 — tell conditions. Across the tiered conditions, three vary meaningfully across categories: launch status, team size, and current measurement focus. Pricing tier, integration depth, and self-reported industry are shared widely enough that they don't sort.
Step 2 — branching tree. Launch status is the cleanest first cut — one answer eliminates the pre-launch category entirely. Among post-launch users, team size separates solo founders from growth teams. Two questions resolve all three categories.
Step 3 — translation. "Is your product launched yet?" honors the factual-circumstances commitment — it asks about a checkable fact, not the user's self-identification as "early-stage" or "scaling." The post-launch follow-up uses preformed options ("just me" / "small team" / "larger team") rather than freeform, because the three categories are stable and well-validated enough that a preformed input mode is appropriate.
A user answering "not launched yet" routes to the pre-launch path; "launched, just me" routes to the solo-founder retention path; "launched, larger team" routes to the growth-team conversion path.