Map what matters

Example: mapping a registration workflow

This article shows how to map a simple workflow before deciding what events or metrics to create.

The example is account registration. It is familiar, narrow enough to explain clearly, and useful for showing how a workflow moves from user intent to measurable behaviour.

The goal is not to create a perfect registration model. The goal is to show the kind of thinking product teams can reuse for any workflow.

What to notice

This example shows three important things:

the workflow is defined before events or metrics
completion is first product access, not just form submission
exits reveal different problems that would need different responses

The map is useful because it tells the team where evidence is needed.

Start with the user intent

A workflow starts with what the user is trying to achieve.

For this example, the intent is simple:

I want to create an account so I can access the product.

That intent gives the workflow a clear purpose. The team is not measuring a registration page, an account feature, or a form component. It is measuring whether users can create an account and reach the product.

Define the workflow boundary

The next step is to define where the workflow starts and ends.

For registration, the team might define the boundary like this:

Entry:
User starts account creation

Completion:
User accesses the product for the first time

This boundary matters. If completion is defined as “form submitted”, the workflow may look successful even if users fail to verify their email or never reach the product.

A better completion point should reflect the outcome the team cares about.

Map the meaningful steps

Once the boundary is clear, break the workflow into meaningful steps.

For a simple registration workflow, the steps might be:

View registration form
↓
Enter details
↓
Submit form
↓
Verify email
↓
Access product

These steps describe progress from intent to outcome. They are not just screens or interface elements. They are the behaviours the team needs to understand.

Identify where users can pause or fail

A useful workflow map should show where progress can break down.

For registration, users might pause, abandon, or fail when they:

do not understand why registration is needed
view the form but do not enter details
encounter validation errors
submit the form but do not receive the email
receive the email but do not verify it
verify the email but do not access the product

These moments help the team decide what evidence is needed. They also prevent the workflow from being reduced to a single completion rate.

Connect steps to events

After mapping the workflow, the team can decide what events should capture meaningful behaviour.

For example:

Workflow step                     Possible event

View registration form             registration.form_viewed
Submit form                        registration.form_submitted
Encounter validation error          registration.form_error_shown
Verification email sent             registration.email_verification_sent
Verify email                        registration.email_verified
Access product                      registration.completed

The event names are not the workflow. They are the evidence captured by the product.

The workflow should be clear before the team names the events.

Connect events to metrics

Once events are defined, the team can create metrics that describe progress through the workflow.

For registration, useful metrics might include:

registration start count
form submission rate
form error rate
email verification rate
registration completion rate
drop-off between form submission and email verification
time to complete registration

These metrics are useful because they relate to specific behaviours. If completion falls, the team can look at where the workflow loses momentum rather than treating registration as one vague problem.

Connect metrics to decisions

The final step is to connect measurement to product decisions.

For registration, the team might need to decide:

should we simplify the form?
should we improve validation messages?
should we change the confirmation screen?
should we investigate email deliverability?
should we improve the resend verification flow?
should we compare behaviour by device, channel, or user type?

These decisions give the measurement a purpose. The team is not mapping the workflow to produce a nicer diagram. It is mapping the workflow so that evidence, metrics, and decisions connect.

A simple workflow map

The finished version might look like this:

Workflow:
Register for an account

User intent:
Create an account so I can access the product

Entry:
User starts account creation

Steps:
View registration form
↓
Enter details
↓
Submit form
↓
Verify email
↓
Access product

Possible exits:
Does not enter details
Encounters validation error
Does not verify email
Does not access product after verification

Completion:
User accesses the product for the first time

Example metrics:
Form submission rate
Email verification rate
Registration completion rate
Time to complete registration

Decision:
Where should we improve the registration experience?

This is enough to create a shared understanding before the team moves into detailed event specifications or dashboard design.

How to apply this

When mapping a workflow, work in this order:

define the user intent
set the entry point
set the completion point
list the meaningful steps
identify possible exits
decide what events should capture progress
define metrics that help interpret the evidence
connect the metrics to decisions

Keep the first version simple. A workflow map should make measurement easier to discuss, not harder.

Events as evidence
From events to metrics
Example: turning a workflow into metrics
Workflow catalogue template

Key takeaway

Mapping a workflow turns a broad product activity into measurable behaviour.

For registration, the useful question is not only “what is the completion rate?” The better question is where users start, how they move through the workflow, where they leave, and what evidence the team needs to decide what to improve.