Skip to content
Docs
Browse docs
Documentation overview

Start with a user flow

Choose the creator or reviewer path, then learn how Mockspace organizes a product review.

On this page

What Mockspace shows#

A flow is a journey through a product. Its steps run left to right. The meaningful states of each screen stack beneath that step: loaded data, an empty result, a validation error, an open dialog, or another condition a reviewer needs to see.

Mockspace renders those frames from the application and places them on one canvas. It does not provide a mock backend or invent product data. The application owns the fixtures and the URL or interaction that reaches each state.

Choose your path#

If you are preparing a product, begin with Install Mockspace, then follow the Quick start or Set up with your agent. Start with one representative flow and keep the first result local while you verify it.

If you received a review link, open it in a browser. You do not need the CLI for basic review. Choose a flow, compare the screen states, and inspect any visual diff or comments the author shared. Read Review and share for the review model.

The four terms#

  • A flow is a journey worth reviewing from beginning to end. It is one row on the canvas.
  • A step is one screen in that journey, in its reading order.
  • A state is a condition of a screen that deserves its own frame.
  • An edge is a labelled alternate path between two steps that the row alone cannot express.

Read Flows, Screens and states, and Alternate paths for the full model.

Prepare a truthful first result#

Start in the application's repository. Choose one representative journey and the states that explain it. Your coding agent can help inspect the app, prepare its fixtures, and configure the capture.

Existing workspaces should reuse their .mockspace/config.mjs, app-owned fixtures, and flow declarations. Run mockspace check before opening the viewer; it reports missing source paths, invalid states and edges, and the exact application start command declared by the workspace.

Know the boundary#

The local canvas is live: its frames run the application through a proxy. A static build is an inert capture that can be read without the app. A published review stores that static result behind the service's access rules.

The project desk lists projects available to you. Public documentation never reads project names, private builds, or signed-in user data.