This blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-04-02.
In 2019, GitLab’s all-remote UX team grew from fewer than 15 team members to almost 60.
Hiring at that velocity meant we interviewed a lot of great product designers, UX researchers, and technical writers. One of the most common questions I personally heard in interviews was, “UX is such a collaborative activity. How do you work effectively when everyone is remote?”
It’s a fair question. As UX practitioners, we’re often used to getting in a room with our product team to brainstorm ideas and work through problems. So, how do you keep everyone engaged and informed without that face-to-face time?
Honestly, there is no perfect answer, and we’re still figuring it out every day. We tend to try new ideas as pilot programs and then adopt them more broadly when they prove to be successful. And just like we iterate on our product, we also iterate on our processes, making them better over time.
In that spirit, here are a few things we’ve tried that have helped to encourage collaboration and connection both within our UX department and with our cross-functional peers.
Pair designers
When I joined as GitLab’s UX director, I spent my first few weeks just talking with the team to understand what was working well and where they needed more support.
A recurring theme was that product designers felt they lacked design peers to partner with. They were getting good feedback from their product managers and engineering partners, but it was different than the support they knew they’d get from another designer.
Because we’re all remote, the product designers were hesitant to just randomly reach out to another designer, because they didn’t know if they’d interrupt that person’s workflow. They couldn’t just look across the aisle to see if someone was busy. And without a consistent partner, they’d need to give a lot of additional context about the problem they were solving.
We addressed this by piloting a Pair Designer program where every product designer is assigned a design peer in their same time zone who works on a different part of the product. For six months, this is their go-to person for ideation sessions and quick, on-the-spot design feedback. After six months, we swap pairs to give people more exposure to different ideas, working styles, and product areas.
Pair designers are encouraged to work together however they’re comfortable. Some agree to meet for a weekly sync over video, others meet every two weeks, some contact each other ad hoc, and some meet primarily asynchronously.
We received very positive feedback on the pilot, so we’ve continued this program, and we’re now on our third rotation. It’s been a great way for designers from all over the world to learn from each other. Here’s a quote from one of our designers:
“I have loved working with each of my 'pairs'’ in UX! Usually we meet once a week for 30 minutes to an hour and spend about half the time each talking about something that is top of mind for us. Sometimes it is just discussing some process or higher level stuff; most of the time we are sharing our screens in Zoom and walking through Sketch, Figma, Axure, someone's branch, etc. to talk through design challenges we are having. The most exciting part of this to me is getting to really dive into a space that I don't get as much exposure to -- also getting to know another designer and having that dedicated time just for us.” Alexis Ginsberg, senior product designer at GitLab
Synchronous kick-off sessions
At GitLab, we try to work as asynchronously as possible. This is important for a few reasons.
Most importantly, we’re all remote and globally distributed in 67 countries, so face-to-face meetings aren’t always feasible across varied time zones. Also, we find that asynchronous communication is often faster than meetings. Lastly, by defaulting to asynchronous communication, we always have documentation of the decisions we’ve made and why we made them. Those are some great reasons to default to written communication.
That said, when a design project first begins, we’ve found that it can be helpful to get everyone together to ask questions, discuss the problem, ideate on possible solutions, and discuss constraints. Depending on the project’s complexity, this can happen very quickly (30 minutes), though bigger problems may take longer.
When we have synchronous kick off sessions, we record them and post them to GitLab Unfiltered, so that anyone who can’t attend still has access to the information. We also document the outcome in a GitLab issue, so that information doesn’t get lost. Lastly, we quickly move from synchronous to asynchronous activities for the reasons noted above.
Video walkthroughs
At GitLab, we believe that design is collaborative. That's why we try to involve our team members as early as possible and throughout the entire process. One way to keep our team up to date without having to set up a meeting is to record short videos where we walk them through our designs, preferably in the form of a prototype.
“If a picture is worth 1000 words, a prototype is worth 1000 meetings.” Tom & David Kelley
In these videos, we lay out the rationale behind our designs and also offer information about other options we thought about and decided against. In certain situations, it also makes sense to add additional background about our long-term vision.
One of the many positive outcomes from this approach is that even team members who have only been minimally involved are now empowered to provide feedback, add their own ideas, or provide us with additional information about the amount of work our ideas will require.
UX Showcase
When a company is widely distributed, it can be hard to keep up with all of the amazing work that’s happening. Staying updated on changes is especially important in a company like GitLab, where we all work on the same product. We need to understand what other designers are doing and how they are doing it, so we can create seamless workflows that maintain consistency throughout the UI.
In our biweekly UX Showcase, four product designers each take 15 minutes to share recent work. We have no restrictions on what they share or how they share it. It can be work in progress or something that recently moved to production. Similarly, the "presentation" can be as simple as walking through a GitLab issue or a more elaborate Google Slides deck. The point isn’t to be fancy – it’s just to share information in an easy-to-understand and compelling way.
Personally, I learn so much from seeing designers talk through the problem they were trying to solve, why it was important, how they solved it, the challenges they encountered along the way, and why the final solution ended up the way it did.
I’m so proud of the work that I see our team doing. It’s as motivating as it is educational.
But the value of the UX Showcase isn’t just to the UX team. We record the showcases and post them in a YouTube playlist on GitLab Unfiltered, so that anyone in the company (or the world) can watch, if they’re interested. We also make sure to post links to the videos in a variety of Slack channels, so that our cross-functional peers can watch at their convenience.
Asynchronous sketching exercises
Most people think about sketching sessions as synchronous and co-located. But at GitLab, we have team members who live in time zones across the world, and we’ve had success at inviting team members to sketch, think, and brainstorm asynchronously.
This does require a team to already have a good level of trust and a shared understanding of the problem space, but it can be a really efficient way to bring out the team’s creativity, regardless of where in the world they work.
If you’re interested and would like to see an example, you can learn more in this detailed blog post.
Slack channel for UX coworking
Sometimes designers just want a quick, ad hoc collaboration session, and their Pair Designer may not be immediately available. For times like these, we have a Slack channel dedicated to UX coworking.
In this channel, designers can ask whether anyone is available for a quick ideation or feedback session. They can also post work in progress to get quick feedback. This has been a great way to promote on-the-spot collaboration within the team.
Design documentation
The most important thing to remember when designing remotely is: document, document, document!
At GitLab, we document our design decisions and rationale in GitLab issues. We even launched a new feature category recently called Design Management that lets designers upload images and invite comments in the same platform that product managers and developers use to do their daily work. We’re adding new features in this category that will make this more and more effective over time.
When it comes to UX process, we document everything in our handbook. That means when someone wants to understand how we research, design, and write about our product, the information is always available and up to date. Everyone at GitLab has a shared responsibility to keep this content clear, current, and easy to use.
All-remote design works!
For teams that are used to collaborating in person, it can seem like a big leap to go all remote. As someone who has practiced UX in a variety of models – 100% in person, a hybrid of remote and in person, and all remote – what I can say is: It works!
In my experience, the least effective model is hybrid. Nothing is worse than being one of the few people on video while the rest of the team works in a room together. Your voice just doesn’t get heard.
We know that we can’t design a great product without close collaboration from our cross-functional peers. When you’re all remote, you have to make a conscious effort to involve peers in your design process early and often. While that takes an extra level of thoughtfulness in an all-remote team, the improved outcomes are worth it.
Cover image by Christina @ wocintechchat.com on Unsplash
