Skip to content

Use cases — who can do what

What this answers: which actors interact with 961tech and what each can do, with the relationships between use cases («include», «extend», generalisation).

The drawio version is the source of truth — see diagrams/01-use-case-diagram.drawio. The PNG is the rendered view embedded below; the mermaid block beneath is the same diagram in text form, useful for diff'ing changes and as a fallback when drawio isn't available.

Use case diagram

graph LR
    Visitor((Visitor))
    Builder((Builder))
    Retailer((Retailer))
    Operator((Operator))
    RSite[("Retailer Site<br/>external")]
    Mail[("Email Service<br/>external")]

    Builder -.->|generalizes| Visitor

    subgraph SYS["961tech System"]
      direction TB
      subgraph DISCOVER["Discovery & Browse"]
        UC1(UC-1<br/>Browse catalog)
        UC3(UC-3<br/>See min info<br/>on cards)
        UC4(UC-4<br/>Filter products)
        UC5(UC-5<br/>Filter by stock)
        UC6(UC-6<br/>Quote-only<br/>price range)
        UC7(UC-7<br/>Filter by retailer)
        UC8(UC-8<br/>Retailers<br/>per product)
        UCA(UC-A<br/>Search catalog)
        UCE(UC-E<br/>Compare 2+)
        UCF(UC-F<br/>Price history)
        UCH(UC-H<br/>Build guides)
        UCI(UC-I<br/>Retailer profile)
      end
      subgraph BUILD["Builder track"]
        UC9(UC-9<br/>Build a PC)
        UCB(UC-B<br/>Compat check)
        UC10(UC-10<br/>Templates)
        UC11(UC-11<br/>Per-retailer cart)
        UC12(UC-12<br/>Cart aggregator)
        UCC(UC-C<br/>Save build)
        UCD(UC-D<br/>Share build)
        UCG(UC-G<br/>Price drop alerts)
      end
      subgraph CASUAL["Casual track"]
        UC13(UC-13<br/>Browse & buy<br/>single product)
      end
      subgraph CONVERT["Conversion"]
        UC2(UC-2<br/>Buy via deep-link)
      end
      subgraph OPS["Operator & Backend"]
        UCJ(UC-J<br/>Admin tools)
        UCL(UC-L<br/>Affiliate reconciliation)
      end
      subgraph M2["Retailer (M2)"]
        UCK(UC-K<br/>Retailer self-onboarding)
      end
    end

    Visitor --- UC1
    Visitor --- UCA
    Visitor --- UC9
    Visitor --- UC13
    Visitor --- UC2
    Visitor --- UCD
    Visitor --- UCE
    Visitor --- UCH
    Builder --- UCC
    Builder --- UCG
    Retailer --- UCK
    Operator --- UCJ
    Operator --- UCL
    UC2 --- RSite
    UCL --- RSite
    UCG --- Mail

    UC1 -.->|includes| UC3
    UC1 -.->|includes| UC4
    UC1 -.->|includes| UC8
    UC4 -.->|includes| UC5
    UC4 -.->|includes| UC7
    UC6 -.->|extends| UC5
    UCI -.->|extends| UC8
    UC9 -.->|includes| UCB
    UC9 -.->|includes| UC11
    UC10 -.->|extends| UC9
    UC12 -.->|extends| UC11
    UCD -.->|extends| UCC
    UC13 -.->|includes| UC3
    UC13 -.->|includes| UC8
    UCL -.->|extends| UC2

Actors

Actor Role
Visitor Anonymous web user. Default actor. Can do most things without an account.
Builder Visitor who has signed in. Inherits all Visitor abilities + UC-C and UC-G.
Retailer Lebanese merchant who self-onboards via the backoffice. M2 deferred.
Operator MASTER. Admin / catalog curator / affiliate reconciler.
Retailer Site (external) Third-party retailer (PCAndParts, 961Souq, etc.) — receives outbound clicks and may post back conversions.
Email Service (external) Outgoing email provider (Resend planned) for price-drop alerts.

