Communication is hard
At GitLab, efficiency is one of our core values. Being efficient in everything we do is important, but it's even more important when communicating and collaborating with others. We need this emphasis on efficiency, collaboration, and communication for GitLab to work as an all-remote company, with zero offices and team members distributed across the globe.
In the context of design, when you're explaining a design decision or requesting feedback, it's easy to fall into the trap of giving too much information. You want people to understand it right away, so you give as much background and arguments as possible. The problem is that long messages and explanations can put up a collaboration-barrier. When people have many things competing for their attention, it's hard for them to take the necessary time to read long messages and engage themselves in a constructive discussion. Also, often the most important points get diluted because of how long something is.
So how can you communicate better and more efficiently as a designer, especially if you're working remotely? I'm a designer working remotely for over 4 years and I've learned a lot about communication. Let me share 6 practical tips that you can use when sharing information or requesting something from someone:
- Important things first
- Keep it short
- Balance context and conciseness
- Use multiple formats
- Clear calls-to-action
- Use simple language
At the end of this article, there's a structure and example that puts all of these tips together, so that you can improve your communication today.
❗️ Important things first
Make sure you communicate the important things first. Journalists do this very well by using the inverted pyramid method: information is prioritized so that the major details come before the minor details. So empathize with your audience and think how much little time they can afford to invest in your message. Prioritize and structure your communication so that the key aspects come first and it's as easy as possible to learn about them.
📟 Keep it short
Keeping written communication short and giving short verbal answers goes hand in hand with communicating the important things first. If you need to give a lot of information, maybe there's a communication or expectations problem.
Although we default to asynchronous communication at GitLab, sometimes a short video call is enough to unblock and make sure everyone's aligned without having to invest too much time in writing and reading something. Our rule of thumb is: “if you have gone back and forth 3 times, it's time for a video call.” (also see video calls guidelines).
Other times, it can also be that the topic at hand is just too large to discuss in one go. Think about how you can break it down into smaller, more “consumable” pieces. It will make life easier for you, the other participants, and anyone else that is following that topic. To help you break things down, read “Iterate Like a GitLab Designer” or our handbook section on iteration.
🤹 Balance context and conciseness
Try to provide as much context as possible while balancing the conciseness of your message. This may seem the opposite of keeping it short, but you do need to strike a balance. You don't want your message to be too short, as it can cause confusion and require clarification, which ultimately delays things. But you also don't want your message to be too long, for all of the reasons I've mentioned so far. Striking this balance sounds incredibly challenging, but fortunately, we have some methods to help us with that, like the inverted pyramid that I described before or multiformat communication.
🎨 Use multiple formats
Communicating through multiple formats means thinking about your audience and applying your message to the formats that are most likely to attract that audience. An example is requesting feedback on an idea: you can share an image, a brief paragraph explaining the idea, a list of bullet points with the pros and cons, and maybe even a short video where you walk people through it. This way, each person jumps to and consumes the format that resonates the most with them, how they want it.
But remember that you don't have to use every format, every time. It depends on who you're communicating with, what you're communicating, and when a certain action is needed. Think about these aspects and choose the communication format that best suits them (and also the time you can invest in crafting your message).
☝️ Clear calls-to-action
If you have calls-to-action, make them clear, direct, and specific.
Perhaps the most important aspect of those three: try to direct your asks to specific people, instead of a group of people or no one at all. The work you put into selecting and targeting who you ask is proportional to the quality of their responses. Asking a group of people is sometimes necessary, but there's a risk of getting nothing but “radio silence,” so be extra careful in crafting your message if you're targeting a group.
Regarding CCs, one of our communication best practices says it best:
It is OK to bring an issue to someone's attention with a CC ("cc @user"), but CCs alone are not enough if specific action is needed from someone. The mentioned user may read the issue and take no further action. If you need something, please explicitly communicate your need along with @ mentioning who you need it from.
Be clear and specific about the who, what, and why. If it's a vague or broad ask, it will be much more difficult for others to respond.
Finally, place any asks you have at the beginning of your message. These asks fall into the “important things first” tip because, well, they are supposed to be important! If possible, consider repeating them at the end of the message as a reminder.
👐 Use simple language
Finally, use simple language and terms that everyone understands (see ubiquitous language). For example, instead of using the “IxD” acronym, say “interaction design.” Or explain what that means with simple language if you can, like saying “how a user might interact with the user interface and how it behaves.”
Example
To bring it all together, I'll first share with you a structure that you can use when requesting feedback or communicating your work, either in a written message, a video, or a presentation:
- Summary: A very short summary (tl;dr) of your message, with simple language and shared terms. If possible, consider bolding the whole summary so it sticks out from the rest.
- Asks: Be clear about what you want and until when. If possible, mention specific people and make sure to bold/highlight their names (if not automatically highlighted). When requesting feedback, specify the kind of feedback you're looking for, what they should comment on, and also what they should not comment on.
- Walkthrough: If you have a video or presentation that gives an overview of the topic, link to it. Better yet, embed it in your message to reduce clicks and friction, but always keep a link so it's accessible to everyone.
- Visual: Try to add a simple image/diagram that describes the core elements of what you're communicating.
- If you have more visuals that you'd like to share, link to an external page with them. For example, at GitLab we use Figma to design user interfaces, so we link to Figma files where people can view all of the design work.
- Details: More information in the form of short paragraphs or lists. It could be links to any additional references, support documentation, or artifacts. Remember to keep them short!
- Tip: Some writing tools support the
<details>
HTML tag, that allows you to easily hide information behind a toggle, like an accordion. See the MDN web docs for a simple example and copy-pastable markup.
- Tip: Some writing tools support the
- Close: Consider reiterating your asks and thank people for their time.
And to see how this can work in practice, here's an example message, where I requested feedback from my team members on a few possible design options:
Keep improving your communication skills
The act of improving one's communication skills doesn't stop, because the “why, what, how, and who” are always changing. The quality of communication can make or break an individual, a team, or an organization. As Anthony Robbins puts it:
The way we communicate with others and ourselves ultimately determines our quality of life.
In this article I focused on writing, speaking, and showing. But communication is also about how you read, listen, and watch. Maybe I'll write about that other side of communication in the future. In the meantime, I leave you with our handbook page on communication, which is a great place to learn more about what makes good communication in a remote company.
Cover image by Stellan Johansson on Unsplash