Example: mapping a registration workflow

A team asks for a registration dashboard. Before choosing charts or event names, it needs to decide what registration means.

This example keeps the workflow deliberately simple. Its value is not that every product registers users in the same way. It shows how a vague request becomes a measurement boundary the team can explain.

Start with the product question

The weak request is:

We need a registration dashboard.

A more useful question is:

Are new users able to create an account and reach the product?

That question makes two choices visible:

• the team cares about new users who start account creation;
• form submission or account creation alone does not count as the selected outcome.

Map the workflow

The map is compact, but it already resolves several arguments that would otherwise appear later in the dashboard.

Why the entry point matters

The workflow does not begin with every website visit or every registration form view. It begins when a new user starts account creation through a supported route.

The team should still record the route, such as invitation, checkout or self-serve registration. Different routes may need separate interpretation. They do not need separate workflow definitions unless the behaviour or decision is genuinely different.

The unit is the first eligible registration attempt per new user. This prevents repeated starts from automatically inflating the number of people who tried to register. A separate repeated-attempt measure can preserve evidence of friction.

Why completion is first access

If the question is whether registration gets users into the product, neither form submission nor email verification is enough.

The selected completion condition is:

User accesses the product for the first time
within seven days of starting account creation.

The seven-day rule matters. A person who returns the next day should not be treated the same as someone who never continues. Another product may need a shorter or longer window.

This completion point should be calculated from the entry condition and an observable access event. It does not require an event called registration.completed.

What the exits actually say

The map identifies where observed progress can stop:

• before details are submitted
• during validation or repeated submission
• between submission and email verification
• between verification and first product access

These are investigation points, not explanations. Event records may show that a user did not continue within the time window. They cannot establish whether the cause was confusion, deliverability, lost interest, technical failure or something outside the product.

Questions created by the map

The team can now ask:

• How many new users start account creation?
• How many submit their details successfully?
• How many experience validation errors or repeated attempts?
• How many verify their email?
• How many reach the product within seven days?
• How long does each transition take?
• Does behaviour differ by entry route, device or workflow version?

These questions are related because they describe the same bounded attempt. They do not have to be forced into one conversion rate.

Hand the map to event design

The workflow suggests evidence such as:

registration.started
registration.form_submitted
registration.form_error_shown
registration.email_verified
account.first_accessed

Each event still needs its own observable fire condition and properties. The workflow map explains why the evidence is needed and how the events relate to progress.

That is the handoff: the team has moved from “build a dashboard” to a defined workflow that engineering, analytics, design, research and product can recognise.