Use cases

See the Glossary for term definitions and the open issues for implementation status per UC.

Visitor + Builder (consumer): UC-1 Browse catalog, UC-2 Buy via deep-link, UC-3 See min info on cards, UC-4 Filter products, UC-5 Filter by stock, UC-6 Quote-only price range, UC-7 Filter by retailer, UC-8 See retailers per product, UC-9 Build a PC, UC-10 Templates & prebuilts, UC-11 Per-retailer cart, UC-12 Cart aggregator, UC-13 Browse & buy single product, UC-A Search, UC-B Compatibility check, UC-D Share build, UC-E Compare 2+, UC-F Price history, UC-H Build guides, UC-I Retailer profile.

Builder only: UC-C Save build, UC-G Price drop alerts.

Retailer (M2 deferred): UC-K Retailer self-onboarding.

Operator only: UC-J Admin tools, UC-L Affiliate reconciliation.

Relationships

  • Solid Actor —— UC — actor performs the use case
  • Dashed «include» UC -.→ UC — included use case ALWAYS runs as part of the parent
  • Dashed «extend» UC -.→ UC — extending use case OPTIONALLY enriches the parent
  • Dashed «generalises» Actor -.→ Actor — sub-actor inherits all parent's permissions

Two parallel tracks

961tech offers two parallel consumer tracks sharing one Discovery & Browse subsystem and one Conversion path. Neither is subordinated to the other — the Casual track is a peer of the Builder track, not a degraded sub-mode of it.

