Design in remote and distributed teams
If you have remote team members - whether they're designers or not - or if you run distributed offices, then realistically you're touching some of the core problems associated with asynchronous or remote working. In truth, even if your designers are located in one geographical location - and even if they all sit at one bank of desks - if any part of your organisation exists in a different timezone or location, design will begin to encounter communication issues sooner or later.
In most orgs, design is one of the core elements that binds development, marketing, brand and business stakeholder - effectively its role is to be the central communication channel. It defends the user, it actions and commissions research, it discovers trend, it crafts solutions - and all of this effects the entirety of the organisation, including the bottom line. Even if your org hasn't necessarily realised this core power of design to effect change, creating your design org to - at the very least - communicate well, with minimal friction is key to any product or brands success.
I've seen many orgs struggle with remote or distributed design work, however the good news is over the past 5 years an entire industry has spun up to create tools to support some of these problems. In reality though, reliance on tooling is doomed to fail without a large culture shift towards remote and distributed workflows. However design orgs are well placed to drive that shift - it's a service design problem after all, and designers are perfectly equipped to solving these knotty human problems and crafting elegant solutions.
If you've identified remote or distributed problems raising their head in your org, here's some hard-won opinion on some next steps, pitfalls and quick wins.
Sweat your workflow
Do the level of discovery and critique you'd do on a new product launch - on your current and future workflows. Design has one of the most complicated workflows in any organisation, primarily as the work produced is often incredibly varied and often subjective. Do you currently work face to face and have quick discussions offline? Great - but you need to work out how that scales in a remote environment. Sure you can FaceTime someone and have that conversation, but in a remote environment that conversation, those decisions - those actions - are outside of the team and the rest of that team loose precious context on your decision making. Because of this, workflows for design need to be transparent, basic and heavily contextual. This initially seems like a large upfront investment of time - documenting all conversations and workshops, running regular all-hands meetings and recording them, coordinating time-zones for group chats - and it is.
But the benefits you gain from this investment are ten fold. It's easier to track changes and decisions, it's easier to onboard new staff and contractors, it's easier for staff to take holiday, it's easier to align stakeholders - because it's all there for everyone to see. Transparency is your friend, and creating systems and workflows that encourage transparency and open discussion are critical to success. In my experience I've found a few key areas that determine failure or success. Firstly you need a solid environment to create centralised documentation. This is playbooks, 'why we did what we did' and outcomes. This environment needs to be easy to use and low friction otherwise it'll never gain traction in the team if documentation is seen as a chore. You'll also need to set expectations on the standard of documentation, responsibilities for updating it, and who sees what and when. Secondly you need a clear approach to workflow. I've placed Kanban into Product and Marketing teams with some success - just remember it has to have maximum clarity and minimum friction - and you'll need to, again, set expectations. Creating workflows like Kanban relies on each designer taking on some project management responsibility to maintain clarity. Thirdly, communication cadences. When do you run a crit? How do you run it? What are the timezones in play? What are the skillsets of the attendees? How do you keep your team in sync - especially if they're cross-discipline? Fourthly, you'll need to focus on the design process itself and the resulting taxonomies. How do you create a brief? If no-one is there to crowd round your screen to make quick iterations - how do you do this? When you've created something incredible - how does it get signed-off? How do you collate stakeholder feedback? When it's signed-off, where does it live and how can others find it?
For me I've found solving these problems as a team and getting buy-in on a team level the best approach. I've also found that (with one critical eye on tool-creep) that giving designers a choice over the tools they personally use to solve these problems to be beneficial in allowing a constant peer review of new and emerging solutions.
Treat this like a range of design problems. Get your team to work on them as a whole, and be sure to bring in all the skillsets relevant to that discussion. Have a video editing team? Copywriters? If they touch your org creatively, involve them at the kick-off discussion. Retrofitting other workflows is both painful and usually causes a lot of resentment.
Consider your whole design org
And by that I mean - not just the Product Design team. It's easy to see Product Design, with its proximity to development and agile practise, as the perfect starting point for building a remote playbook. But think about Marketing and Graphics, and their unique requirements. Sure they do a lot of print, video or social - but a successful design org is one that is sync, creatively, cross-discipline, and you should consider the same remote needs that a Product Designer would have applying to a graphic designer crafting MPU Advertising. In my experience it's 'all or nothing' - but there are huge benefits. If your Product Designer is building a product onboarding feature, and they can see the Marketing output and message for the product in real time (and vice versa) I defy anyone to say that this level of dual asynchronous context is a bad thing. At their core, Product and Marketing design are 90% about communication of story - so if those two teams aren't on the same page...what chance does the end user or customer have in understanding the story you're telling?
Communication, Communication, Communication
You're not going to be sitting next to each other - and if you are, others who won't be sitting next to you need to be looped in. Begin by treating any offline conversation as taboo - ask yourself if any element of that conversation is critical for group understanding. The worst phrase you can hear uttered in remote teams is 'I wasn't aware of that'. People being unaware of critical information (even if you don't consider it critical) is incredibly dis-empowering and quickly causes silos which inevitably devolve into cliques. Your role is always to prevent that from happening. To solve for this, choosing your communication cadence is critical - and that cadence can be split into online and offline comms.
This is primarily video calls. Zoom and GoToMeeting all have good cheap tools for teams and using it effectively means making clear diary touchpoints in your regular weekly workflows, and remembering to record and archive meetings for those who cannot attend. I've found having a general all-hands design meeting mid-week to be a good 'go round the room' opportunity to catch up and listen, and another weekly critique-specific session to be pretty much optimum. Any more than that and you begin to get meeting fatigue and attendance will drop - your designers will be having numerous other meetings themselves inside their teams, so optimising the time you have as a group is critical. Slack is also your friend, however others have found tools such as Basecamp to be better for their workflows. Either way a continuous IM channel is critical.
This is likely to be split into documents, workflow and assets. For documentation I've had success with Notion as a powerful centralised asynchronous document environment, however Dropbox offers it's own version which some will prefer. For workflow, Asana has a low impact Kanban and list option for managing jobs to be done. Product Designers may prefer Jira to sync better with their development teams - the best tool here is usually the best tool for the job, and that can mean multiple tools (I run Asana and Jira) but the key is to give everybody access to everything -even if they rarely use it in their day-to-day. I've used Trello, Meistertask - there really is no shortage of options - however the workflow you apply to those tools is much more important use of your time. For assets there's Dropbox, Box, GoogleDrive...the list goes on. Personally I prefer GoogleDrive as it offers email, documentation and presentation options, but with asset management the tool selection is really about cost - the taxonomy is critical to how useful it is.
Criticism and Feedback
In remote communications environments, the process of criticism and feedback quickly becomes core to team success. Your weekly crit sessions become very important, and it's necessary to make sure those meetings are coordinated well to create maximum value for everyone involved. There are a few tools to help with crit and feedback, but I've found in running remote crit that it's important to schedule the work being critiqued in advance so everyone turns up knowing what their involvement is - and they have time to research the context from documentation before they log in. I've also found that the designers who leverage the best critique are the ones who communicate up front what they want critique on, rather than awaiting a generic Q&A from their peers.
For critique and feedback there are, again, offline and online elements. For Online I've found Figma to be a great centralised design tool to coordinate different design disciplines (from Product to Marketing to Brand) under openly shareable transparent URLs. Invision Studio is also good for this use, and both tools offer prototyping, presentation and support screen sharing. For offline, these tools also offer commenting and collaboration at the core of their product. I've found commenting and multi-user collaboration to be incredibly useful, and is something of a game changer in distributed teams. How you use commenting and collaboration in these tools however can be a contentious discussion - it's entirely possible for 5 designers to pile onto one artboard and begin altering someones work, and the danger of 'design by committee' naturally increases with such powerful features. Your team needs to work out together where the red lines are in collaboration, and have awareness of how each other work, and prefer to receive feedback.
You're not physically there, so you need to empower your team with ownership over their work and their ways of working. As you move towards distributed teams, and the 'hovering Art Director' in you has to take a back seat, trusting that 'things will get done to standard' becomes a key component in how you work together. Working with your team to discuss and define ownership - and then getting them to 'own' that ownership - is a crucial to them being able to perform remotely and build a sense trust - both with you, and with other designers.
Coaching and Leadership
Remote teams need more coaching - or they seem like they need more. This is really due to you having to schedule it rather than it happening in typical daily conversation. The benefit of that though is it causes focus, and means the coaching can have more impact. Leadership also needs scheduling, but in reality remote or distributed teams need a slightly more passive lightweight form of leadership - you're not organising group lunches and meet-ups and seminars, now your role is to make sure everyone is in the loop, concerns are addressed, communications are clear and transparent, and agreed documentation and communication cadences are being adhered to. Does it feel less social and ore janitorial? Yes. Yes it does. But it doesn't mean that it can't be rewarding. I've found distributed and remote teams need more individual attention - coaching individual designers to find their leadership qualities and embrace them. Turning your entire design org into a team of design leaders is a very satisfying proposition - more so than expensing a group lunch or dragging everyone into the office via a two hour commute to attend a meeting.
You have to be face to face sometimes. Remote is great and everything, but there's always going to be a need to spend time with those in your org; whether that's to connect on a personal level, gain skill transference, kick-off a complex project, or just to bond as a group. Depending on your budget, those face to face opportunities might be decided for you. But I've found some key times when turning up matters most.
Any new staff member will have an impact on the teams dynamic, but it's not realistic to get the whole team together every time you hire someone (especially if your company is scaling quickly). Involving your team in the hiring process is always good practise regardless of work culture, but turning up to meet them on their first week is hugely important. It shows you care, sure, but it removes fear in any new starter. Starting in a new culture is nerve-racking, so you should do your best to mitigate that worry and be there to ease them in.
If you are a leader you have to pick a cadence of turning up that is optimal for your team. I've found something akin to quarterly useful, especially if your business runs a quarterly OKR process to define the business or team level goals. Get on a plane. Bring people together who need to be together.
Bring teams together that need to be together. That's obvious. If you have a remote team that all work together on one product line, find a time for that group to meet in person maybe twice a year organised around what makes sense to their work. Let that team decide that cadence, and do all you can to support their choices. However as a leader, consider who from other teams should also be there - if you're building a commercial product, is there a benefit in bringing Marketing Design and Product Design together? If Video is a large part of your onboarding, shouldn't they be essential to any face to face meet up?
Sometimes you have to bring everyone together to meet up and get to know each other. You've likely been working hard to prevent team silos, but even in the best case scenario, it's likely you'll have designers and creatives - or key stakeholders and colleagues - that have never met in person. Most companies choose to do this on an annual cadence over a one week retreat, which is great. Do it. But does your broader design team need that opportunity as well? Large retreats can be overwhelming and with so many faces, people can find it tough to connect on the things that matter. Consider the need for a smaller retreat to balance it out.
A note on Diversity
One of the wonderful effects of remote and distributed teams is that the culture enables - and promotes - increased diversity. The fact that the highest paying jobs and opportunities are in big cities, and the cost of education, combined with living costs vs renumeration (especially when you’re beginning your career) means that working the best jobs at the best companies in the biggest cities favours those who come from affluent backgrounds, who most likely are white, who most likely are male and who most likely have no complexity in their background. This means that there is a huge talent base internationally that cannot access the opportunities that they might be perfectly aligned to given the chance. If you have a family you care for, elderly parents, children, a non-affluent family history, or are a minority for whom opportunity is less accessible - which let's face it is a lot of people - you can't just up and leave to New York, London or San Francisco to throw down $3K on an apartment rental. And why should that sacrifice - or attainment - be the defining factor in your career success? Is it because the role you are qualified for, for whatever reason, requires you to be present in an expensive city, despite the fact that - if we are all really honest - could be done anywhere? Is it because the people who run that company could afford to be in an expensive city and therefore presume others can?
The greatest benefit of remote and distributed teams if you can tear up the existing rulebook and look to building a different kind of org based on talent, skillsets and experience regardless of location, background or privilege. In design, diversity is its lifeblood. Finding and solving user problems, communicating to broad ranges of people, communities and cultures - this is what design does. But without diversity in that design team, it's just appropriation. The most exciting thing about the move towards remote and distributed teams is the freedom it gives in team building and the access it gives to a broader spectrum of great talent - wherever and whoever they may be.
A note on tools
As I've mentioned, tools are largely useless without workflows - so remember that choosing a tool is something you should try to do after analysing your teams preferred ways of working, and as a group you've identified the problems any given tool would actually solve. Here are some key tools I've used to coordinate and enable remote and distributed teams, which might be useful in your org. All offer collaboration and versioning features, which support asynchronous workflows (hence Sketch isn't here - sorry Sketch).