How Remote Meetings Can be More Productive For Developers and Designers
As more and more teams are collaborating remotely, having effective meetings between various stakeholders is key to successful projects. Developers and designers are two core stakeholders in this process.
Collaboration between them and the issues surrounding how designers share designs with developers are much talked about and clearly a question that has not been answered in whole.
Today, developer and design teams are spread across time zones to build products for a global audience. In such scenarios, communication is the key.
The people, processes, and tools all contribute to the communication process. Having transparent workflows that make it simple for everyone across the team setup to work with one another creates better communication channels.
When it comes to meetings for developers and designers, issues of scope, feasibility, bugs, navigation, and aesthetics are some of the main talking points. Left unmoderated and unchecked, they can stagnate projects to no end.
Here are some key tips on how designers and developers can share work with each other and have more productive meetings.
1) Meet only when needed
Meetings are not the goal, it’s the fruitful collaboration that comes through them. So having a meeting must be for good reason. Keep the scope of the meeting narrow enough so that you have concrete takeaways from the event.
Bringing everyone into the meeting, while possibly a good idea for building up the team, may not be the best idea for productivity. Don’t get the whole team involved unless they absolutely have to be there.
That means anyone who seems like a spectator at the meeting could rather be using their time more actively and efficiently. Only bring in direct stakeholders who will be contributing to the conversation. For sending out updates, embrace asynchronous tools.
2) Focus on the user
Users are the unifying theme for both developers and designers. Any ambiguity in meetings should be resolved keeping in mind what is best for the end user.
It is simpler to collaborate when working with a common perspective and that’s what a user-centric process provides. If there’s doubt about what features to implement, or what should be prioritized, think about what is most suited to the user.
By using user personas or a spec document detailing the needs of the users, teams can actively concentrate on solving specific problems for the user.
With Lucid Meetings, teams can also share their notes with the end customers so that everyone can collaborate in the same space. This way users can be part of the process too.
To get a better idea of user behavior, but without intruding in their natural workflow, teams can use tools that allow them to understand how users experience their websites and products.
3) Refer to a central source
When getting developers and designers together for stand ups, have a central repository that they can refer to. This not only helps in the meeting itself but also before and after meetings. Developers use Git for good reason, and designers are starting to adopt version control as well.
Having a central source to refer to makes it easy to track deliverables and tasks. Asset management is one of the core pain points when designers share designs with developers. There are many handoff tools like Sympli and Zeplin that help in that regard.
Consider using design systems and style guides as well. These provide a complete set of standard documentation and guidelines with respect to colors, fonts, aesthetics etc. that make it easier to place every element and show how the product should look and feel.
This central repository acts as a valuable resource that can be opened during meetings, via screen share, and everyone on the team has context on what elements are under consideration.
Any changes that have to discussed during meetings can be made in one instance and that is reflected to everyone on the team so there is no redundancy.
4) Give early contextual feedback
Pre-meeting preparation is important. One of the things that helps coming into meetings is the having shared and processed feedback.
Think about how inefficient it is if both designers and developers come into the meeting and then start reviewing projects to share feedback. Most feedback can be processed beforehand and shared via email or a project management tool. This way when you’re in the meeting, the conversation is about decisions rather than starting discussions.
Another factor is making feedback contextual. Rather than referring to an issue log or wiki to understand feedback, provide images that demonstrate what the problem is.
There are many visual feedback tools like zipBoard and Notable that allow sending screenshots with comments and annotations. This saves time because then a developer or designer doesn’t have to go about recreating the issue. They can simply look at the live example.
5) Set a time limit
This is true for any meeting, even if it isn’t remote. Setting a time limit helps contain discussions for the sake of discussions.
Have a set time for everyone to contribute and participate actively. A round robin arrangement helps get input from every person at the meeting and ensuring no one feels that they have not been heard.
Protocols help and final thoughts
Apart from the tips mentioned above, having a set of predefined protocols on how meetings and collaboration will be conducted helps structure the creative process.
That may be making it necessary to have an agenda (which is good practice in almost all cases), or setting a moderator who will check that no one strays from the topic.
The most significant advantage of having protocols is that it reduces the chances of having a deadlock. An impasse can be avoided if developers, designers, managers and any other stakeholders is aware of the rules of engagement.
For any organization to be successfully be able to scale their team, whether co-located or remote, they need to have a system in place that guides how people will collaborate.