Track Anchor UC Landing role Who it serves Distinguishing feature Categories
Casual UC-13 Browse & buy single product Primary landing Buyers shopping for a single discrete object — laptop, prebuilt, peripheral, monitor No compat panel, no build sidecar; brand-first product detail; one-shot transaction Monitors (M2), laptops (#24, M3), prebuilts (#25, M3), peripherals (M3)
Builder UC-9 Build a PC Co-visible secondary entry PC enthusiasts assembling a desktop from components Live compatibility check (UC-B), per-retailer split cart (UC-11), aggregator (UC-12) CPU, GPU, MB, RAM, PSU, case, cooler, storage (all M1); monitor (M2, optional completion slot)

Both tracks:

  • Are open to anonymous Visitors (Builder generalises Visitor; sign-in adds UC-C save and UC-G alerts but is never required).
  • Consume Discovery & Browse (UC-1, UC-A, UC-3, UC-4..UC-8, UC-E, UC-F, UC-I) — these are shared infrastructure, not Builder-private.
  • Resolve through the same Conversion UC-2 Buy via deep-link.

The peer-symmetric use-case model (neither track is a sub-mode of the other) coexists with an asymmetric landing page: the homepage promotes Casual as the dominant surface and Builder as a prominent, equally-accessible secondary CTA. Both options are visible on entry — neither is hidden behind navigation — but they are not equally weighted on the landing canvas. Rationale: the larger Lebanese audience is buying single discrete products; Builder is the moat (narrower audience, deeper engagement) and stays one click away, never demoted. See ADR-0005 for the landing-role decision and the alternatives considered.

The Casual track exists because routing every Lebanese buyer through a build flow contradicts how laptops, prebuilts, and peripherals are actually purchased: brand-first ("I want a Lenovo ThinkPad" / "I want a Logitech G502"), single-item, one-shot. See Casual parts customer persona for the user-research case, and §6.1.3 for the design implications. UC-13 is the use-case anchor for that flow.

UC-13 — Browse & buy single product

Actor: Visitor (Builder inherits via generalization).

Goal. Find a single discrete product (laptop, prebuilt PC, peripheral, monitor, gaming chair) — confirm it's in stock at a Lebanese retailer at a fair price — buy it. Single-item, one-shot, no build context.

Includes.

  • UC-3 See min info on cards — name, price, retailer, stock state on every product card and detail view.
  • UC-8 See retailers per product — the multi-retailer comparison panel ("all retailers selling this Logitech G502 on one page") is the aggregator value-add for the casual buyer.

Hands off to. UC-2 Buy via deep-link — the user clicks a "Buy at retailer X" button on the single-item detail and the conversion fires.

Distinct from UC-9. UC-13 has no compatibility check, no per-retailer build cart, no templates. It is not a filtered subset of UC-9; it's a peer flow with its own landing, its own filter shape (brand + price tier + screen size for laptops; brand line for peripherals — never CPU socket or RAM speed), and its own product-detail layout (no compat panel, no build sidecar).

Categories. Monitors (M2) — the first concrete Casual-track catalog, dual-track with the Builder optional completion slot. Laptops (#24), prebuilt PCs (#25), and peripherals — all M3-deferred per ADR-0010 which locks the milestone roster. UC-13 is approved as the use-case model now so #28 page design and the M3 category tickets can build against it; M2 ships monitors only, the rest of the Casual catalog ships at M3.

Triggered by. Phone search ("best laptop under $500 lebanon"), Google ad, Instagram ad, a dying laptop, a gift purchase, a peripheral upgrade. Hours-to-days from search to checkout — not the weeks-of-research pattern of UC-9.

Why it's a peer of UC-9, not a subset of UC-1. UC-1 Browse catalog is shared infrastructure — the catalog grid, the filter rail, the card layout. UC-13 is a flow — a landing strategy, a navigation model, a product-detail variant tuned for non-builders. Treating Casual as "just UC-1 with different filters" would have masked the design pressure that the homepage, navigation, and product-detail page all need to fork by track. See ADR-0004.

Design notes

  1. Two parallel tracks (Builder + Casual). UC-9 anchors the Builder track; UC-13 anchors the Casual track. Both are peer entry points for Visitors. Neither is subordinated to the other in navigation, landing, or use-case hierarchy. See the parallel-tracks section above and ADR-0004.
  2. Builder generalises Visitor. Anyone signed in can do everything an anonymous Visitor can, plus the account-bound use cases (UC-C, UC-G). UML inheritance.
  3. Browse is shared infrastructure. UC-1 always involves seeing min info (UC-3), filtering (UC-4), and seeing retailer presence (UC-8). Filtering itself decomposes into stock-state and per-retailer filters. Both tracks consume these shared sub-UCs; UC-13 additionally «include»s UC-3 and UC-8 directly because the casual single-item detail view depends on them even when the user never traverses UC-1's catalog grid.
  4. Quote-only price estimation (UC-6) extends UC-5. When the user filters to include request-quote products, we optionally enrich those with a computed price range.
  5. Build (UC-9) is the central composite of the Builder track. Always includes compat check (UC-B) and per-retailer cart view (UC-11). Optionally extended by templates (UC-10) and cart aggregator suggestions (UC-12 extends UC-11).
  6. UC-13 is the central composite of the Casual track. Includes UC-3 and UC-8. Compatibility (UC-B) is deliberately absent — compat is irrelevant for a laptop or chair, and a stray compat warning on a single-item product page is the kind of UX seam the Casual persona is allergic to.
  7. Save extends to Share. A saved build is shareable; share is the natural extension of save. Save (UC-C) and price-drop alerts (UC-G) are Builder-track only today — Casual is one-shot per persona research and does not motivate a wishlist UC at v1.
  8. Buy (UC-2) extends to Affiliate (UC-L). Every successful buy is a candidate for attribution; reconciliation fires asynchronously on click + conversion data. UC-2 is the unified conversion path for both tracks.
  9. External actors as system rectangles (UML 2 convention) — they participate in use cases but aren't actors in the same sense as humans.
  10. UC-K is M2-deferred — visually grouped separately so it's clear it's not v1.x work.

Decisions taken from this view

What was deliberately left out

  • Authentication actor and flows — handled at the Auth.js layer, not as use cases. See #11.
  • Internal scrapers and matchers — infrastructure, not actor-facing. They appear in Ingest pipeline.
  • Notification-of-share / email confirmations — out of scope for v1.