Experiment with staged disclosure in the Registration flow
Experiment summary
We believe that using a staged disclosure pattern in the registration flow can reduce its perceived complexity, thus improving the completion rate and fasten stage adoption.
To verify that, we will create an alternate version of the registration flow. We will progressively introduce the content by creating dedicated JTBD, role, and create v.s Join steps instead of our current Welcome page which is displaying all these options in one form.
And we’ll measure the impact on the following:
- Primary metric: registration completion rate.
- Secondary metrics: Time to completion, Group/project creation rates
- Health metrics: D7, D14 Retention rates for group, Trial adoption rate, Conversion rate
Hypothesis
Using a Staged disclosure pattern in the registration flow can reduce its perceived complexity, thus improve completion rate and fasten stage adoption.
Business problem
The registration flow is a critical part to help users getting started with GitLab. The faster we lead new users to product value the better chance we have to facilitate the platform adoption.
Supporting data
Qualitative
Solution Validation: Test SaaS registration flow visions
Quantitative
TO ADD BASELINE REG FLOW DATA
Expected outcome
- Primary metric: Increase in registration completion rate
- Secondary metrics: Decrease in Time to completion, Increase or steady Group/project creation rates
- Health metrics: Steady D7, D14 Retention rates for group, Steady Trial adoption rate, Steady Conversion rate
Experiment design & implementation
Regular registration (no invitation)
View
Current Registration flow
flowchart TB
A[Registration form] -->| Email confirmation| B[Sign-in]
B --> C[Welcome page]
C --> D{S.F.C + Create or Join a project}
D -->|S.F.C = true & create a project| F[About your company]
D -->|Join a project| G[User dashboard]
D -->|S.F.C = false & Create a project | H[Create a group & create or import project]
F --> H
H --> I[Get started screen]
I --> J[Learn GitLab]
Experiment flow (Option 1)
Introducing dedicated JTBD, Role and Create/Join a project steps
flowchart TB
A[Registration form] -->| Email confirmation| B[Sign-in]
B --> C[JTBD]
C --> D[Role]
D --> E{S.F.C + Create or Join a project}
E -->|S.F.C = true & create a project| F[About your company]
E -->|Join a project| G[User dashboard]
E -->|S.F.C = false & Create a project | H[Create a group & create or import project]
F --> H
H --> I[Get started screen]
I --> J[Learn GitLab]
Experiment flow (Option 2)
Introducing dedicated JTBD, Role and Create/Join a project steps. Changing the order of Create/Join a project so it's a the beginning of the flow.
flowchart TB
A[Registration form] -->| Email confirmation| B[Sign-in]
B --> C{S.F.C + Create or Join a project}
C -->|S.F.C = true & create a project| D[About your company]
C -->|Join a project| E[JTBD]
C -->|S.F.C = false & create a project| E[JTBD]
D --> E
E --> F[Role]
F --> G{Background redirection}
G --> |User is joining a project|H[User dashboard]
G --> |User is creating a project | I[Create a group & create or import project]
I --> J[Get started screen]
J --> K[Learn GitLab]
Vision flow
This first experiment should help us build on a longer-term vision. This vision version of the registration flow includes the following:
- Different levels of user verification for enhanced security
- Trial prompt as a step (experiment TBD)
- Choice to start a project from a template or run CI/CD for external repo
- Registration flow finishes when users land on the project overview page instead of the Learn GitLab
flowchart TB
A[Registration form] --> B{Arkose - Check background verification level needed}
B --> | Verification level 1 | C[Email confirmation]
B --> | Verification level 2 | D[Phone number verification]
B --> | Verification level 3 | E[Credit card verification]
C --> F[JTBD]
D --> F
E --> F
F --> G[Role]
G --> H{S.F.C + Create or Join a project}
H -->|S.F.C = true & create a project| I[About your company]
H -->|Join a project| J[User dashboard]
H -->|S.F.C = false & Create a project | L{Create a group & Create / import / template project or CI for external repo}
I --> K{Start a trial Yes/No}
K --> L
L --> | Create a project | M[Create a project]
L -->| Import a project | N[Import from 3rd party]
L -->| Use a template project | O[Pick a template]
L -->| CI external repo | N
L --> P[Project overview]
M --> P
N --> P
Invited user registration
View
Current Registration flow
flowchart TB
A[Email invite] --> B[Registration form]
B --> C[Welcome page]
C --> D[Invited Group/project activity]
Experiment flow (Option 1)
flowchart TB
A[Email invite] --> B[Registration form]
B --> C[JTBD]
C --> D[Role]
D --> E[Invited Group/Project activity]
ICE score
| Impact | Confidence | Ease | Score |
|---|---|---|---|
| value 1 | value 2 | value 3 | Average(1:3) |
Known assumptions
Results, lessons learned, next steps
Checklist
-
Fill in the experiment summary and write more about the details of the experiment in the rest of the issue description. Some of these may be filled in through time (the "Result, learnings, next steps" section for example) but at least the experiment summary should be filled in right from the start. -
Add the label of the group::that will work on this experiment (if known). -
Mention the Product Manager, Engineering Manager, and at least one Product Designer from the group that owns the part of the product that the experiment will affect. -
Fill in the values in the ICE score table ping other team members for the values you aren’t confident about (i.e. engineering should almost always fill out the ease section). Add the ~"ICE Score Needed" label to indicate that the score is incomplete. -
Replace the ~"ICE Score Needed" with an ICE low/medium/high score label once all values in the ICE table have been added. -
Mention the [at]gitlab-core-team team and ask for their feedback.