UX scorecard Recommendations for Starting a trial
[UX Scorecard part 1](https://gitlab.com/gitlab-org/growth/product/issues/166): user journey map, grade, video-documented flow (Walkthrough and 2 user testing session). # Recommendations for improvements & next steps ## 1: Facilitate decision making A lot of information is being thrown, it's hard to understand where is the value of the trial. How is this helping user's Job to be done? Which GitLab plan users will try?... We should be clear at the beginning to avoid doubts and confusion during the process. #### Step: Trim down information to the minimum viable * [ ] Research on self hosted trial * Get at least quantitative data on self-hosted trials usage as a starting point. * If no data, run a survey self-hosted trials. Is this a legitimate option to start with? If not, shall we keep it as a choice? Shall we ask SaaS users if they would like to install GitLab at the end of their trial? * [ ] Clearly state which plan and the related set of features users are going to try. * Adjust the current or create a new starting page for the trial flow? * [x] Simplify Sign-in / Register process the in trial flow #### Step: Ensure entry points to trial are clear and global * ~~[ ] Test adding a "try for free" CTA under Gold in the pricing page.~~ * [X] Add "Try GitLab for free" CTA instead of register in the top nav of about.gitlab. *How de we measure success? -> Significant increase of traffic in the trial flow and potential increase of IACV generated from trials.* Sub-epic:https://gitlab.com/groups/gitlab-org/growth/-/epics/8 ## 2: Tailor the steps based on users type, Teams v.s Individual The steps required to complete the trial process could be trimmed based on users type. Eg. An individual won't be able to provide the same information as a company, therefore we should take this into consideration and not ask for it. #### Step: Define user type beforehand * [x] Create a map of the current scenarios * [x] Know if a user is trying GitLab for his company or for his individual usage * Use the second step of the current registration process to get this information? #### Step: Personalise the form * [x] Display/hide form fields based on user input * All company related information should not be ask for individual users. * [x] Experiment: For users setting up a trial for their team, remove the option to attach subscription to a namespace. Observe the impact. * For signed-in users prefetch required information to start the trial. * [x] Iterate on pre-filling information in trial flow. * Fetch all the information needed if given by users. * [x] Remove active trials from subscription list in the trial flow * Existing users can not attach a trial to a group with an active trial, we should remove this item from our dropdown suggestions #### Step: Simplify * [ ]~~Implement soft confirmation email instead of Captcha.~~ * [x] Experiment: Remove the newsletter step and observe the impact. (Or modify copy). * [x] Experiment: Remove the phone number field or find another way to get the information, if necessary. * [x] Give users the ability to register for a Free Trial via SSO (Social Sign-on, Google, Twitter etc) * [ ] Simplify access to ToS * To avoid sending user out of the flow, should we use a modal? * [x] As a new user of GitLab going through the registration process, seeing the "sign-in" tab is confusing, I should not have this option. * Split the Sign-in / Registration pages and route users accordingly. *How de we measure success? -> Decrease time to completion of the flow (AVG time spent on pages, Bounce rate)* Sub-epic:https://gitlab.com/groups/gitlab-org/growth/-/epics/9 ## 3: Prepare the onboarding After a user completed the trial flow, we are not welcoming them and helping them using efficiently the app. Perhaps we should consider using the data we collected during the registration process to tailor the onboarding and the next action to take. * [x] Iterate on trial confirmation for existing SaaS users * [x] Redirect .com users to onboarding after they signed-up and started a trial #### Step: Make relevant usage of the data collected * [ ] For a company, consider offering the following suggestion: * Add members to the newly created group? * Import / create a project? * Promote the most used feature of the plan? * [ ] For an individual, consider offering the following suggestion: * Import / create a project? * Promote the most used feature of the plan? *How de we measure success? Changes in DAU.* Onboarding main epic: https://gitlab.com/groups/gitlab-org/growth/-/epics/4 ## Later: Follow-up We should follow users during their trial process and subtly nudge feature usage by proving their values, we could use different channels to accomplish this: * Emails * Start of the trial. A welcome email paired with the soft confirmation? * Mid-trial. Curate and promote a specific set of features users could find helpful? * End of trial. Based on feature usage, offer a "personalised plan"? for example, Bronze with more CI minutes... * End of trial. Survey users that do not wish to upgrade. * Helpers/ in-app Product tour * Onboarding tasks? * Gradually introduce features. (Once a week? On a given day?). * Reward usage through extended trial length or more CI minutes: * Team created X number of projects/group, * Team used X feature, * Team/Individual choose to self-host GitLab after using SAAS, * Individual/Team did X contribution to an open-source project... *How do we measure success? -> Changes in DAU, Increase in MRR, Increase in Net retention.* ## Later: Expand the experience Our trial process is currently a one-size fit all process and is mainly oriented toward using GitLab Gold, doing so we may be loosing on opportunities to demonstrate how users could beneficiate from GitLab by trying out other plans. This idea seems to correlate with the data we have, in periscope we found that of all the trial upgrades in the last 3 months, 7.07% upgrade during or after the trial. Of that 7.0% that upgraded, 6.22% purchased Gold, 39.74% purchased Silver and 54.03% purchased Bronze ([source](https://app.periscopedata.com/app/gitlab/499372/WIP---AA-Growth-Conversion---Trial-Conversions)). #### Step: Research * Run a survey / Exploratory interviews on the logic behind starting a trial for GitLab, what are the expectation?(Increase speed...) What are the decision factors? (features, price...) Would self-hosting GitLab for a 30 day trial be relevant? * Get quantitative data to assess the demand of other plans to consolidate the qualitative findings. #### Step: Improve the trial entry points based on the findings * Give the ability to trial other plans? * Landing page, suggest plans based on users needs? *How de we measure success? -> Increase the total IACV we generate from trials.*
epic