Epic: Collect information from users during onboarding

[phimae]

Context The current form fields that we have do not give us sufficient information about our users who sign up. This issue is to improve the success and completeness of initial information gathered during onboarding.

Value: We would like to capture more information about our users during the first time product onboarding. By doing so we can offer better support for our users.

Measurement

• Increase in % of successful company website form submissions
• Increase in % of valid first + last name
• No significant degradation in onboarding conversion

Update Profile Information	IDE selection modal	Start new workspace	Phone number verification
if (user has not already provided info AND is 24 hours after user sign up) OR the last update was 1 year ago	If user has no IDE preference, shown after login (typically first)	Open workspace modal, this information is asked for when clicking "new workspace"	If user .... AND on workspace start
			-

---

Design Decisions

• ☑️ First name + Last name presented to user as separate
• ☑️ Ask for company email, not company
• ☑️ Ask for IDE preference during onboarding flow
• ☑️ Consolidate both IDE selection and profile information modals
• ☑️ Implement as either a modal, or a full page
• ☑️ Implement the onboard as a three step, not a one step flow
• ☑️ Steps will not be dismissible, but some fields will be optional / skippable.
• ☑️ We won't show a step indicator for now
• ⁉️ Validate fields on each step (if possible), submit at end (if possible)
• ⁉️ Ordering of the three step flow (personalisation first?)

Work

• Track ide changed event during onboarding #16568
• Removing company input field from profile form #16569
• Extract a CheckboxInput component from onboarding flow #16545
• Adjusting onboarding copy for better readability #16570
• Add confetti after new onboarding flow #16543
• New User Onboarding Flow UI #16501
• Prep for new onboarding flow #16469
• adding new profile fields for new onboarding flow #16467

Future Iterations

1. Bump the existing user base for information (mark tainted data for some users)
2. Request additional qualification information (company size)
3. Request additional disqualification information (students)
4. Re-prompt on subsequent logins if not entered information
5. Move information gathering async (notifications center)
6. Request for information in other parts of the product experience
7. Introduce monetary incentive to submit information (e.g. credits)

Previous issue contents

