Successor screens require an action and carried state

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Storyboard cart→checkout→receipt with teaching sku-A×2 totaling 30. Attractive screens with changed products/amounts do not represent one journey.

Mechanism

For each transition declare action, prerequisites, carried identities/data and failure state. Checkout receives the same cart, and a receipt follows confirmed payment only. Failures retain recoverable checkout. Check totals/options/back behavior across screens, labeling static expectations and testing implementations through real activation.

Bad example

Arrange unrelated cart/login/receipt screens with different products, accepting them because all three look attractive.

Good example

Carry sku-A×2 and total 30 from cart to checkout. Checkout activation preserves state; confirmed payment leads to the same-order receipt, while failure stays recoverable. State triggers/back paths; a storyboard does not prove payment implementation.

Why the change matters

Actions explain why a screen follows and carried state explains task continuity. Together they turn a screen collection into a checkable journey.

Observable expectation

Teaching screens preserve product/count/amount, success has confirmation and failure no receipt. Back navigation retains choices or follows a declared reset rule. Images verify storyboard consistency, not successful clicks.

Limits

Taxes/discounts/shipping can legitimately alter totals if explained. Static images cannot verify network, permissions, payment or persistence; screen count does not measure flow completeness.