Skip to content
Browse docs

Flows

Model one journey as an ordered row that a reviewer can understand end to end.

On this page

A flow is a reviewable journey#

A flow is the sequence a person follows to finish one job in the product. Mockspace draws each flow as a row, with steps from left to right and the states of a step below it.

Choose a boundary that a reviewer would actually inspect end to end. “Recover a failed payment” is a useful flow. “All account pages” is a category, not a journey. A flow that exists only to collect unrelated screens makes sequence and missing coverage harder to see.

What belongs in a flow#

Each flow declares an id, a human-readable name, its design purpose, optional notes, an ordered screens list, and optional alternate-path edges. The screen definitions carry their own routes, sources, states, and design notes.

export default [
  {
    id: "request-to-booked",
    name: "Request to booked trip",
    levels: ["Booking", "Flights"],
    purpose: "Review the traveller journey from brief to confirmation.",
    screens: [home, brief, inventory, proposal, confirmation],
    edges: [
      { from: "inventory", to: "confirmation", label: "book without a proposal" },
    ],
  },
];

The array order is the canonical reading order. Use alternate paths for a shortcut or branch; do not duplicate the whole flow just to show a different transition.

Group a large flow list#

Use optional levels to place a flow in nested navigation groups, from outermost to innermost. In the example above, Booking → Flights contains Request to booked trip. On arrival, the selected flow’s ancestors open and unrelated groups start collapsed. Each group opens and closes independently; the same group name under another parent is a separate group. Group counts include every captured track in that group.

Omit levels or use [] to keep a flow at the top level. Names must be non-empty strings; surrounding whitespace is trimmed. Mockspace uses the declared levels and does not infer groups from flow names. Groups appear in first-encounter order, with flows in their declared order within each group. This only organizes the navigation: canvas order, track and frame IDs, and shared links stay the same.

Flow names wrap in the navigator. Drag its right edge to change the width, or focus the divider and use Left/Right arrows (Shift for a larger step), Home/End for the bounds, and Enter to reset. Double-click also resets. The width is saved in this browser; phone navigation uses its own drawer width. Fit flow adjusts to the available canvas space when you resize.

Reuse one screen identity#

The same screen can appear in more than one flow. Keep one screen id and reuse its definition. Giving the same page two identities produces duplicate frames and splits its purpose, source, and state metadata.

The canvas counts a reused screen once for every row where it appears because each placement is part of that flow's reading order. mockspace check reports both total row frames and unique screen states when reuse makes those numbers differ.

Keep purpose with structure#

A flow name says what happens. Its purpose says why the journey is reviewed. Notes should preserve decisions a reviewer or agent could not infer from source code alone, such as the point where approval is required or the state that must never be skipped.

When the flow changes, update the declaration with the product. Mockspace serves this context to agents through MCP, so stale prose is worse than missing prose.

Continue#

Read Screens and states to define each step, or Prepare states to make the states render without a production backend.