See internal [RFC](https://www.notion.so/gitpod/Bring-light-into-the-user-black-box-Ask-for-more-information-d239d92f611641778a251952cb011a70) for more context.

Current Behavior
The current update profile information modal is shown on second login but the larger part of users don't log in again but still could be an interesting persona from a target company.

Intended Changes

• Maintain existing modal
• Change it to show on sign-up, and not on following sign-in
• Remove "Dismiss" button. The close button is already there.
• Remove avatar
• Split the "Name" to "First Name" and "Last Name". I understand that "Full Name" would be better, but I'm afraid most won't bother
• Email remains
• Replace Company with Company Website. We should maximize the chances that it is correctly formatted, without increasing friction. Maybe adding a placeholder example or starting already with "www."?
• Remove Git related text from description.

This modal does not need to show in Gitpod Dedicated

Potential Future Iterations

• Greet the user with their first name in the dashboard (e.g. Hi Bob, start your first workspace with cmd + O)
• If no company website is given but a team is created, prompt to ask for company domain
• Include this modal with the IDE selector / the cmd+ O quickstart modal as a "get started" flow (Step 1, 2 ..)
• Match domain with others -> no others --> invite colleagues. If >2 others --> Get in touch with your colleagues and create a team
• After creating a team --> there are xx other users from xyz.com, invite them to your team (from projects screen)
• Matching users with the same domain name

Related issues:

• Replace the editor selection cards with the new dropdown component used in the start with options new workspace modal #13116

[jldec]

Scheduled for next iteration.

See original design in #11023

Note that the prompt happens on the 2nd day after signup (I believe it's independent of whether the user logs in or not).

Suggestions

• The change for the prompted fields should be applied to both the modal and the user settings.
• The modal does not require the blurb at the top about git env-variables.

[phimae]

Thanks @jldec!

Note that the prompt happens on the 2nd day after signup (I believe it's independent of whether the user logs in or not).

Correct, with this issue I am proposing to show it right after signup so that we may get information from the 77% of users who never log in a second time (but with information we can still reach out to them)

The change for the prompted fields should be applied to both the modal and the user settings.

100% - thanks for the catch

The modal does not require the blurb at the top about git env-variables.

Agree, that's what I meant with "Remove the description text about the Git configuration if possible"

[svenefftinge]

We might want to have an explicit "Welcome to Gitpod" experience, that includes initial setup steps and information, such as editing profile information, but also things like picking preferred IDE, etc. It seems like bolting on modal after modal isn't an ideal experience for new users 🌱

@gtsiolis Do you have the capacity to design a welcome page that includes the information this ticket asks for and the initial IDE setting, as well? Would be great to have a full landing page that we put before any other page and not use modals.

[gtsiolis]

Thanks for hanging here, everyone! Took a closer look at the linked RFC and the problem statement above. 👀

Cc @jldec @phimae

Listing some thoughts below:

1. It's worth noting that the editor selection is a mandatory step for every new user signing up, even if they won't go through the dashboard.
2. The problem of users not coming back is probably not related to the editor selection or profile update step but that's a different discussion.
3. The idea @svenefftinge describes above in Epic: Collect information from users during onboarding #15857 (comment) to combine the editor selection and the profile update sounds good.
   • Could be worth ordering the editor selection first so that users actually can get some value out of this action.
   • We could minimize the profile information layout by shrinking the avatar, skipping (or removing completely the company field, removing the variables related information at the top, and of course replacing the editor selection cards with the new dropdown component used in the start with options new workspace modal (Replace the editor selection cards with the new dropdown component used in the start with options new workspace modal #13116).
4. The proposal above[1][2] to remove the Git and variables related information on the profile update step sounds absolutely logical. This was probably left there as a first iteration (skateboard) to get this in the sooner, see relevant comment in [dashboard] allow editing user information #11023 (comment).
5. Renaming Email to Work Email sounds good.
6. Using a field for the Company name was being tracked in Replace 'Company' with 'Company Name' in account profile #11182 but we never got around it. Maybe it does not help much or create a good incentive for the user to bother updating this, see also relevant comment in Replace 'Company' with 'Company Name' in account profile #11182 (comment).
   • Does it make sense to measure how many users have actually set this field?
   • Isn't the work email sufficient for what's needed here?
7. I'd highly recommend avoiding splitting the name into two fields for first name and last name. Instead, we could rename Name to Full Name.
8. To create some basic incentive for users to bother updating their full name or work email, we could use the section subheading.
   • Currently, this information is only used for authoring commits.
   • Later on, we could use this to suggest teams to join, etc, see screenshots below.

Taking into the above, I made some quick drafts on how this could looks like as a modal or a full page.

Welcome (Modal)	Welcome (Full page)

[svenefftinge]

Thank you 🙏
We could use multiple pages so they are less crowded. Also the "you are logged in as foo from GitLab" doesn't seem helpful. Can we do without?

[gtsiolis]

Can we do without?

We can start without it, although it does provide a hint that an account has been created or associated with the form below.

We could use multiple pages so they are less crowded.

@svenefftinge Something like a two-step flow?

Step 1	Step 2

[phimae]

Hi @gtsiolis! Thanks for your reply and the nice looking drafts. Really like the two bars that indicate what's coming. I also thought about having a third step that just says "start workspace" but I think @svenefftinge wasn't a big fan when we discussed.

The problem of users not coming back is probably not related to the editor selection or profile update step but that's a different discussion.

I agree - my point was more about missing out on a substantial share of users whose information we would never get if we kept it on 2nd day (as they don't come back for a 2nd session)

skipping (or removing completely the company field

We would like to name it company website and keep it please

Does it make sense to measure how many users have actually set this field?

We do that already through the profile_changed track call - 3% currently change the company name

I'd highly recommend avoiding splitting the name into two fields for first name and last name. Instead, we could rename Name to Full Name.

Understand how that feels unnecessary, but there are two reasons why this is important: 1. We can personalise comms for the user better (so far we can only say "Hey there" or "Hey gtsiolis") and 2. we need a proper name split into first and last for enrichment

To create some basic incentive for users to bother updating their full name or work email, we could use the section subheading.
Currently, this information is only used for authoring commits.
Later on, we could use this to suggest teams to join, etc, see screenshots below.

Love that, would be great if we could demonstrate value for the user with this! Had some similar thoughts in the Future Iterations paragraph in the issue description

[phimae]

Hi @svenefftinge and @gtsiolis - just came back from PTO and wanted to check in to see if there have been any discussions around this while I was out?

[atduarte]

Given the constrained capacity, I would suggest we go with something very small for now.

To get to a decision faster I will suggest a set of changes, but if you feel strongly about any feel free to change:

• Maintain existing modal
• Change it to show on sign-up, and not on following sign-in
• Remove "Dismiss" button. The close button is already there.
• Remove avatar
• Split the "Name" to "First Name" and "Last Name". I understand that "Full Name" would be better, but I'm afraid most won't bother
• Email remains
• Replace Company with Company Website. We should maximize the chances that it is correctly formatted, without increasing friction. Maybe adding a placeholder example or starting already with "www."?
• Remove Git related text from description.

👍 ?

[gtsiolis]

Thanks for chiming in here, @atduarte!

Adding some comments below on the proposed MVC above in #15857 (comment). Besides two minor issues, all changes you suggest seem like a good iteration. Cc @phimae @svenefftinge

Maintain existing modal

DEAL—Sounds good for this MVC iteration. 🤝

Change it to show on sign-up, and not on following sign-in

❗ issue: This would conflict with the editor selection modal which always shows up on sign up, right?

💡 suggestion: A counter-proposal MVC proposal here could be to reuse the two-step modal we've used before for informing users about changes, see #4607. The code is already there—we could just adapt it to host both editor selection and profile update steps. Given the upcoming changes in #13116, this could make the transition between these two steps better.

Remove "Dismiss" button. The close button is already there.

💭 thought: I would keep that there for accessibility, but we could try dropping it, too.

Remove avatar

DEAL—Since we don't currently support updating or removing the avatar, skipping the avatar sounds good and also aligned with the proposals above in #15857 (comment) and #15857 (comment). 🤝

Split the "Name" to "First Name" and "Last Name". I understand that "Full Name" would be better, but I'm afraid most won't bother

💭 thought: I'm probably missing something here, but I still see little to no value for this change besides the unnecessary visual noise and extra friction in the onboarding, however, I don't want to hold this back. Let's break it into two parts and revert (merge) later if we run into any issues.

💡 suggestion: A middle ground solution could be to follow the proposal in #15857 (comment) to use Full Name as the label. Remember that currently this only shows up as Name. But I understand this may not help us move towards the goal of these changes. Let's keep the First Name and Last Name as an inline form, not stacked vertically as the rest of the form fields.

Email remains

DEAL—This could be improved by renaming the Email to Work Email, but leaving this as is sounds also fine, if not better. 🤝

Replace Company with Company Website.

❗ issue: I find this quite error-prone and less appealing to users than typing out the org (company) name. Isn't work email or company name helping here? Users are already using their Company (Org) name in the corresponding SCM providers. Could we instead first try to auto-populate this Company (Organization) field from the SCM providers, as all of them support such a field?

💡 suggestion: We could replace this field with Organization instead (see relevant comment in #11182 (comment)) and try to auto-populate this field from the relevant field which exists in all supported SCM providers.

Remove Git related text from description.

DEAL—I believe this is one point that everyone agrees on. 🤝