User Flow Documentation Template

Detailed enough for a designer to create wireframes and an engineer to build the logic without asking follow-up questions. Every screen, decision point, error state, and edge case should be documented. If the flow has more than 15 steps, consider splitting it into sub-flows (e.g., "Checkout: Shipping" and "Checkout: Payment").

FigJam and Miro are popular for collaborative diagramming. Whimsical has a dedicated flowchart mode. For simple flows, a text outline (like the one in this template) works fine and is easier to keep updated than a visual diagram. The visual diagram is useful for presentations and stakeholder alignment. The text outline is useful for engineering handoffs.

Document the handoff points explicitly. At step N, the user leaves Product A and enters Product B. Note what data is passed (URL parameters, session state, API calls), what the user sees during the transition, and who owns each side of the handoff. Cross-product flows are where most user experience failures occur because no single team owns the full path. The [design handoff template](/templates/design-handoff-template) covers the designer-to-engineer handoff within a single product.

Update when the flow changes (new step, removed step, new error handling) or when usability testing reveals that users take a different path than documented. Flows that do not match reality are worse than no documentation because they teach engineers and QA the wrong behavior. Review flows quarterly for high-traffic features. Track actual user paths against documented flows using [funnel analysis](/glossary/conversion-rate).

Start with the flows that have the highest traffic, the highest revenue impact, or the most support tickets. For most SaaS products, this means: signup, onboarding, core value action (the thing users pay for), and upgrade/payment. Use [product metrics](/glossary/aarrr-pirate-metrics) to identify which flows matter most to your business. ---