The UX Department works alongside the community, Product Managers (PMs), Frontend engineers (FE), and Backend engineers (BE). PMs are responsible for kicking-off initiatives, taking action, and setting the direction of the product. PMs don't own the product; they gather feedback and 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, as well as facilitating discussion 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.
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][pajamas].
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 possible 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 stages.
UXers work alongside PMs and engineering at each stage 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.
Product Designers and Technical Writers may also serve as a "backup" for other areas of the product. This area will be listed on the team page under their title as an expertise; for example, "Plan expert." UX backups should be just that—backups. They are there to conduct UX reviews on MRs when the assigned UXer for that area is out. The UX lead for a given area should coordinate with the PM and their backup during scheduling for any work that is critical. Critical UX work is defined as any work that addresses an outage, a broken feature with no workaround, or the current workaround is unacceptable.
In the spirit of having "stable counterparts," we plan headcount as follows:
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.
In product development, there is a concept called Dual-Track development, which helps us work smarter, faster, and more collaboratively. In this model, there is one track of work that is focused on Discovering what is valuable and another track of work focused on Building what has been proven. These tracks run concurrently, with some time during each milestone devoted to Discovery of new information and some time devoted to Building what we're already confident will work.
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 Discover 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:
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. You should review a new design idea with the product manager and developer before it gets finalized with high-fidelity assets or specs. Remember: