At GitLab, change is part of our DNA. We embrace constant iteration and evolution in our product and our company.
This year, much of the change we’ve experienced has been due to company growth. We’ve literally doubled in size, increasing from around 400 to over 800 team members in a very short period of time. Naturally, that growth brought changes to how we organize our product teams. What were once small, interdisciplinary stage groups quickly grew to become multiple, dedicated teams within each Stage. For example, in Secure, we saw the creation of three separate teams, all with dedicated Engineering resources and Product Managers.
On the UX team structure side of things, we knew we needed to support our Stage by creating a similar division of responsibilities. But questions kept coming up: How would we divide our efforts while still creating an integrated experience? And how could we address some gaps that were already becoming more evident as we scaled?
We decided to treat this problem like we do any other UX challenge. First, we clearly identified the problem:
How might we maintain our effectiveness as a design team within an evolving company structure?
With the problem identified, we began iterating through solutions and identifying subtasks and processes that helped to solve it.
Something we learned early on is that what we create today will likely be outdated next week... and we’re okay with that! Problem solving for scale and unknown change is difficult. Something that works with a team of 3 might not work with a team of 6. We were going to have to be flexible. We didn’t come out with exact answers or a silver bullet, but we did discover some best practices that helped along the way.
Taking the guess work out of UX
UXers are a curious bunch. We’re always asking questions: who are our users, what problems are we solving, and why are we solving them? (And then we ask why again.) The purpose of these questions is to help remove guesswork from our proposed solutions. We wanted to approach solving this problem in the same way.
So, we started by putting together a foundations document that asked all of the usual questions. Then, we shared it cross-functionally, so anyone could contribute to the answers and add more questions.
We learned that we knew some things, but there was also a lot that we didn't know. That’s OK, because what you don't know can sometimes be more important than what you do know. Open questions can serve as a checklist of information to uncover.
Asking (and answering some of) the questions in our foundations document resulted in the first iteration of our Secure UX page. This page will grow over the next year, as we get to know our users and problem space through research, UX Scorecards, cross-stage collaboration, and talking with users. The key insights we gain will continue to inform our handbook page for shared team awareness.
Andy: "Having this document in place helped us take inventory across the entire Stage of where the knowledge gaps exist and focus our efforts toward uncovering critical information."
Kyle: “When I joined the team, the foundations document project was a great way to peel the different layers of our product, drive conversation, and better understand cross-functional motivations. I’m elated that other stage groups have adopted the process and found it helpful!“
Getting to know your team
Early on, we realized that we needed to have more face-to-face time than we were accustomed to. We met this challenge by having weekly 1:1s with each other and maintaining a consistent cycle of coffee chats with our Stage group counterparts. (It’s a little like doing user research to understand pain points and possible areas of confusion.)
When a team is rapidly growing, it's crucial to embrace collaboration and transparency. Surfacing challenges early allows for opportunities to emerge before a problem does.
For us, there was no shortage of hard conversations and growing pains, but that was when real growth and progress happened.
Maintaining and cultivating relationships with the team and the Stage has enabled us to have more productive conversations. As an unexpected result, we work more effectively asynchronously now more than ever and rely less on ad-hoc chats and meetings. But we still have our coffee chats and 1:1s. We aren't giving those up!
Kyle: "Sharing your vulnerabilities with each other is a powerful way to bring you closer together and evolve your team’s relationships. Establishing mutual trust compounds the effects of collaborative efforts and can be the difference between success and failure of a project."
Andy: "It's refreshing to be able to know and understand teammates’ thought processes, decision tendencies, and the way they like to communicate. It was a challenge, at first, adjusting to more synchronous communication and collaboration, but the results speak for themselves."
Sharing work and splitting work
Something we realized after becoming a two-designer Secure UX team was that we were both trying to become experts on a diverse range of security topics. It’s an intrinsic trait of designers that we want to "know all the things," so we can be informed when making design decisions.
Unexpectedly, though, we were overlapping each other's work, which meant we weren't finding success or collaborating well.
By not having a dedicated area of focus within the Secure Stage, we each had conflicting views and approaches to the same features. We were continually "rebasing" our design and exploration work because of UX conflicts that manifested.
So we hired a UX manager.
Just kidding!!! But when our new manager, Valerie, joined our team, she was able to guide us toward creating areas where we would have ownership.
Coincidentally, the engineering team also split within the stage groups at this same time, giving us the opportunity to create dedicated areas of focus and align better with our counterparts.
We started the task of creating separate UX areas by running a quick brainstorming session with the Secure UX team (just like we do at the beginning of a new project). From there, we looked at the areas our Stage categories were meant to cover, and we began aggregating that information into this mural board. It was the same affinity mapping process we use to look for commonalities in research findings or stakeholder requirements..
What the affinity map helped us quickly see was: while there were areas of clear ownership where we could split work, there were areas where we needed to share work, too. This issue summarizes what we learned.
Shared work
Here’s the work that we decided to share:
- Interacting with vulnerabilities
- Status, reporting, and metrics for vulnerabilities
- Information architecture and inter-stage experiences
These areas are core to the Secure experience, and they benefit from collaborative design work and exploration. But the benefits don’t end with our product UX—they help our team work better together, too:
- We gain an established common purpose.
- Our trust grows as we get to know each other better.
- We fail and succeed together.
- We have more opportunities to create new and unique solutions.
- We gain visibility into how another designer may have solved a similar problem in the past.
By sharing work, we’re also able to improve our onboarding experience for new product designers. When new teammates join, we work together to find a shared issue that will help them better understand the product and that they can contribute to without much domain knowledge.
For example, when Becka and Camellia recently joined the team, we purposely chose shared issues as excellent shadow opportunities. These serve as great introductions into the Stage and the security field and will help build their foundational knowledge in both.
These shared issues help everyone obtain a richer contextual understanding of the design problems we are solving for as a team. In the end, our product and experience will benefit as a result.
Split work
While shared work has its advantages, so does splitting our efforts to focus on specific domains and features. The benefits we've seen:
- We can work closely and consistently with engineers.
- We’re able to grow our domain knowledge about a particular area.
- We experience less of the friction caused by context switching.
- We’re better able to envision and create an end-to-end experiences for our users.
Split work doesn't mean solo work, necessarily. The GitLab UX team hosts weekly group design feedback sessions where designers share their work and the UX team offers feedback. Our UX Director often says, "I learn the most about our product in these sessions!" We definitely agree.
That’s why we also do our best to share work during cross-functional meetings and asynchronously on our Secure UX playlist on the GitLab unfiltered YouTube channel. For us, a divide-and-conquer approach doesn't mean that other teammates aren’t involved.
An excellent example of collaborating on split work is the UX Scorecard initiative in Q3 to collaborate on the new Security gates feature. This is a software composition feature (Kyle's split focus), though the MR aspect is closely related to vulnerabilities detected in the MR (Andy's split focus). In this case, Andy will conduct #534, and Kyle will do #533; then we'll work together on next steps and design improvement recommendations. Since each of the issues is tied to different personas, we see this is an opportunity for us to be an advocate for each unique user and focus strictly on their experience—all while working together on a cross-stage solution that benefits the feature.
Andy: “Having both a dedicated area of focus and shared areas of focus has given me an opportunity to dive deep into the specific niche areas of AppSec and uncover valuable insights about our users, their goals, and the technical challenges they face while still being able to see the bigger picture.”
Kyle: “Merging our efforts is a crucial aspect to our design process. This helps ensure our split work results in a cohesive experience for our users.”
Putting it all together
In the next few months, we have two new designers joining Secure and another for Protect. We’re thrilled to continue evolving our team and partnering with our new teammates on a path forward. Our mission and commitment are clear: To create a best in-class security and compliance experience for our customers.
Thanks for reading! Any thoughts to share? Do you have stories about scaling your UX team? Tell us in the comments below!
Interested in joining the team? We’re hiring!
