The UX Department works alongside the community, Product Managers (PMs), Frontend engineers (FE), and Backend engineers (BE). PMs are responsible for kicking off initiatives and setting the product direction. PMs define the "what" and "why" for feature-related issues by gathering customer and user feedback, and they give GitLab team members and the wider community space to suggest and create.
UX should assist in driving the product vision early in the process. We inform the vision by conducting generative research and facilitating discussions with community members, customers, PM, FE, and BE. We are elevated above just the transactional workflow and generative in creating work, rather than just executing tasks.
Our mission is to collaborate with the wider GitLab community and fellow GitLabbers to rapidly create products and experiences that customers value over competitor products and toolchains. To achieve our mission, we commit ourselves to being:
The UX department is not solely responsible for the user experience of GitLab. Everyone is encouraged to contribute their thoughts on how we can make GitLab better by opening an issue. You can use just words or include images. These images can take a variety of forms; here are just a few examples:
If you are creating high-fidelity designs, please make sure to let others know that this is a proposal and needs UX review. You can ping anyone on the UX team for assistance.
We'll always have responsibility for reactive tasks that help "keep the lights on," such as bug fixes and minor UX enhancements. But we also must carve out some portion of our time for proactive work that identifies existing pain points, redefines how we approach problems, and uncovers actionable innovation and improvement opportunities. This proactive UX work enables us to create the most complete, competitive, and resilient solutions.
It isn’t always easy to find the space for proactive UX work, but the challenge is worth it, because it's how we create a best-in-class product experience. And it's not just the UX team's responsibility; it requires a coordinated effort from Leadership, Product, and Engineering, too.
We're currently working to find the right balance between proactive and reactive UX work. While we don't have a prescriptive ratio, we also don't allot 100% of our available work time to reactive efforts. Before and at the start of each milestone, UXers should work with their managers to define the appropriate ratio, based on our active OKRs and stage group requirements. When there are questions about priority or scope, or when a UXer is concerned about meeting a deadline, they should immediately reach out to their manager to help them resolve any concerns. Comunicate early and often!
One example of proactive UX work is our Experience Baselines and Recommendations initiative. Another example is the generative research that our UX Researchers lead (while inviting cross-functional partners to participate). Yet another example is the ongoing effort to beautify our UI, both through small, tactical changes and through our Pajamas Design System.
Experience Baselines and Recommendations
Designers use Experience Baselines to benchmark common user tasks. In many cases, tasks involve multiple stages of the product, giving designers visibility into how users traverse across stages. Designers follow with Experience Recommendations for how to improve the experience in upcoming milestones.
Here at GitLab, iteration means making the smallest thing that adds value and getting it out as quickly as possible. Working like this allows us to reduce cycle time and get feedback from users faster, so we can continue to improve quickly and efficiently.
Iteration isn't just one of GitLab’s six founding values, C.R.E.D.I.T, it is one of the foundational concepts in design thinking and user experience. Planning too far ahead without real-world feedback can cause you to build something that doesn't meet user needs.
Iteration is especially vital in an open-source community. Keeping changes small and iterative makes it easy for anyone to contribute. Here are some examples of how we are embracing the power of iteration and using it to build GitLab:
Every Product Designer is aligned with a PM and is responsible for the same features their PM oversees. Technical Writers each support multiple stage groups and at least one complete stage (up to four) with the goal of supporting only one stage per writer by the end of FY-2020 per the current hiring plan. UX Researchers support multiple PMs from across one or more sections.
UXers work alongside PMs and engineering at each phase of the process: planning, discovery, implementation, and further iteration. The area a Product Designer or Technical Writer is responsible for is part of their title; for example, "Product Designer, Plan." You can see which area of the product each Product Designer or Technical Writer is aligned with in the team org chart.
In the spirit of having "stable counterparts," we plan headcount as follows:
Taking time off is important. It is equally important to come back to work and feel refreshed. We discourage team members from checking work-related activities while on leave as a way of feeling less overwhelmed when returning. To prevent this, your stage design peers, or manager if you do not have stage design peers, will serve as your backup when you are on PTO by:
Backups are responsible for addressing critical UX work while a designer is away. Critical UX work is defined as any work that addresses an outage, a broken feature with no workaround, or the current workaround is unacceptable. If a backup begins to feel overwhelmed with workload, they should immediately reach out to their manager for help. Your manager will be able to help further delegate tasks when necessary.
When taking an extended time off, such as Paternity leave, work with your manager to communicate with the relevant stable counterparts to ensure that UX workload for that stage is reduced in order to avoid burnout among other designers on the team.
When returning to work, you are not responsible for responding to every To Do that accrued while you were away. Utilizing a tool such as PTO Tanuki helps reduce outdated mentions upon returning.
We believe that strong cross-functional collaboration between Product, UX, and Engineering leads to the most successful products.
These roles should be well balanced, so that each group can contribute to the product and make informed decisions about what to build and how to build it. Collaboration enables us to build features that are desirable, usable, and feasible. It also helps GitLab to achieve business goals, delight users, and build software that's high quality, fast, and secure.
There are three essential parts to great collaboration: shared processes, appropriate tools, and psychological safety.
A shared process for how we work (that everyone on the team understands) is essential to collaboration. If we don't understand how we work, then we can't work together well. A handbook section written in cooperation with Product, UX, and Engineering is in development and will serve as the SSOT for our Dual-Track Agile process. For now, be sure that you are familiar with the Product and Engineering teams and how they work.
We follow a Dual-Track development approach that helps us work smarter, faster, and more collaboratively. In this model, one track of work focuses on validating what adds value to our product and another track of work focuses on building what has already been validated. These tracks run concurrently during every milestone.
UX research and design are essential components of both tracks. Talking to customers or potential customers to understand their problems is at the core of this idea.
Here at GitLab, we are adopting concepts from this model over time. Currently we're doing a good job on the Build track, but we want to shift more attention to the Validate track (we also talk about this as reactive vs. proactive UX).
If you're interested in learning more about Dual-Track Agile and other methods for producing awesome products, you can check out the book Inspired by Marty Cagan. If you don't want to read the entire book, you can try this summary or Blinkist.
We have a lot of collaboration tools available to us at GitLab. It's our responsibility to select the best communication medium for the situation and to understand when and how to use our tools. Zapier, another all remote company, wrote an article about collaboration tools and methods that help foster communication among remote teams.
People thrive in environments where they can bring their unique perspectives to work, put ideas forward without fear, and openly debate and critique ideas in a healthy and productive way. Read more about Trust on Teams and why it matters.
The remote and asynchronous way we work can make it hard to know when collaboration is needed. Here are some things to think about:
UX readylabel when the work is ready for the Build track. Just before UX Ready is a great time for PM, UX, and Engineering to sync up a final time to make sure the issue is indeed ready for development. Learn more about how we use Workflow labels in the GitLab Docs.
The beginning of an epic is a good time to talk through the big picture with the product manager and rest of the team as often as possible. Visuals like journey maps and screen or user flows can help keep everyone on the same page and make these discussions richer.