The Growth area is made up of Fulfillment, Telemetry and four Growth groups which focus on improving specific metrics. We don't have our own product. Instead, we make the experience of paying for GitLab and managing licenses as easy as can be. We also look for strategies to help customers discover the value of the product, thereby increasing the number of customers and users. GitLab believes that everyone can contribute, and this is central to our strategy.
The Growth UX team aligns closely to user experience flows rather than with PMs. Designers are not “assigned” to a particular PM, rather they are the first point of contact on UX related to that flow, with flexibility built in to even out the workload and ensure UX experts work on things they are subject matter experts on. This will allow us to cover all the areas of Growth, including fulfillment. It allows designers to own one area but to also have expert knowledge of other areas of Growth's responsibilities.
We also have designated leads for large experience areas, as noted below.
Not sure which designer to talk to about a particular issue? Create your issue and tag it with UX. You can also reach out to the Growth Slack channel (#s_growth) or mention the product designers in issues @gitlab-com/gitlab-ux/growth-ux.
The Product Designer applies the milestone in which they plan to deliver the work (1-2 milestones in advance, or backlog for items that are several months out. For example, if an issue is not doable for a designer in the current milestone, they can add the next milestone to the issue, which will communicate to the PM when the work will be delivered.
If the PM has any concern about the planned milestone, they will discuss trade-offs with the Product Designer and other Growth PMs.
Themes and Focus Areas
The UX Themes that we are prioritizing for now (FY21 Q1):
Applying theme based labels to UX issues allow us to track our work more holistically against big areas we've identified for UX improvement.
Customer Journey/Process for Fulfillment/Customer Transactions
When working through transactional issues related to sign-up, trials and upgrades it helps to break down the task into pieces. This way of working through issues enables product designers to document the beginning and end of a user journey in an easily digestible way for everyone. It's based very loosely on a talk from Jared Spool regarding "Content and Design".
Entry Point(s): The initial touch points of user interactions. (i.e. A Page, CTA or Form etc)
Decision: Giving users the ability to decide on Products, Options or Packages.
Confirmation: Summary of a successful or unsuccessful purchase.
These steps won't always be needed and won't always be linear. For instance, an Entry Point may also be a point at which a user selects a Product.
All of the planned, in progress and completed UX Scorecards for Growth can be found in this epic.
For more information, read about UX Scorecards.
Scorecard: Renew a GitLab Plan
Job Description: TBD: When (situation), I want to (motivation), so I can (expected outcome).
UX scorecard issue (with walktrhough and video): 113 (WIP)
UX scorecard Score: TBD
Recommendations Epic: TBD
Scorecard: Start a GitLab trial
Job Description: When creating a new account, I want to start a trial, So I can test GitLab.com Gold features.
UX scorecard Epic (with walkthrough and video): 1332
Job Description: When I realise my team needs a feature from a higher tier than our current paid one, I want to quickly and easily upgrade (to that tier), so that they can benefit from it as soon as possible.
UX scorecard issue (with walktrhough and video): 113
This is a log of major changes introduced by the Growth UX team as part of their work with the Growth subgroups. It serves as an easy way to track down when and why a major change to a user experience was introduced.
We define "major changes" as:
Major layout/IA changes on a single screen
User experience changes across multiple screens (flow changes)
Increasing/decreasing the number of interactions it takes to complete a task
Changing the content of something at a critical step for the users (a banner warning for example)
Changing when and where something that is triggered by the system happens (when and where a banner shows up and what triggers it)
Introduced the new, simpler free trial signup flow
Last year we introduced a simpler free trial sign up in which a user could complete the process by interacting with one app only. Before, they had to create a separate account in the Customer Portal app which often led to confusion.
Provide more context and guidance for true-ups in the renewal flow
Users didn’t know what number to put into the Users over license field in the renewal flow which resulted in new licenses that threw errors. They also didn’t know what number to put into the Users field so we renamed it so it aligns with the data and labels in the Admin Overview. The MVC will be shipped without the illustrations but is still considered a major improvement. This change as a whole is an intermediate step before we move towards automatically collecting the data.
Changed the appearance, content and behavior of renewal and auto-renewal banners
Existing banners were confusing the users because they lacked contextual information. Auto-renewal banners, for example, didn’t make it clear that the subscription will automatically renew. Banners were also non-dismissable and shown to all users instead of just the instance admins. This change introduced a new appearance, new behaviour (who they’re shown to and when) and more contextual content.