Flows and prototypes
Wire screens together with the connect tool, play the result as a prototype inside a device shell, and hand the same flow graph to an agent as navigation intent or as a UI test.
A screen on its own says what something looks like. A flow says what happens next, and that is the half an implementation usually has to guess.
Connecting screens
Pick the connect tool, drag from a control to a destination screen, and an interaction popover asks for the three things a transition needs:
- The action: navigate, open an overlay, go back, or dismiss.
- The gesture: what the user does to trigger it.
- The motion: how the transition moves, including a timeout transition for a screen that advances on its own.
Connections are drawn on their own arrow layer above the canvas, so the graph stays readable without changing the screens under it.
Playing it
Preview runs the graph inside a device shell at the device you chose, and it plays what you would actually be able to do:
- Forward navigation and walk back through the history you built.
- Overlays on their own stack, so dismissing a sheet returns you to the screen underneath rather than to the previous route.
- Hover states where the medium has them.
- Timeout transitions for screens that advance without input.
What a flow tells an agent
A screen that belongs to a journey reports its flow node: whether it is an entry point, where it sits in the traversal order, its route, and its outgoing transitions. A control that leaves the screen reports the destination's flow id and the event that fires it, and an input that carries state forward reports the field it fills.
The rule that follows is short: implement navigation from the flow, never from a button's label. "Continue" is not a destination, and two screens in the same product can both have one.
A screen that reports it is not in a flow is stating a gap. The right response is to say so, not to invent a destination.
Running the flow as a test
The same graph can be executed against the running app. Each transition becomes a step: perform the gesture on the control, expect to arrive at the destination screen. It is the cheapest way to catch the case where every screen is pixel-correct and the wiring between two of them is wrong.
See verifying a design against the running app for how the app is brought up and observed.
Sharing a prototype
A shared design carries the flow graph with it, so whoever opens the link plays the prototype instead of paging through static frames. The viewer walks the graph you published; it has no connect tool and no write path back.