Skip to content

ADR-0005: Casual flow (UC-13) is a parallel track to Builder (UC-9), not a sub-mode of Browse

Context

The original design spec (2026-04-25) framed 961tech as two modes sharing one backend: a compatibility-checked PC Builder and a multi-category Browse & Compare. Both modes were peer experiences in the spec.

The use-case model produced for the M1 prototype, however, encoded only the Builder mode as a first-class flow (UC-9 anchors the Build & Configure group, with UC-B compat, UC-10 templates, UC-11 per-retailer cart, UC-12 aggregator, etc.). The Casual mode was implicit — a casual buyer was assumed to traverse UC-1 Browse catalog → UC-A Search → UC-2 Buy via deep-link, with no path-specific UX.

Persona research (#36, merged 2026-04-27) surfaced this as the structural pain of the Casual parts customer persona: forced into builder UX they don't want, landing on a "build a PC" site when the goal is to buy a thing (laptop, prebuilt, monitor, gaming chair, peripheral). The persona doc flagged this as severity-3 ("Casual-only acute") in the cross-cutting pain matrix and committed to a follow-up use-case ticket.

That ticket is #51. Three modelling options were on the table when writing it:

  1. Filtered subset of UC-1. Treat Casual as "UC-1 Browse catalog with a different filter shape and a hidden compat panel." No new UC; the difference is presentation only.
  2. Extension of UC-9. Add a «casual» flag to UC-9 Build a PC that disables compat, templates, and the build cart. One UC, two configurations.
  3. Parallel peer use case. A new UC-13 "Browse & buy single product" that anchors a Casual track sitting beside the Builder track. Both tracks share Discovery & Browse and Conversion; neither is subordinated to the other.

Decision

Casual flow is modelled as UC-13, the anchor of a Casual track that runs parallel to the Builder track (UC-9). Both tracks are peer entry points for Visitors. Neither is a sub-mode of the other. Both consume shared Discovery & Browse use cases (UC-1, UC-A, UC-3..UC-8, UC-E, UC-F, UC-I) and resolve through the shared Conversion use case (UC-2 Buy via deep-link).

Landing role. The Casual track (UC-13) anchors the primary landing; the Builder track (UC-9) is a co-visible secondary entry from the same homepage. Both tracks are visible the moment a Visitor lands — neither is hidden behind navigation — but the homepage gives Casual the dominant surface and gives Builder a prominent, equally-accessible secondary CTA. The model stays peer-symmetric; the landing page's promotion is asymmetric. Rationale: the larger Lebanese audience is buying single discrete products (laptops, prebuilts, peripherals), not assembling desktops. Builder is the moat — narrower audience, deeper engagement, harder-to-replace value — and stays one click away, never demoted.

The use-case diagram and narrative in use-cases.md reflect this with two named track groups ("Builder track" anchored on UC-9, "Casual track" anchored on UC-13) — explicitly peers, not nested. The landing priority is a homepage-design constraint that flows from this ADR into #28 page design; it does not alter the peer-symmetric use-case model.

Consequences

Positive

  • Removes the structural pain. The Casual persona is no longer routed through UC-9. There is now a use-case path for "I want to buy a laptop" that doesn't pass through a builder.
  • Frees #28 page design to fork the homepage and navigation by track. Builder landing and Casual landing can have different layouts, different CTAs, different filter rails, without one being styled as a degraded version of the other.
  • Lets #24 laptops and #25 prebuilts attach to a real use-case anchor when they ship in M3, instead of being grafted onto UC-1 / UC-9 awkwardly.
  • Matches the aggregator design spec's explicit "two modes" framing — the use-case model now agrees with §3.1 of the spec instead of silently demoting one of the two modes.
  • Compatibility (UC-B) stays out of the Casual flow by construction. Modelling Casual as a sub-mode of UC-9 would have left compat semantically attached to the casual product page; modelling it as a peer makes its absence intentional and documented.

Negative

  • One more anchor UC to keep design and code aligned with. /build (anchored on UC-9) and the future Casual surface (anchored on UC-13) need consistent navigation conventions, sign-in handoff, and analytics so the two tracks don't drift into two products.
  • Marketing surface area increases. A landing strategy that respects both tracks (instead of just promoting the Builder moat) is a harder copy and SEO problem than a single-flow site.
  • Asymmetric homepage promotion is a real design problem. Casual gets the dominant surface on the landing page; Builder is co-visible but secondary. Getting that hierarchy right without burying the moat is harder than either "Builder-first homepage" or "perfectly symmetric two-column homepage" would be. #28 page design inherits this constraint.

Neutral

  • No code change yet. UC-13's catalog (laptops, prebuilts, peripherals) is M3-deferred; the use-case model lands now so #28 and the M3 category tickets can build against it, but no flow ships under it until M3.
  • Save (UC-C), Share (UC-D), and Price drop alerts (UC-G) remain Builder-track only at v1. Persona research characterises Casual as one-shot — they do not motivate a wishlist/alert UC for Casual at this stage. Revisit when telemetry or feedback says otherwise.

Alternatives considered

Alternative A: Filtered subset of UC-1 Browse catalog

Treat Casual as "UC-1 with laptop-shaped filters and a hidden compat panel." No UC-13.

Rejected because: it masks the design pressure. The Casual flow needs a different homepage, a different navigation model (brand-first for laptops/peripherals; not category-first for components), a different product-detail page (no compat, no build sidecar, tax-inclusive default), and different filter affordances (screen size + brand line, not CPU socket). Modelling all of that as "UC-1 with parameters" hides the fork from anyone reading the use-case diagram and pushes the divergence into per-page implementation details where it's easy to miss.

It also leaves UC-2 Buy via deep-link as the only path-specific casual touchpoint — which is true at the conversion moment, but not before. Most of the casual UX happens before UC-2 fires.

Alternative B: Extension of UC-9 with a «casual» mode flag

Make UC-9 the universal "shopping" UC, with a flag that toggles compat, templates, and the build cart off for casual sessions.

Rejected because: it inverts the modelling — Builder is the moat, the harder-to-build flow with the compat DB and rules engine. Subordinating Casual to UC-9 would make the simple, single-item flow look like a stripped-down Builder rather than its own thing. It also makes UC-9's invariants harder to reason about: every consumer of UC-9 has to handle the casual-mode branch, even when compat is the entire point of the use case.

The deeper objection is product-strategic. The aggregator design spec frames Builder and Browse & Compare as two parallel experiences, not "Builder with a degraded mode for non-builders." Subordinating Casual to UC-9 contradicts that framing.

Alternative C: A wishlist UC (UC-W "Save product to wishlist") at the same time

Add an account-bound wishlist UC alongside UC-13, mirroring UC-C Save build for the Casual track.

Rejected for v1 because: persona research characterises Casual as single-item, one-shot, hours-to-days from search to checkout. Casual buyers do not currently motivate a wishlist UC. Building UC-C's Casual analog now would be inventing demand. Revisit in M3 once telemetry confirms (or refutes) one-shot session shape.

References