GitLab
A single application for the entire DevOps lifecycle
GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Remote Work Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management
GitLab
A single application for the entire DevOps lifecycle
GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Remote Work Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management
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.
We follow the Product Designer workflows and UX Researcher workflows described in the UX section of the handbook. In addition:
This is a pilot process we're kicking off in 12.10. The UX team will start weighting UX issues in order to better estimate capacity, realistically break down our work, and give PMs a little insight into how much work we can take on in a milestone. We aim for velocity over predictibility. This means that we don't need to be accurate, we just need to get better. This paragraph has a useful explanation of estimation that captures the spirit of what we want to accomplish with this pilot.
| Weight | Description (UX) |
|---|---|
| 1 | Mostly small UI changes leading to small incremental UX improvements. No users’ workflow involved in these changes. Requirements are clear and there are no unanswered questions. For example: A copy experiment, changing a button styling…. |
| 2 | Simple UI or UX change where we understand all of the requirements but may need to find solutions to known questions/problems. These changes should blend in with an actual user workflow. For example: Simplify Sign in / Register process the in trial flow. |
| 3 | A well-understood change but the scope of work is bigger. Several pages are involved and/or we're starting to design/redesign small flows or connect existing flows between each other. Designers may conduct extensive background research (previous issues, support tickets, review past user research, review analytics, etc). Some unknown questions may arise during the work. For example: Update the customer portal checkout page to allow subscription and billing information input, Experiment with adding a contact sales option in app. |
| 5 | A complex change where input from group members is needed as early as possible. Spans across multiple pages, and we're working on medium-sized flows that potentially connect with another area of the product There are significant open questions that need to be answered. The product designer may need to do some research on their own or in collaboration with a researcher, but this isn't always the case. Possible research activities might be to find and/or validate a Job To Be Done, conduct user testing or card-sorting, or do a survey. For example: UX Scorecard, How can we improve the dismiss action in upgrade moments. |
| 8 | Complicated changes introducing a new user flow that connects with other large flows and may require input from other designers, product managers, or engineers from the same or another stage group. This change would most likely be added to our Log of major changes. This is the largest flow design/redesign that we would take on in a single milestone. This requires research where the designer may or may not be working with a researcher to plan and conduct exploratory interviews or user testing sessions. For example: Onboard new signs up through an onboarding issue board. |
| 13 | Highly significant changes impacting multiple user flows, a large new feature, and/or a complete redesign. This issue could significantly impact product strategy and would require critical input from others (the wider GitLab community, e-group, customers), and there are many unknowns. This necessitates research where the designer could team up with a researcher and other designers to gather input data, plan and conduct exploratory interviews, lead user testing sessions… These changes should be added to our Log of major changes. It's unlikely we would commit to complete this issue in a milestone, and the preference would be to further clarify requirements and/or break it into smaller issues planned in several milestones. For example: An improved free trial sign-up experience for GitLab.com SaaS users. |
There is a limit to our product, which is that issues have a single field dedicated to issue weight, and this is usually used by the engineering teams. To pilot issue weights, teams will need to work around this limit for now, and look for opportunities to enhance the product.
One way to do issues weights is to use Parent-Child issue labels. For teams using this method, follow these suggested steps, but feel free to adapt to match your teams workflow:
link::parent and contain high level discussion and links to child issues. This should also be the SSOT for the design work.link::child. So for example, you can have a child issue for the UX work (workflow::problem validation and workflow::design), or you can break these down even further for a large project. You might also have a separate linked issue for UX Research work, as per the process by which the UX Research team works.UX or Engineering but not both. This will make sure there is no confusion as to what the weight is for.For teams that use epics and don't want to use Parent-Child issues labels, you can proceed as follows. Again, as this is a pilot, these steps are a suggestion but can be adapted as we go and we can make updates here as we refine the process.
UX and assess the issue weight. Issues larger than an 8 should be broken down further.workflow::planning breakdown.Engineering.UX or Engineering but not both. This will make sure there is no confusion as to what the weight is for.In terms of milestone planning, the UX team is following these guidelines:
Milestone Capacity:
- Total weights completed last milestone: XX
- Average capacity (last 3 months completed): XX
Current Milestone:
- Estimated capacity: XX (use the average capacity from the previous milestones and include a brief explanation if it's higher or lower)
- Total current weights: XX
- Percentage of time: [write percent of your time you will dedicate to this group and other groups, for example 50% retention, 50% fulfillment, or 75% capacity due to childcare / time off]
We do not need to apply a weight to
We should apply weights to
To start with, we follow GitLab internal communication guidelines. In addition the following tips will make it easier to collaborate with Product Designers who span multiple groups:
The order in which we approach our work can be complex, as we have priorities and severities, milestone plans, and the product design team has their own guidance on selecting the next thing to work on. Additionally, some UX issues need to be delivered earlier in the milestone than others. To help with communication you can use the Due Date field. As a PM, if you choose this route, please do the following:
The engineering team applies the UX label to any MR that introduces a visual, interaction or flow change. These MRs can be related to new issues, bugs, followups, or any type of MR. If the engineer isn't sure whether the MR needs UX, they should consult the designer who worked on the related issue, and/or the designer assigned to that stage group, or the UX manager.
Visual reviews are required for any MR with the UX label. When the MR is in workflow::In review, the engineer assigns the MR to the designer for a visual review. This can happen in parallel with the maintainer review, but designers should prioritize these reviews to complete them as quickly as possible.
There are times when it isn't possible or practical for a designer to complete their visual review via Review Apps or GDK. At these times the designer and engineer should coordinate a demo.
The UX Themes that we are prioritizing for now (FY21 Q1):
Other important themes that we aren't prioritizing for now but will look at in the future and/or in small .
Applying theme based labels to UX issues allow us to track our work more holistically against big areas we've identified for UX improvement.
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".
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.
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:
Feb 18, 2020, Epic - Released in 12.4
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.
Jan 30, 2020 - Issue - MVC expected in 12.8
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.
Jan 30, 2020 - Issue 1, Issue 2 - Expected to be delivered in 12.8
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.
