Camaraderie in a remote design team

A few weeks ago on our annual Wildbit retreat we had a group discussion on what works and what doesn’t in our internal process. A few developers mentioned the same problem — a lack of shoptalk with their peers when working remotely. They came up with different solutions, from participating in local meetups to weekly lunches with other developers, but it reminded me of a time when the same problem was very acute in our design team.

To provide a setting — I work from our office in Philadelphia on most days, Derek lives in Arizona (−3 hours), and Matt is in the UK (+5 hours). If distance alone wasn’t a big enough problem, a workday-long time difference between Matt and Derek makes it worse. Aside from that we also focus on different projects — Matt handles marketing design, while Derek and I work on different products. This environment is great for focused work, but it also eliminates any chance of small talk or casual feedback. We can’t share industry news over coffee, stop by each other’s office to show our latest work, or go for a walk to talk through current issues.

Setting up camp

A few years ago when our design team consisted of just Derek and I, we’d chat in private or jump on a call to stay in touch. That worked, but personal chats can get distracting and (as they are personal!) take a priority over what we’ve been doing at the moment. We didn’t really consider it a problem, but one day Chris added a Slack channel #designers and something magical happened — it became a place to share stuff or ask questions without requiring anyone’s immediate attention. Suddenly other team members who care about design started joining the channel and posting links, screenshots, thoughts, and rants. It became a small community campsite.

Regular check-ins

That worked really well for shoptalk and staying in touch, but didn’t affect our work process. Occasionally one of us would work on a major update but the rest of design team wouldn’t even know about it. By the time we saw an update it would be too late for feedback or changes, and the end result wouldn’t be as good as it could be. That’s when we decided to start a weekly call to share progress and discuss work.

The rules are simple: Show the team what you are working on. Explain your decisions and thought process. If there is a part you are struggling with or want more feedback on let the team know. Remember that feedback is on the design and not you personally. In the end it’s your call to accept feedback or to ignore it.

The call is scheduled every Wednesday at 11am — that’s before lunch for me, early morning for Derek, and end of the day for Matt. We tried different days but they didn’t work as well — Monday mornings are filled with product meetings, while Fridays are busy finishing up the week. Wednesdays are late enough in the week to get some work done but early enough to still have time to work through feedback. On some weeks we may be too early in the design process to talk about it, or focused on code, or working on bug fixes — then it’s totally acceptable to skip a call once in a while.

Are they worth the time?

Basic meeting math applies to all meetings: The time blocked off doesn’t equal actual time spent. The time spent is the time blocked off multiplied by the number of people in the meeting. So, a one hour meeting with 6 people is a six hour meeting. […] Factor in salaries and hourly rates, and meetings get expensive quick.

Jason Fried, “Status meetings are the scourge”

Our calls normally run for 45 minutes to 1.5 hours. That’s a big chunk of productive time to block in a day. The obvious question is if they are worth it, and I think they are for multiple reasons.

Feedback on design details that only designers care about. Talking about kerning or visual balance and alignment in a meeting with the whole product team isn’t productive and may result in rolled eyes. That’s part of our craft though, we love that stuff, and we’re ready to pick the tiniest details with a ruler and a color picker.

Fight tunnel vision with an outsider’s perspective. As mentioned we all focus on different products and areas, so most of the time we aren’t familiar with the story behind a presented solution. While working on something as part of a closely tied team, it’s easy to convince ourselves that the current solution is the only one possible. That’s where an outsider can look from a different perspective, ask an unexpected question, or provide insight.

Rubber duck debugging. Explaining a problem to someone else often leads to hitting upon the solution in the process. There is no practical need to gather people for that technique, but I am convinced that teammates work better than a rubber duck. Even if a “eureka!” moment didn’t happen, there is a good chance that someone already solved a similar problem or can suggest a direction to look into.

Sharing knowledge. As Wildbit runs three products and is actively working on a fourth, it’s important to share advancements and lessons learned. If someone came up with a great design solution, refactored or tried something new on the front-end, or improved a build process — we want to know about it and apply it to other products.

Practice explaining design decisions. Thinking through a problem and the choices you made is an incredibly important part of presenting work. We don’t have clients, but getting a buy-in from the team is just as important.

This had an interesting side effect on me. Have you ever been asked why you did something in a specific way and couldn’t find an answer? As we present our work to each other on a regular basis I started asking myself to justify a choice early-on while making it. If I don’t have a clear answer there is something wrong with the solution.

Regular face to face time. Spending time with your peers makes any team better. We often slide into talking about personal matters or industry news, which is so rare and missed in remote teams.

Of course, our weekly call isn’t the only time we interact with each other. In addition to a Slack channel, we have Basecamp with a weekly check-in on interesting stuff we stumbled upon and occasional posts about books or resources. We ask for code reviews on shared projects and talk about major changes to projects that we run solo. Sometimes we won’t wait for the next call and shoot an email asking for a feedback.

Final thoughts

Being the only designer in a team can be lonely, and in remote teams this feeling can arise even when you have peers. Making time to provide feedback, learn from each other, and have face to face conversations should be a conscious effort in any remote team. It definitely changed our process for the better over the last few years.

I am eager to learn how it’s solved in other remote design teams. Please share your experience in comments or reach out to me on Twitter.