PHASE 2 STRUCTURE DECISION CHOOSE ONE

Three Ways to Structure
the System Map

The brief says: "how you structure the map is a big part of what we're reading." This is not a visual preference question. It's a systems-thinking declaration. Each option encodes a different mental model of the platform.

OVERVIEW

Side-by-Side Comparison

Criterion	A — Portal-centric	B — Lifecycle-centric	C — Hybrid ★ Recommended
Completeness signal	★★★Hard to show what's shared	★★★★Every step visible	★★★★★Everything + context
Portal connection clarity	★★★Arrows get messy	★★★Ownership unclear	★★★★★Both dimensions clear
Money flow visibility	★★Buried in Platform column	★★★In-flow but mixed	★★★★★Dedicated section
Live walkthrough traceability	★★Jump columns to trace	★★★★★Left-to-right finger trace	★★★★★Spine + clear lanes
Structural "because" quality	★★Default choice — weak signal	★★★★Clear argument	★★★★★Strongest design argument
Execution risk	LowSimple to build	MediumOwnership ambiguous	MediumMore sections, more planning

OPTIONS

Each Structure in Full

Visual pattern

Customer

Browse

Cart

Checkout

Tracking

Reviews

Store

Order Queue

Accept/Reject

Menu Mgmt

Stock

Hours/Status

Payout Dash

Platform

Store Dir

Commission

Settlement

Fraud

Analytics

Reporting

                ↔ arrows connect nodes across columns ↔
              

Shared: Auth • Notifications • Search Index • Pricing Engine

OPTION A

Portal-Centric

"What does each user type see?"

Three vertical columns — one per portal. Every node placed under the portal that owns it. Arrows drawn between columns to show cross-portal communication. Shared infrastructure shown as a bottom band beneath all three columns.

Strengths

Ownership is instantly legible — no ambiguity about who controls what
Maps directly to the brief's "three portals" framing
Easy to build — low execution risk
Simple to explain: "each column is one login"

Weaknesses

Cross-column arrows multiply fast — spaghetti at 41 nodes
Lifecycle sequence disappears — hard to trace "happy path" order end-to-end
Money flow buried inside Platform column, not its own visible system
Default choice — reads as "first idea", not a considered structural argument

Walkthrough traceability:

2/5

Verdict Not recommended. It answers "who owns what" but not "how does an order actually move." The brief asks for the machine — the parts and how they connect. Portal-centric shows the boxes but obscures the motion. The "because" for choosing this structure is weak: "I organised by login type." That's not a systems insight.

Visual pattern

Customer

Browse

Cart

Checkout

Track

Review

Payment

Capture

Hold

Settle

Payout

Store

Receive

Prepare

Ready

Driver

Assign

Pickup

Deliver

PoD

Platform

Fraud

Notifications

Reporting

+ management nodes

              → time flows left to right →
            

OPTION B

Lifecycle-Centric

"Follow the order from click to completion."

Horizontal swim lanes. Time flows left to right. Each lane represents a participant (Customer, Store, Driver, Payment, Platform). Nodes are placed at the point in the lifecycle where they activate. Reading left-to-right traces any scenario naturally.

Strengths

Walkthrough-optimised — left-to-right finger trace for any scenario
Time sequence is visible — "what happens first" is unambiguous
Shows parallelism: Store prep + Driver assignment happen simultaneously
Strong structural "because": "I wanted to show the machine in motion"

Weaknesses

Portal ownership becomes unclear — which lane "belongs" to which portal login?
Store management nodes (Menu, Stock, Hours) don't fit the linear lifecycle
Platform admin nodes (Reporting, Analytics) exist outside the order flow entirely
Money flow in its own lane but competing visually with all other lanes

Walkthrough traceability:

5/5

Verdict Strong but incomplete. Excellent for tracing the order lifecycle and any scenario that unfolds in time. Falls apart for management nodes that exist outside any order (menu changes, stock updates, analytics). The "because" is strong but partial — it only maps the machine in motion, not the machine at rest. A menu manager can change item prices between orders; that needs a home.

Visual pattern

ORDER LIFECYCLE SPINE (left → right, shared by all portals)

Browse

Cart

Checkout

Confirm

Prep

Dispatch

Deliver

Complete

↓ each portal's nodes hang below the spine step they activate at ↓

Customer Portal

Search & Filters

