Testing a web flow

A worked example: evaluating a signup flow end to end.

You may only test properties you own, operate, or are expressly authorized to test. See Authorization & limits.

Pick the flow, not the page#

A flow is a sequence with an outcome. "The pricing page" is a page; "find out what this costs and start a trial" is a flow. Test flows, friction usually lives in the seams between pages, not on any one of them.

Set a goal a real user would hold#

I manage a team of 10. Work out whether this fits our budget,
then start a trial.

This is answerable, has a clear success condition, and spans several screens, so it will surface handoff problems between marketing and product.

Choose contrasting personas#

For a signup flow, a useful set:

• Impatient multitasker: catches every unnecessary step before value.
• Budget decision-maker: catches unclear pricing and hidden tiers.
• Screen-reader user: catches focus traps and unlabeled form fields.

Read the seams#

Pay attention to where personas cross a boundary, marketing site into app, unauthenticated into authenticated, form into confirmation. Common findings there:

• No confirmation after an action succeeds, so the persona repeats it.
• Form fields whose purpose isn't explained, so the persona abandons rather than supply the data ("why do you need my phone number to show me a demo?").
• Counts or state in the header that don't match what the persona just did.

Fix, then re-run the same config#

Change the product, keep the personas and goal fixed, re-run. If the finding is gone, the fix worked. If it moved somewhere else, you relocated the friction rather than removing it.

A reasonable cadence#

• Per release: re-run your core flows.
• Per redesign: re-run with an expanded persona set.
• When a metric moves and nobody knows why: run the flow the metric covers.

See also Simulations and Findings & reports.