Design an improved onboarding experience for a new user
Description
This is the first screen a GitLab.com user sees upon signing in to the site, until they create a project:
This view has a few missed opportunities. It doesn't help them:
- Get introduced to the product in an interactive way. We link to the docs, but we could do quite a bit more.
- Invest in the platform, aside from suggestions to create a project (good) or an empty group (not quite as good).
- Feel good about being a part of GitLab. We should make this screen a welcoming experience.
- Introduce the user to our open core model, how they can contribute.
At some point, we should also consider a different experience for different user types (an admin, a GitLab.com user, CE vs. EE, someone on Gold/Ultimate vs. Free/Core). We should deepen the experience in line with onboarding users into the different stages of I2P.
Products to explore:
Proposal
- Make the first screen a welcoming, celebratory experience that encourages the user to take a critical action (create/import a project, or explore GitLab features).
- Introduce the user to the high-level stages of GitLab's I2P workflow, and give them the ability to explore.
- One possibility is creating a dummy project, seeded with examples.
Progress
Current onboarding user journey
Comment: It takes 37 actions from users to sign up for the free trial.
Video-documented attempt to sign up for a trial
Problems to solve
- single & standard journey for all users
- not exposing what GitLab has to offer (not even the basics)
- the users are limited in terms of what they can do (no free trial by default, except if the user clicks on the ‘Try GitLab for Free’ on the marketing site)
- no structured & organised way to learn about the core GitLab features in a short time
- users aren’t encouraged to perform any actions after signing up
- the process for signing up is a pain. Users go through a rollercoaster of shifts in their goodwill to eventually land on a welcome page (or even just the billing page in case of free trial sign up)
- email confirmation in the sign up form
- CAPTCHA
- email confirmation (almost there)
- trial sign up asks for things we already asked for + additional info, it’s split into two pages (the second step seems unnecessary)
- After sign up, we send them to the User profile > billing page
- Users receive an email from sales, thanking for the purchase (free trial). This could be confusing and should probably be handled differently.
- Users don’t receive a welcome email that would also provide links to educational content, showcase our features, encourage further actions from the user
- not welcoming, no personalization
Questions
- What happens before users sign up? What pages do they view? What convinces them to sign up? Could their motivation for signing up affect the onboarding later on?
- How many users drop out of the sign up process?
- What are the magic moments for our user personas? How can we recognise & match users to these personas in the onboarding and adapt it so that we get them to the ‘a-ha’ asap?
Future onboarding user journey
Comment: In 39 actions (almost equal to the 'current onboarding journey') users sign up for the free trial, find out how issues work and create a new label and add it to an issue (through guided onboarding).
Goals of the redesign
OKRs:
Improve the onboarding experience for new GitLab users by decreasing sign-up time to 1 minute or less. Document the existing user journey in video, propose a new sign-up flow, test it with users, iterate based on feedback, and implement the new workflow.
Provide a guided onboarding experience that helps new users become productive in GitLab more quickly. 80% of new users should start guided onboarding, and 80% of those who start should finish. Create a user journey of current experiences and pain points, propose and test a guided first-time experience, iterate based on feedback, and implement an MVC solution.
- design an onboarding for the first 30 mins, focus on users goodwill (reduce choices) and make them create/do something meaningful (improve acquisition, activation and retention)
- improve the sign up process (improve acquisition)
- Familiarise users with core features in < 10 mins (improve activation)
- Projects, groups
- Issues, labels + boards
- Milestones
- Repository + MRs
- Setting up profile + status
- Epics
- increase the perceived quality of GitLab as a product and consequently the desirability of it: a-ha moment (improve activation, retention, referral)
Challenges
- keeping the onboarding up to date
- onboarding training needs to persist even if the user opens a link in a new tab
Solution
- User flow
- Add 'Learn GitLab' to help menu
- Main 'Learn GitLab' helper interactions
- Exit 'Learn GitLab' interactions
User flow
The popovers should animate in with a slight delay after the page loads. I'd suggest we start with a 1 second delay and an animation similar to this.
Task progress:
- Part 1/3:
- Project overview
8% complete
- Repository overview
16% complete
- Commits
24% complete
- Commit details
32% complete
- Branches overview
40% complete
- Compare
48% complete
- Issues (list)
56% complete
- Issues filtered by ~"Accepting merge requests" (list)
64% complete
- Issue page
72% complete
- MRs overview
80% complete
- MR details
88% complete
- CI/CD
96% complete
- Pipeline details
100% complete
- Project overview
- Part 2/3
- 'New...' menu dropdown
- Create a project
50% complete
- Project overview
100% complete
- Part 3/3
- Settings
33% complete
- Members
66% complete
- New members added
100% complete
- Settings
User avatar:
No avatar | Gravatar | User-set avatar |
---|---|---|
Add 'Learn GitLab' to the help menu
If the tour is started by going to 'Learn GitLab' in the help menu, the welcome text changes to 'Welcome to Learn GitLab'
The main 'Learn GitLab' helper interactions
Learn GitLab helper specs + annotations
The positioning of the helper:
In the prototype, the position of the helper varies sometimes. That seems like a bug in Sketch. The positioning of the helper should be consistent.
Exit interaction
Ideally, we should gather feedback from users that go through the onboarding journey (as illustrated in 'With feedback'). If that's not possible for the MVC we can skip it ('Without feedback')