Source: GitLab Blog | Author: Alexis Ginsberg and Holly Reynolds and Becka Lippert and Matej Latin
많은 디자이너들이 지난 몇 달 안에 그 외딴 삶에 새로움을 느낄지도 모릅니다. 이 게시물은 디자이너들이 Gitlab에서 어떻게 협업하는지에 대한 겉모습만 긁어주고, 어떤 아이디어들은 COVID 이후의 세계에서는 조금 다르게 작용할지 모르지만, 여러분의 일상적인 작업에 대한 영감을 찾을 수 있기를 바랍니다.
Working as a designer at GitLab means being a Remote Designer with a capital R. GitLab has no “main” office. We have teammates working from their home office or coworking spaces all around the globe. Some of us don’t even have one home base, preferring to travel the world while working.
As designers at GitLab, we may not be able to physically get together near the Nespresso machine to chat about our days, or grab a conference room for a quick whiteboard session around the latest design challenge we are solving, but we still find ways to stay in sync. Are you thinking about NSYNC now? Good.
Finding creative ways to collaborate synchronously with all teammates across GitLab is a worthy challenge to be solved, and we are always experimenting and iterating on the best ways to do this! We have found that synchronous collaboration has to be a bit more intentional, but if time and space is made for it, it can be just as––if not more––fun and productive! Here are some ways the GitLab design team has worked to create that space for synchronous collaboration…
👯 Pair designers
Every six months or so, each individual designer is paired with another GitLab designer who is intentionally dedicated to a different stage group. We are given the freedom to coordinate how we choose and can collaborate as much or as little as we feel comfortable with. The trend seems to be 30 minutes to an hour either each week or every other week.
Alexis: I personally look forward to my weekly Zoom meeting with my pair, and we usually aim for an hour but sometimes go over time since we love chatting with each other. We have an agenda of items both of us hope to cover, but also make sure we have time to catch up as people and coworkers, which is especially important to me as a remote designer (sometimes you just want to show off your dog or talk about the latest Netflix show you are binging!).
The agenda items are usually split evenly between us so that we can dedicate half of the time to a design, research, or process challenge we are working through, and the other half giving feedback. We are encouraged to work in the tools we feel most productive in so sometimes we will be walking through a design in Sketch, Figma, Axure, Mural, or even a quick sketch on paper or iPad.
As our team grows larger, getting this time to really dive into the design challenges of another stage group is very important. It helps me focus on the holistic journey users have within GitLab, rather than just “my” specific corner of the product. Every designer at GitLab shines in their own way, and this is just another way for us to learn from each other!
☕ Coffee chats, 1-1s with other designers, and stage specific syncs
We’ve already touched on the importance of remembering that although we are remote designers, we have the support of an entire team around the world. In no other place is this more apparent at GitLab than in coffee chats, one-on-one syncs, and syncs with stage specific teams.
Alexis: We can opt in to random coffee chats with anyone at GitLab, but as a designer magic happens often when just chatting through challenges with other designers. Working remotely means more time to focus, and the formal process of asking to schedule time with others can sometimes feel like you are asking permission to steal focus time away from their day. If all designers agree to set aside time each week that is dedicated to chatting with each other, it helps take that guilty feeling out of the equation and feels more like an informal time to chat and explore designs (that “turn around in your chair to chat with the coworker next to you” feeling), rather than another faceless Google Calendar invite.
We do this in a few ways, either through recurring 1-1s with other designers (including the pair system), recurring small group syncs with other designers in our stage group, and somewhat larger recurring syncs with designers in our section. They are all useful and full of collaboration to varying degrees.
The smaller and more specific the syncs get, the more day-to-day-design and feedback-specific the collaboration gets, which is great, because designers in one product area need to be able to support each other frequently on related work.
Larger syncs are perfect for getting a broader understanding of what other designers outside of your stage are up to and for aligning on broader GitLab Design priorities affecting our section.
Becka: The larger syncs also help discover overlap that you may not know exists, such as similar challenges or new use cases for a component in the design system.
Matej: Based on my experience so far, having a recurring 1-1 call with other designers from my stage group can be even better than the option to do it spontaneously in an office environment. And that’s mostly because of how we do it.
These calls are always at the same time on the same day of the week. We have a Google Doc for the agenda, so we can prepare in advance. Often, when I work on something, I remember that my fellow designer from my group probably knows more about the topic, so I just open that agenda doc and add an item to it so that we talk about it the next time we meet. This way, I don’t interrupt them with Slack messages or ad-hoc calls.
All this combined, it leads to scheduled, time-boxed calls where participants are prepared in advance and everyone gets so much value out of it. We borrow ideas, prototypes, pieces of UI. We can go into details of why our teams are working on the things that they’re working on. If we relied solely on group status update calls we wouldn’t be able to do that.
It’s also a great way to socialize and build relationships with other designers, as we often talk about stuff that isn’t work related. We’ve only been doing this for two months in the Growth group, but I’ve already saved hours of wasted time working on things others already did. I also got to know the designers much better, which makes collaboration easier, more likely, and also more enjoyable.
When it comes down to it, we are all GitLab Designers and need to not only understand and empathize for each other’s work, but also for each other as people who like each other and are working toward the same goals!
🎬 UX Showcase and UX Weekly
Our largest opportunities for synchronous collaboration are our UX Weekly meeting and the UX Showcase. These syncs aim to capture as many designers across time zones as possible, which is a great chance to interact with faces you may not see on your screen often.
Alexis: Our team has grown substantially over the last year, so having a weekly time to catch up with each other at a department level has also grown more important. The UX Weekly is a time for any and all GitLab designers to discuss any updates they have made to Pajamas (our design system), process changes, OKRs, exciting ideas, or workshops designers are tinkering on that they think may benefit others – basically any team updates in general.
Growth of our department (and GitLab as a whole) has also inspired us to find new ways to stay transparent and visible about the work we are doing. This promotes cross-team collaboration both inside and outside of design.
Every two weeks product designers are encouraged to dive deeply into problems they are solving at the UX Showcase, making sure to touch on things like business goals, customer goals, and constraints. Four stage groups present per session for fifteen minutes at a time, giving us an hour to highlight work we are excited about sharing broadly on GitLab Unfiltered for anyone to watch! What we present and the format in which we share is not prescribed, so designers can get creative about how to use that fifteen minutes allotted to their stage group (or at least as creative as sharing a screen on Zoom will allow!).
The part of the UX Showcase I enjoy the most is understanding the journeys my fellow designers go through and what processes they find most beneficial when creating solutions alongside their teammates in Product and Engineering. I also love the Slacks I get from other GitLabbers after presenting, asking to learn more about the work I am doing because they have feedback or to collaborate on something they are working on that is similar. The most exciting pings I get are from coworkers I am unfamiliar with, because that means we are empowering everyone to learn about and contribute feedback to our user experience!
🤝 Collaboration with Product Managers
A strong relationship with our partners in Product Management is important for any designer, and this is no different even for those of us who don’t have to walk into an office every day.
Alexis: One of my favorite weekly meetings is when my team’s product designers and product managers all get together in the middle of the week for a 45-minute sync on Zoom. The first item on our agenda is for each of us to go over our goal of the week. These goals can be very personal or something we are hoping to accomplish professionally that week. I personally really enjoy learning more about what my teammates hopes and dreams are, even if those hopes are just to finish the repairs on their guest bathroom (this seems to be a big priority on our team for some reason!).
We spend the rest of the time going over our agenda items, such as in-flight research, issues that need collaboration, questions that we need clarification on, and then the good ole’ board walking time (going through our Kanban board of open issues in the current milestone) where we see how prioritized work is going. Usually we don’t get to the last agenda item, because we are busy walking through a design together or collaborating on some research items in Mural. This is fine though, because we have other times set aside to talk about priorities, and this is something that is easy to do asynchronously as well.
A recurring theme I hear from product managers is that working with designers is one of their favorite parts of their jobs, and that they would never want to lose that just because we aren’t co-located. Luckily for all of us, most designers at GitLab are now aligned to one group with one dedicated product manager, so we can really focus on making that working relationship great!
My product manager and I take an hour out of our busy schedules each week to hop on Zoom and sync up. We use our agenda (are you sensing a theme here?) as our guide to walk through priority design issues that require collaboration or scope clarification. I prefer to drop sketches and mocks into a Mural board that we share, so that I can share my screen and allow him to follow along and make comments as I walk through ideas. Sometimes he will even share sketches with me, which I will then add and build on. This time helps us collaborate and get to know each other outside of regular conversations in Slack and issues.
💻 Collaboration with Engineering
Another very important relationship for product designers to nurture is with our friends in Engineering. Designers and engineers at GitLab usually work together asynchronously, often in issues or merge requests. Many of the usual touchpoints between these teams – like stand up, retros, brainstorms, and reviews – are effortlessly asynchronous. Instead of distancing us as designers from the engineers we team up with, this just allows us to make the time we do set aside for synchronous work more focused and intentional. Sometimes we may even sneak in a board game or two.
Alexis: My team has weekly syncs between designers and Engineering Managers to discuss ideas for experience improvements and gather feedback or known constraints around designs. Product managers will also join and help facilitate any pivots or tradeoffs we may need to make while walking through our planned priority work. We also have a larger meeting to discuss big picture updates or retro type items, like processes we think could improve our workflow.
These (at least) weekly syncs are important in keeping our teams running smoothly, but my favorite engineering syncs are the impromptu one-on-one review and pair sessions I have with teammates. If asynchronous reviews or ideation seem to be going back and forth for a long time, nothing is better for unblocking a teammate than a quick synchronous Zoom call. Usually, what starts with one of us being confused by something the other is working on ends up in us chatting on a call and learning from each other as we share our screens and work through tough challenges together. The best part of these is that if our time zones are very different, we get to say, “Go have some coffee and have a great morning!” and “Get out of the office and have a good night!” at the end of the same meeting.
🔬 Collaborating with users and the UX Research team
Having a solid understanding of users and being able to empathize with their frustrations and desires is so important to us. In fact, we even have a team dedicated just to UX Research! As with most organizations, though, GitLab Product Designers also need to have a passion for research and will often wear that “research hat” themselves.
Alexis: Conducting research as a remote designer has surprisingly not differed as much as I expected from my time as a designer working in an office. Usually we start everything with a synchronous kickoff chat between the person requesting research, the researcher, and anyone else interested in the research project to capture objectives. This is also documented more formally in an issue, so we can iterate together asynchronously and have a single source of truth to refer back to. The planning and scripting can either be done in GitLab itself, or in a Google Document where we collaborate asynchronously.
Prototyping or setting up testing environments is done in GitLab or any tool we feel comfortable will be most effective for the user. We schedule time with participants and conduct the interviews themselves through Zoom, which is something many would be familiar with. Those who join the call take notes and chime in as needed. If anything, this may feel less intimidating to participants, as we are all just friendly faces in a small Zoom box, rather than people staring at them in person. Many times, users will remark on something going on in our home office, and that acts as an icebreaker and takes pressure off of the situation (I always get comments on my yellow chair and terrible wall art for example).
The synthesis aspect of research is where things get interesting, although I would imagine organizations that aren’t remote are also catching on to some of the remote techniques I am about to describe. We take the insights captured in Google Docs and GitLab issues and map them out in Mural. These synchronous sessions in Mural help us feel like we are all together at a whiteboard doing some good old fashioned affinity mapping – even more so if we are all doing this on a Zoom call and chatting as we work. Add a few stakeholders to the call, and it is a remote research synthesis party!
⚖️ Why synchronous vs asynchronous?
This post highlights and focuses on some of the ways the GitLab team collaborates synchronously across time zones and teams, but the flipside of this is asynchronous collaboration, which is how we Get Things Done™️ a majority of the time. It is even one of our values. There are of course pros and cons to each way of collaborating!
Holly: One of the challenges of being a remote organization is that we all simply can’t be available at the same time. In addition to collaboration, inclusion is also one of our values. Asynchronous communication allows us to ensure that everyone has a chance to have a say, regardless of their schedule or timezone.
However, we recognize that asynchronous communication is not without its challenges. Because async conversations happen in a page or document rather than a real-time setting, they can slip off the radar of participants. This can result in a stall in productivity. We have to be intentional about managing conversations we want and need to be a part of. This may include using To-Dos, tagging others when we need feedback, applying group labels, and assigning items to ourselves, so that we are notified when a change occurs.
Asynchronous communication also gives everyone a chance to pause, reflect and respond to ideas proactively, rather than reactively. This is great, particularly for introverts such as myself, but can at times lead to overthinking in discussions. We strongly believe that everyone can contribute and should feel empowered to do so, but we also recognize the need to move the work forward. Some of the ways we manage this are through asking questions and seeking to understand one another’s views, but also setting timelines (as needed) and goals for what we want to accomplish within a certain time frame.
Finally, asynchronous communication allows the history of our collaboration to be preserved. We’ve grown exponentially this past year in a very short period of time. With so many new faces and great ideas coming in, it’s more important than ever for us to be able to refer to the historical conversations surrounding why certain decisions have been made. This enables us to move forward with insights starting from the original idea all the way through to production.
With all of these great benefits, though, sometimes problems can be particularly complex and need a quick answer or require real-time visual collaboration. We have a rule that if a conversation goes back and forth asynchronously more than 3 times, we move to a synchronous conversation, usually in Zoom or Slack. We record as many of our meetings and video chats as possible, so that others can still have an opportunity to catch up and provide feedback. And we recognize that as human beings, we are social creatures. Sometimes we simply need to hear someone’s voice, see their body language to fully understand a situation, or to just have a human connection. In these cases, we embrace the benefits of synchronous communication.
For more details on how we collaborate remotely in general, feel free to add this blog to your reading list!
💡 Tips and things to keep in mind when meeting
You may have a friend of a friend who has a horror story about video calls with coworkers. Mishaps can happen to the best of us (especially those of us with cats), and we understand that at GitLab. Here are a few of the things we keep in mind to make synchronous collaboration as seamless an experience as possible:
Becka: Keep an agenda! One of the coolest things about GitLab meetings is that there’s always an agenda attached, so you can see what will be covered. Anyone on the call is empowered and encouraged to add items to the agenda, whether it’s to draw attention to an issue, invite feedback, or discuss something process oriented as a group. We can always add “Read-only” items at the top if there are a lot of agenda items, if the discussion can take place asynchronously, or if it’s more of an FYI (“Thank you so much to Alexis for starting this awesome blog post [linked to doc] about remote work!”).
Having a meeting agenda completed in advance (and often elaborated upon during the meeting), lets attendees come prepared and gives everyone a chance to be heard. If you decide that the other agenda items are higher priority, you can always add yours to the bottom of the list and feel good knowing that if time runs up, it will automatically be moved up as higher priority in the following meeting.
Finally, agenda items are a great place to revisit to-dos from weeks prior, to find links to issues that were discussed, and a great single source of truth for meeting notes that all can contribute to.
Becka: Mute your mic when you aren’t speaking to avoid frustration and perhaps embarrassment. 👀
Holly: Remote work can blur the lines between personal and professional, but we are all human and things just happen sometimes! If anything, this can create bonding moments.
Alexis: Many of our collaboration values are around being kind to each other. This can translate to video calls and collaborative workspaces, too! Build any sessions with easy collaboration in mind. Give each other space to respond, and listen to each other. Pause often to allow other people to chime in with thoughts or ideas without interruption. Read the room as you typically would in person. One thing that really helps with this is turning your camera on during meetings, so that others can see your face and read your body language. I know sometimes it is tempting to join with your camera off, but trust me – it helps!
Another way you can be kind to others is by scheduling meetings with a 5-minute buffer at the end. So, for example, instead of blocking 30 minutes of time with someone, schedule them for 25 minutes. There is nothing worse having back-to-back meetings without time for making coffee, taking a bio break, or just walking around and stretching (hopefully toward some place that has a snack you can bring with you to the next meeting).
Matej: If you need to collaborate often with the same teammates, schedule your syncs as recurring in a consistent cadence and have an agenda. This allows participants to be intentional in advance about what they’d like to cover during that set time, so they can understand expectations and be prepared – which enables everyone to collaborate on more items!
Alexis and Holly: Lean into the fact that most coworkers may only be seeing your upper half and anything behind you, and fill that space with your personality (we like to wear outrageously silly sweaters or put our favorite art behind us)! Dogs or family walking behind you or interacting with the camera to say hi to colleagues is not only accepted at GitLab but encouraged. Working outside of an office means that coworkers can get to know you outside of the office “version” of you, if that is something you feel comfortable with.
🦊 How do you do remote?
Feel free to ping us on Twitter at @gitlab with any remote synchronous collaboration tips and tricks in your toolbox that you think our team could learn from. See you in GitLab!