Pre-Book · Phase 1
Page-Level Information Architecture
A screen-by-screen inventory of the tool: what each page is for, who sees what, which states it can be in, and where its content actually comes from.
Site map
Pre-book has fewer screens than its complexity suggests. Five routable surfaces and a layer of six overlays carry the entire workflow. The overlays are documented separately and deliberately: they are not pages, they cannot be linked to, and they hold a disproportionate amount of the tool's logic.
Screen inventory
| Surface | Type | Primary job | Role variance | Mode variance |
|---|---|---|---|---|
| Access gate | Route guard | Keep unauthenticated or unpermitted users out | None | None |
| Account | Page | Account details, Shopify order history, secondary way into pre-book | High | Low |
| Dealer dashboard | Page | Control centre for the whole workflow | High | High |
| Catalog & PDP | Page | Find products | None | None |
| Cart | Page | Assemble one order and commit it | Medium | High |
| Overlay layer | 6 overlays | Gating, instruction, upload, progress | High | High |
Dealer dashboard
The dashboard is not an overview screen that happens to have controls on it. It is the control centre, and it is currently doing at least six unrelated jobs on one surface.
| Aspect | Detail |
|---|---|
| Jobs on this screen | (1) Choose a dealer, if rep. (2) Turn pre-book on or off. (3) Read program instructions. (4) Start an order or upload a CSV. (5) Review, edit, and delete saved orders. (6) Submit the whole program. |
| Content elements | Program heading and instructions; pre-book activation control; start-order and CSV entry points; saved-order list with per-order edit and delete; program total and threshold status message; submit action. |
| Role variance | Reps see dealer selection and rep-specific notices. Dealers see neither. The rest of the layout is shared. |
| Mode variance | Pre-book on: pre-book tools appear, the regular B2B upload area is hidden. Pre-book off: the reverse. |
| States | No dealer selected (rep) · pre-book off · pre-book on, empty program · program below threshold · program above threshold · program at order cap · loading a large order · submitted. |
| Data sources | Theme settings (headings, instructions, tooltips, windows, thresholds, caps) · customer metafields (saved orders, program state) · browser session (active mode, selected dealer). |
| Admin-configurable | Program heading names, instruction copy, tooltip visibility, whether the pre-book link appears at all, order and ship windows, minimums and thresholds, maximum orders. |
The saved-order list is the most important content in the tool and it is a list item on a screen with five other jobs. There is no program detail view — no place to see the whole program as one object with its total, its threshold distance, its ship windows, its order count against the cap, and its orders. Phase 2's dashboard redesign is really the creation of that missing screen.
Account
The account page is standard Shopify with pre-book bolted to the side. It offers a second, parallel way into the workflow — including a second CSV upload entry point — which means the tool has two front doors that do not behave identically.
| Aspect | Detail |
|---|---|
| Content elements | Customer account details; past Shopify orders; link into the pre-book dashboard; CSV upload; for reps, dealer selection and rep-specific notices. |
| Role variance | High. Rep notices and dealer selection appear only for reps. |
| Notable | Past orders shown here are Shopify orders. Submitted pre-book programs appear only once the backend has created Shopify orders from them — so there is a window in which a dealer's program is real but invisible on this page. |
| Gaps | No pre-book program history. No distinction between a regular order and an order that originated as a pre-book program. Duplicate CSV entry point with different surrounding context. |
Cart
The cart is the underlying Shopify cart with pre-book rules layered on top. Its primary action changes meaning depending on mode, which makes it the highest-stakes surface in the tool: the same button does three different things.
| Mode | Primary action | Result |
|---|---|---|
| Regular | Check out | Standard Shopify checkout |
| Rep regular-order | Submit order | Order submitted for the selected dealer, no program state |
| Pre-book | Save order | Captured into the program as a draft; cart cleared |
| Aspect | Detail |
|---|---|
| Content elements | Line items and quantities; ship window selection; ship date; PO number; note; program context (which program, which order number within it, running program total); primary action. |
| States | Empty · populated · ship date required · ship date out of range · below threshold · above threshold · editing an existing saved order · saving. |
| Data sources | Shopify cart (line items) · theme settings (copy, windows, thresholds) · customer metafields (program total, order index) · session (mode, dealer). |
| Gaps | No line-level program context (which items count toward which threshold). No quantity-grid entry pattern, which is what wholesale buyers expect. Ship-date constraints are enforced but not explained. No indication of which dealer the order is for. |
Catalog & product pages
Pre-book does not replace browsing. It changes only what happens after items reach the cart. This is a deliberate and reasonable choice for a proof of concept, and it is also the clearest place where the tool stops feeling like a St. Croix product.
A dealer building a pre-book program is making a season's buying decision, not shopping. The catalog gives them no program context while they browse — no running total, no distance to the next tier, no indication of what is new in the program, no way to see what they bought last season. Everything the buyer needs is one screen away from where the decision is made.
Access gate
Not a screen — a route guard. If the user is not authenticated, or pre-book is disabled, or the user lacks access, the tool redirects rather than rendering anything.
Three different conditions produce one identical outcome. A dealer who should have access but does not, and a dealer arriving before the program opens, get the same silent redirect as someone with no business being there. There is no state that says you are in the right place, at the wrong time.
Overlay layer
Six overlays. None are routable, none are linkable, none survive a refresh, and between them they hold dealer selection, all instructional content, and every progress state in the tool.
| Overlay | Trigger | Blocking | Job | Weakness |
|---|---|---|---|---|
| Dealer selection | Rep lands on dashboard | Yes | Bind the session to a dealer before anything else | Once dismissed, nothing persistently shows who was chosen |
| Instructions | User opens it | No | Explain the program in admin-authored copy | The rules of the program live in a panel most users open once |
| CSV upload | User opens it | No | Take a file of SKUs | No template, no column mapping, no preview before import |
| CSV loading | Upload in progress | Yes | Cover SKU resolution | Ends without a per-SKU report of valid, draft, unavailable, missing |
| Pre-book reminder | Contextual | No | Explain how to leave pre-book mode | Exists because the mode itself is not legible; a symptom, not a feature |
| Order loading | Opening a large saved order | Yes | Cover cart re-hydration | Duration scales with order size; no progress, no cancel |
Four of the six overlays exist to compensate for something the interface does not say on its own. The reminder popup explains a mode the interface should make obvious. The instructions panel holds rules the dashboard should show in place. Two loading modals cover operations whose cost the design never accounted for. Phase 2 should aim to retire overlays, not restyle them.
IA findings
Six structural findings, each of which becomes a requirement in Document 04.
| # | Finding | Leads to |
|---|---|---|
| IA-01 | The dashboard carries six unrelated jobs. It is a screen that grew by accretion rather than one that was designed. | PB-DSH-01 |
| IA-02 | There is no program detail surface. The program — the actual object the tool exists to manage — has no screen of its own. | PB-DSH-02 |
| IA-03 | Program state is displayed in two places (dashboard and cart) with no canonical source, so they can disagree. | PB-PRG-01 |
| IA-04 | There is no post-submit surface. The most significant moment in the workflow ends on a screen that was not designed for it. | PB-SUB-03 |
| IA-05 | Two front doors (account and dashboard) offer overlapping but non-identical entry into the same workflow. | PB-DSH-04 |
| IA-06 | There is no administrative surface of any kind. Operators configure a live wholesale channel through Shopify settings fields. | PB-ADM-01 |