As designers, we are often very comfortable in working together using the physical space to our own advantage — critiques, workshops, brainstorming sessions, etc. It’s usually part of our education, and it evolves with our practice and experience. Facilitating an in-person workshop is second nature to many of us. Which is why one of the most common questions about working without being in the same room is: how do you design remotely?

There are tools for this, yes, but it’s not about Sketch, XD, or Figma. It’s about the overall remote design workflow. What does it look like?

Sustained feedback

The shift from in-person to remote isn’t really about processes, or how design is being done. Many existing processes can be used and adapted effectively. A useful principle for me to follow is sustained feedback.

Sustained feedback breaks large chunks of feedback into smaller bits, given over time: feedback happens in parallel to the work, and is done in such a way that any change or modification is incrementally shared with the people that need to be involved. In practice it means that feedback, both negative and positive, is given frequently (i.e., even multiple times a day) and is as timely as possible, instead of waiting for specific feedback moments and letting things pile up (i.e., a week later, a month later, at the end of a project or a quarter), which can make positive feedback feel insincere. It keeps changes from building up and becoming a larger piece of work that is harder to discuss and evaluate — and give feedback to.

You might notice that this principle isn’t strictly related to remote work; remote work isn’t inherently different from in-person work. But it does highlight some aspects of work that come naturally to in-person work by the simple fact that people are in the same space.

Sustained feedback is one of these traits: in an office, it’s easy to walk by a colleague, get in a meeting room for a chat, do a workshop. Some studios have dedicated rooms for the entire length of a project, a very clear way to provide a space for sustained feedback. All of these allow feedback to happen over time, and ideas to be exchanged frequently. Remote work requires being intentional about behaviours that are implicit or unconscious in an office setting.

Shift from voice to text

Most modalities for reviewing designs and gathering feedback rely on voice and a direct, synchronous exchange. When going remote, the primary form of communication should shift from voice to text, and from synchronous to asynchronous.

Note that I say “primary”: voice and calls still play a role, but shouldn’t be the default. In a way, we need to take a page from the way developers review code and discuss issues. Developers have text communication built-in in almost all their tools. Designers need to figure out the approach that works best for us.

There are many advantages to using text:

• It gives people enough time to reflect and clarify their ideas before replying.
• It’s flexible — not everyone needs to be present at the same moment.
• It reduces the impact of loud voices that can silence the quieter ones.
• It gives us the space to be as precise as needed.
• It allows more people to participate, thus increasing transparency.

Some people might be way more effective using voice communication. This is expected: it’s a skill that people practiced for years, and many of us haven’t spent a similar amount of time developing written feedback skills. It’s just a matter of building up that experience.

Define your feedback loops

Putting these principles together, the idea is to take your design and production workflow and make sure that you have sustained feedback across multiple communication channels, and that your primary channel allows for textual asynchronous feedback.

The primary channel should use a tool that allows for posts with discussion threads. At Automattic, we use a specialized tool called P2, based on WordPress, but you can also use other tools like Basecamp, Yammer, or Facebook Workplace. If your company is already comfortable with GitHub or GitLab, you can use these too. This can be used for both quick rounds of feedback on details, as well as for larger pieces — entire design iterations.

A chat channel is excellent for frequent, quick feedback — share an image, a mockup, a screenshot, an idea, and get some replies. If the conversation gets too large or complex, shift it back to the primary channel. Also note that every change that is discussed in a chat should also make its way into the primary channel. Don’t assume that the chat is enough for visibility, especially in larger teams and organizations. You can use services like Slack, Microsoft Teams, or Element.io for this.

A live channel, usually in the form of pair design — see, I told you voice wasn’t going away! This can be done effectively with a design tool that supports real-time collaboration like Figma, but can also work well if one designer executes quickly while the other reviews and discusses.

An open critique session, where more people (and often, senior designers from outside the team) review the work and give insights. This is partially to show the work done to a larger audience to help teams synchronize better, and partially to get external feedback from people not deep in the design work. This can be done with any video conferencing tool that supports screen sharing — we typically use Zoom but other mosaic visual ones like Meet are good.

There are two interesting properties in this mix of approaches:

• Increasing Bandwidth — while text is excellent because it allows people to better manage emotions and reduces hot takes, sometimes a voice chat can clear misunderstandings quickly. The mix above allows the flexibility to scale the communication bandwidth up or down to be as effective as possible.
• Variable Frequency — chats are frequent and fast; the primary channel is slower and steady; voice conversations can happen periodically, or any time clarification is needed. This covers a wide range of needs, and provides the space for sustained feedback to happen.

The structure above is meant to be general, so mix and match the pieces that work for you, and add any other approach that’s useful for your specific team.

Notice that none of the above is specific to any design phase! You can do all the above at any time, whether you’re preparing a user interview, analyzing research insights, preparing a wireframe, drafting a pixel-accurate visual design, or making a prototype. It adapts to any process your company is already using.

These principles of remote design are what I found working well in many different remote teams — and it’s the design workflow foundation that allowed Automattic to scale so well for over a decade. It can also be very effective for organizations that are still office-centric, as it allows for more flexibility and more transparency.

I’m sure it can work for your team too.