What is a Decision Point?

TL;DR

• A decision point is where a flow branches.
• The branch can depend on user choice, data, permissions, state, or a business rule.
• Decision points make hidden product logic visible.
• Each branch should have a clear condition and resulting state.
• Unclear decision logic becomes rework during engineering and QA.

What does a decision point look like?

In onboarding, the product may ask whether the user is joining an existing workspace or creating a new one.

That choice changes the next steps, permissions, and required information. The point where the flow splits is the decision point.

What can trigger a branch?

• user choice
• role or permission
• account status
• data availability
• validation result
• business rule
• system success or failure

Decision point vs. user action

Every click is not a decision point. A decision point specifically changes which route becomes valid next.

For example, clicking “Next” may continue one path. Choosing “Personal account” versus “Business account” creates two different paths.

How do teams map decision points?

1. Name the condition that changes the path.
2. List all valid outcomes.
3. Define the next state for each outcome.
4. Check whether any branch is impossible or missing.
5. Review permissions, fallbacks, and recovery.
6. Test the branch logic inside the full flow.

Common mistakes

Using vague branch labels

“Yes/No” is only useful when the underlying question remains obvious.

Forgetting default or unknown conditions

Real systems can have missing or stale data.

Hiding business rules in engineering

Important branch logic should be visible to product and design before build.

The bottom line

A decision point asks: what condition changes the route, and what should happen for each possible outcome?

Related terms

User flow · Workflow · Product state · Edge case

Relevant Figr resource

See branching examples in Figr’s User Flow Examples.