Payment UI

Live Tracking

Reviews

Store Portal

Order Queue

Menu Mgmt

Stock/Hours

Payout View

Platform Portal

Fraud Detection

Driver Assign

Notifications

Analytics

MONEY FLOW — DEDICATED SECTION (below the map)

Capture

Auth Hold

Settlement

Commission

Payout

Refund

OPTION C ★ RECOMMENDED

Hybrid

"The lifecycle is the spine. The portals are the perspective."

A horizontal lifecycle spine runs across the top — the shared order journey that all three portals observe simultaneously. Below the spine, each portal's nodes hang in its own swim lane, anchored to the lifecycle step they activate at. A separate dedicated section below maps the money flow end-to-end.

Strengths

Answers both brief questions: information flows AND money flows, each with their own visual structure
Lifecycle spine makes any scenario traceable left-to-right
Portal lanes preserve clear ownership — three distinct sections below the spine
Money section is impossible to overlook — not buried in any column
Strongest structural "because": the platform IS the lifecycle — portals are just different windows onto it
Shows shared nodes (Auth, Notifications) once, with lines pointing to the portals that use them

Weaknesses

More complex to lay out — requires careful Mermaid/FigJam planning before building
Risk of over-complexity if not kept disciplined — must resist adding sub-nodes
Management-only nodes (Analytics, Reporting) need a deliberate home that doesn't disrupt the spine

Walkthrough traceability:

5/5

Verdict Recommended. The structural "because" is the strongest argument available: the lifecycle is the only thing all three portals share — it's the single source of truth. The portal columns are not independent kingdoms, they're three different views of the same order moving through time. Separating money flows gives them the visual weight they deserve — they're the second explicit ask in the brief, and most maps bury them.

RECOMMENDATION

Option C — The Written "Because"

Hybrid: Lifecycle Spine + Portal Lanes + Money Section

The structural "because" — ready to annotate directly onto the FigJam board

C Recommended

The lifecycle spine

One shared sequence: Browse → Cart → Checkout → Confirm → Prep → Dispatch → Deliver → Complete
Every order that ever happens on this platform traverses this spine exactly once
All three portals observe the same order — they just see different fields of it
Placing this as the horizontal backbone means any scenario can be traced left-to-right

The portal lanes

Three swim lanes below the spine — one per portal login
Each node anchors to the lifecycle step it activates at
Management nodes (Menu, Analytics, Onboarding) that exist outside the order flow sit in a "management" sub-section within their portal lane
Shared infrastructure (Auth, Notifications) shown once with outbound lines to each portal that uses it

The money section

Dedicated horizontal band below everything else
Eight nodes: Capture → Hold → Settle → Commission → Payout → Refund → Dispute
Aligned vertically to the lifecycle steps that trigger each money event
Impossible to miss — the brief explicitly asks for money flows
Money is the only flow that reverses (refunds) — shown as a return arrow

Because the lifecycle is the only thing all three portals share. A customer, a store manager, and a platform admin all have separate logins, separate dashboards, and separate mental models — but they are all looking at the same order. The order is the shared object. The lifecycle is the shared clock. Organising the map around that clock means the board answers the machine question before the portal question. The portals become context, not structure.

Because money flows deserve their own section. The brief explicitly names information flows and money flows as the two things being mapped. Most system maps put money inside the Platform column and call it done. That buries the mechanism that makes the whole business work: the customer's payment holds for the duration of the order, gets split on completion (platform commission + delivery fee + store portion), and settles into a store payout on a cycle. Refunds run that in reverse. That's a distinct system — it runs in parallel to the information flow, not inside it.

Because the 15-minute walkthrough requires left-to-right traceability. When the hiring team picks a scenario — failed payment, driver cancels, store goes offline — the evaluator needs to watch a finger move across the board and follow the logic. The lifecycle spine makes that movement natural. Portal-centric maps require jumping columns. Lifecycle-only maps blur ownership. The hybrid holds both.

Confirm to Proceed

Awaiting your decision. If you choose Option C (recommended), Phase 3 begins immediately: writing all board annotations using the article-writing skill, then running the advanced-evaluation quality gate before a single node goes on the FigJam board.

If you want to adjust anything — change the money section placement, collapse the portal lanes differently, or modify how shared infrastructure is shown — say so now. The structure decision is the last thing we lock in before building.