Appearance
Why it works
This section makes the empirical case for NanaSelect: why the guided-selection experience is shaped the way it is, grounded in human factors and usability research, and how we intend to prove it with data. It's what lets the POC be defended as empirically sound rather than asserted.
Two framing pages:
- This page — the rationale: each major design decision traced to a vision principle and the human-factors reasoning behind it.
- Measurement plan — the hypotheses we intend to support or refute, the metrics that test them, and the end-to-end path from a visitor's clicks to a bid outcome.
Plus the function explanations — what each part of the system is and why it exists, one page per domain, paired with the task-oriented how-tos (#672):
- The product catalog — systems, attributes, categories, factors.
- Right-sizing — the rules and the cost-tier ladder.
- Guided selection tracks — persona paths through the flow.
- Experimentation — A/B testing tracks and presentations.
- Presentation & theming — runtime look-and-feel.
- Content & media — pages, chrome, media, corpus, tagging.
- The Drupal relationship — one-way bulk ingestion from nanawall.com.
- The DAM spin-off framework — media stays in-app; the triggers that would change that.
- The lead lifecycle — leads and the Eloqua hand-off.
- Privacy & data governance — consent, retention, erasure.
- Admin governance — users, audit, analytics.
The problem we're designing against
The root failure in door selection is uninformed choice under complexity. A buyer faces dozens of systems differentiated by attributes they don't yet understand (operation type, thermal and acoustic performance, wind load, sightlines), and the traditional tools make it worse:
- An open filter hands the user a pile of undifferentiated options and no way to know which trade-offs matter — high cognitive load, no endpoint, easy abandonment.
- A sales-led path optimises for the seller's margin, which pushes toward over-specification — a system more capable (and expensive) than the job needs, which is exactly what gets value-engineered out at bid.
Every design decision below is a response to one of those two failures, and each traces to a product principle.
Decision → principle → evidence
Educate through every step · Principle 1
Decision: each question teaches the trade-off it asks about — why the option matters — rather than just collecting a value.
Why: this is a direct application of the paradox of choice and cognitive-load research (Iyengar & Lepper; Sweller): people presented with many options and no framework to evaluate them experience choice overload, lower confidence, and higher abandonment. Teaching the criterion at the moment of the decision (contextual, just-in-time learning) reduces extraneous load and raises decision confidence. An informed "yes" is more durable than a guessed one — it survives the scrutiny of a later bid.
Right-size, don't up-sell · Principle 2
Decision: steer to the most cost-appropriate system that genuinely meets the requirements, and actively surface cheaper alternatives that suffice.
Why: over-specification is the failure mode with the largest downstream cost — an over-spec'd system is the one that loses at value engineering, sometimes to a competitor. Anchoring the recommendation to sufficiency rather than capability aligns the tool with the buyer's real interest, which builds the trust that makes the recommendation persuasive. Behaviourally, surfacing a "good-enough, cheaper" option counters the up-sell anchor and reframes the decision around fit. "A right-sized spec is the one that survives value engineering."
Guide, don't just filter · Principle 3
Decision: a linear, decision-driven path that converges on a single recommendation, rather than an open filter that leaves options undifferentiated.
Why: a guided path externalises the evaluation framework the novice lacks — it sequences decisions, carries context forward, and terminates in an answer. This is the difference between a recognition task (pick from a structured, explained sequence) and a recall/evaluation task (compare N options on M unfamiliar attributes yourself). Recognition is dramatically lower-effort, which is why a guided flow has a defined endpoint and a filter does not. The measurable prediction — guided sessions reach a recommendation where filter sessions abandon — is the first hypothesis in the measurement plan.
Meet the expert where they are · Principle 5
Decision: a fast path for professionals who already know the system, without forcing them through the full guided flow — while still nudging them past mis-specification.
Why: expertise changes the optimal interaction. Forcing an expert through novice scaffolding is friction that reads as condescension and drives abandonment; the guided flow is scaffolding for those who need it, not a toll for those who don't. The nudge remains because even experts mis-specify — the tool's value to them is the right-sizing check, not the education.
Standalone, but connected · Principle 4
Decision: own the selection logic and product data as a clean service; borrow Drupal's imagery, PDPs, and the configurator over JSON rather than rebuilding them.
Why: this is an architecture decision in service of the experience — it lets the selection flow evolve at its own pace with modern tooling and a selection-oriented data model, while reusing the rich content that already exists. NanaSelect ends at the recommendation and is a pathway into the configurator and resources, not a replacement (see the non-goals).
What "it works" would mean
The rationale above is a set of falsifiable bets, not settled fact. "It works" is not an assertion — it's the state where the metrics in the measurement plan confirm the predictions: guided sessions converge instead of abandoning, cost-appropriate alternatives get surfaced and taken, and recommended specifications trend down toward sufficiency without hurting fit. The next page describes exactly how we'll know.