Tips to communicate with your team as a Product Designer
How to deliver the right information to the right person in a fast-paced environment & fast-growing teams
Disclaimer: My method for communication has been developed with two feature teams and may change over time. It may not be applicable to early-stage startups with fewer people, but can be adjusted to fit your needs.
This article is tool agnostic and essential actions that improve communication within the team and my productivity can easily be adapted in a different company using different tools.
Introduction
I started thinking about how to improve how I communicated with those around me when the number of people working on my projects kept increasing.
Mickaël David, Doctolib’s previous Head of Design told me a thing that struck me:
In terms of communication when you think you are sharing too much with those around you, you are actually sharing the bare minimum.
And it was true, the bigger the organization, the more diluted the information. I was always astonished at how I would discover, at the last minute, that a fellow product designer was working on a project very close to mine.
What would have happened if we could have synced at the beginning? A major leap towards an improved product? A major breakthrough? Discovering life on Mars?
As I aimed to enhance my communication skills, I came to a realization that it can be quite time-consuming, particularly in a rapidly expanding organization. Doctolib is a vast corporation, and the sheer number of individuals in the design team can be overwhelming. We have User Researchers, UX Writers, a specialized Design System team, Design Ops, and Product Marketing, among others. And if that wasn’t enough already, we also interact with Developers, Product Managers, Sales, Consultants, and so on.
The number of interactions became too much for me. Figma comments, emails, Slack messages, pings and calls became an everyday occurrence, and it made my organization complicated and the time allowed to actually work on my project difficult.
How can I get back the time lost and save time for deep work without compromising on the quality of information?
In the following article, I will try to convey tips & tricks based on my experience to improve the quality of information shared during each phase of the design process. As a conclusion, I will also focus on the learnings of my journey.
I. The death of private message
As I delved into improving my communication skills, I realized that private messaging is the worst medium to share information.
Whenever I receive a private message regarding a particular subject, it requires a lot of effort to recollect the project, its current status, and the subsequent steps.
The same goes when a decision has been taken without exchanging with the main stakeholders.
A quick discussion without sharing what has been decided with the whole group is the same as pushing back more work in the future.
When something has changed and someone from the team doesn’t know, they will have to work twice, to retrieve the information and to make the change.
Anticipate future questions from several stakeholders by sharing extensively with several people at the same time, let’s say on a public Slack channel that anybody can take a look at or a common document.
II. Define who the actors are
The Product Designer and its role
Here it is, your first day with your new team. New Product Manager, new developers, new projects.
You don’t know them, they don’t know you, it is good to get to know each other first over a coffee (in real life or behind your computers). And what better way to use this quality time as a way to present the role of a Product Designer?
Since I transitioned to this job, I have always tried to explain in extensive detail what being a Product Designer is.
If your grandmother can’t understand what you are doing, neither do most of your coworkers…
… and it’s alright!
Try to explain:
- How you, a Product Designer, work (it can be nice to write down a “How to work with me”)
- Your strengths and weaknesses
- Anything you feel should be known by your coworkers
Some coworkers may be familiar with the work of a Product Designer, while some may not but you have everything to gain from this conversation before and even during a project.
Understanding how everyone works around you
If you are the one who invited the person in front of you, as you should, ask how the other person works. You can double this discussion as a way to know more about how a Developer, a Product Manager (with a dive on the life of a Product Manager at Doctolib by Julie Massard) or an Engineering Manager works.
Effective communication with your team is essential for designing a solution. Understanding their process can help you communicate more effectively with them. Don’t forget to talk about their toolkit and how they use it daily (more on that in the article).
After they explain their process, explain yours, and what you need to work effectively.
It is important here to understand which struggles they are facing daily, explain yours and stand on equal grounds (and make some friends along the way 🌈).
Communicating with Direct and Indirect Stakeholders
In a project, there are two kinds of stakeholders I interact with, Direct and Indirect Stakeholders.
Direct Stakeholders are in the Feature team (Product Manager, Developers), or linked closely to the project team (UX Researcher, UX Writer). I have a constant interaction with them throughout the whole project.
Indirect Stakeholders are people outside of the Feature or Project team with a broader scope (Legal, Data analyst) or working on a different scope (Designers or PM in a different feature team). I interact with them temporarily on parts of the project.
The context of communication
I interact with Direct Stakeholders on a daily basis depending on which part of the process the project is. I try my best to focus on small interaction using the tools each of us are working on.
- If I need to talk about a specific point to an engineer about a Jira ticket, I ping them on the Jira ticket.
- I want to comment on a user story my PM wrote on Confluence, I comment on the Confluence article.
- A message that concerns several members of the team? Hey, good thing I set up a project Slack Channel that helps me communicate with them without disturbing others (more on that below).
When talking with Indirect Stakeholders, I usually need to take a few steps back and present a simplified version of the whole project again before going to the main reason I need to talk to them. However, it doesn’t change how I communicate with them: on their respective working tools.
- A member of the legal team is creating a doc and I want to know more about a certain point? I comment on the Google Doc they have created.
You get the gist…
Communicating in a team isn’t only to pass information from one person to the other, it is also about spreading it to those around.
Design is a team effort, if we efficiently communicate, everyone is involved and each has more information to provide better solutions.
If you are beginning your career or even if you are a seasoned product person, I would highly suggest reading this interesting article by Bas Wallet.
In it, Bas is making the connection between the deliverables, fields and roles in design, while also highlighting how personality types make certain aspects of design more suitable for you than for others.
Another way to know more about yourself and communicate that to others.
III. Communicating in action
In action, my communication process is divided into several steps before, during and after the design process. It’s introduced by a Preset and followed by 2 other steps, QA and Follow-up, each with a different way of communication.
Under each part lies several tools I will use to communicate with the team and Stakeholders. Some during the entire process, and others just at specific points.
The Preset
Set up a private Slack channel
Before every project, I start a dedicated Slack channel with the project stakeholders, the Product Manager, the UX Researcher, the data analyst and the UX Writer at first.
I don’t usually integrate the Techholder at first since there is a great chance that they are doing another project at the same time, but maybe I should start doing it to see if that improves communication during my next project.
I start by sharing all the information, links, and previous research on the channel with everyone, and bookmark some for easier access.
Having everything written as much as possible, allow me to know that we all have the same level of information before starting the project.
As the project goes on and more people are onboarded (Engineering manager, Techholder, Developer), we simply invite them to the channel. There, they will see the previous exchanges, bookmarked links and find answers to some of their questions.
This Slack channel will be used throughout the whole project and when the project is done, the channel is archived and all the specs of the project will be detailed in a Confluence article, written by the PM.
Set up an Asana project with your Product Manager
As a Product Designer, the one I talk with the most is the Product Manager. When we are not talking face-to-face, on Slack or during a call, we are exchanging on the process mainly using Asana (The process is more important than the software used, it can be Asana, Monday, or other. Clarity and accessibility when sharing information are key).
I have an Asana project template which I set up at the beginning of every project. On top of improving productivity, it doubles as a way to sync on a daily and weekly basis with my PM.
There, I have all the kick-off, documents and each step I must go through. This template can evolve as I add each new thing that I have to do on it, whether it’s a conversation that I need to have with a stakeholder to a design of a particular feature.
It also helps to keep all the thought processes, abandoned ideas & decisions. Basically, a second brain that can be shared with anyone.
This Asana project also helps during my weeklies with my PMs and other direct stakeholders as we can bring forward the subjects we want to talk about, another communication asset.
Discover
After the kickoff with the Product Manager, Engineering Manager, Techholder, UX Researcher, UX Writer, Data analyst (yes, it’s a lot), I put the finishing touch to the Slack Channel with:
- The kick-off recap
- The “next steps” with what everyone has to work on including myself
When interviews start, I invite Direct Stakeholders to the interviews where they can see how the user truly behaves and they can ask questions. On top of making them a true part of the project, it helps convey something intangible and hardly transmissible, the sense of purpose.
When interviews are over, I share the results and the analysis directly to the Slack channel before entering the next phases.
Define
When defining the main problem, we get information from many different sources, Tableau and a Confluence page with the analysis from the Data team and Dovetail for the research.
Then we define the flows, the How Might We’s and potential additional research on Miro.
We may organise workshops during these phases which can help convey the message of where we are in the project but there is nothing more reassuring, to me, than a good ol’ message on the project Slack channel at every step in the process.
Feels just like ticking a box off your to-do list when a job has been done.
It helps to set a landmark for the project, people can ask questions, and we can also use the recap to share the information with other teams at Doctolib.
Develop
When in the development phase, there are several back-and-forths. Between the team and the users, between the Product & Design team and the Tech team or between the Product & Design team and other stakeholders.
Communicate during the end of the early development phase
After testing the solution between the team and users, I share the important results with everyone on the project Slack channel together with the decisions that will later be implemented in the flows on Figma.
If some people absolutely need to see this, I ping them in the post and ask for feedback directly in the comment.
Communicate during the following phase
Following this phase, there will be back-and-forth between the Tech team and the Design and Product team. After we agreed on the flows, we divide the work into two.
The Product Manager creates the user stories and specs in Jira and the Product Designer designs in Figma. The Developers, in order, to make the bridge between user stories and the designs, will most of the time go from one another and have questions.
During these phases, the main interactions I have with my Direct Stakeholders are made on Figma. If something is missing, or different compared to the user stories, they will let me know. However today I ask them to communicate their feedback in a particular way:
- For minor changes/minor questions on specific parts of the design: comment on Figma and ping the right person
- For significant UX questioning UX of the project (the ones that are longer than 3 lines): Post on the Slack project channel, exchange in the thread
- For major UX questioning/Can’t decide: Set up a quick 30-minute chat with the Stakeholders, decide on the decisions/next steps and finish with a post on Slack about what has been decided
Sharing and pinning this message on the team Slack channel helped me reduce the number of private messages talking about a specific design in Figma.
If individuals still contact me through DM, I share this list of how they should do it and try to explain in greater detail why their message is not suitable in this case (can’t answer to all DM about a Figma, the comment helps have a better reach, etc…).
Communicate with indirect stakeholders
If you are lucky, as I am, you may have designer colleagues (or non-designer colleagues) to whom you want to present the solution.
With them, I usually post a message on a specific Slack Channel including:
- The context of the project
- The flows/UI I need feedback on
- The Miro/Figma link in which they can comment/try things
If I need to sync with them on a specific topic, we will set up a call or a workshop later on.
Deliver & QA
In most cases, the delivery interactions will happen between Jira, Figma and the Slack Channel.
Jira and Figma to adapt and or finish parts of the design (like the edge cases, and error states) that can be forgotten during the development phase.
When all my specs are done, the scoping, and sizing are done and the tickets are created, I try to use a Jira Widget as a way to know where they are in the sprint.
For the QA the best time to talk about it is during the morning stand-up meeting with the feature team. That’s where engineers present what ticket they will be working on during the day, so you know which design they might contact you about. When they are done, there should be a ping or a change in the Widget status.
Follow-up
Once a project is done, we continuously share with the team, in the project Slack channel the good and bad news, the bugs, how many users are using the features, the performance, etc…
Mostly done through posts in the Slack channel, these will spark comments that will then turn into action.
Conclusion
The right information to the right person
This can sound strange after all this article but I also realized a problem in the way I was presenting information.
People don’t really care about the details as much as you do
My goal as a Product Designer is to gather several pieces of information, problems, and tiny details to transform them into a “simple” solution, the same goes when I communicate internally.
When I try to share what I am working on I always feel the need to share everything, too much in fact. To such a degree that my message would lack impact and people would make weird faces when they would understand less after my explanation than before.
Just wait for them to ask, then give the details
Thank you very much for reading up until this point. Don’t hesitate to continue the conversation in the comment section.
Thank you Vanco Yutian Zhou for the illustration
If you want to further communicate with me you can contact me on LinkedIn (by Private Message, the only kind that I like 😉).
