The case for asynchronous design meetings
Every time I go to conferences, workshops or other events, I try to understand how other designers and their teams work on their day to day basis. What processes are their teams adapting? What’s working well and what isn’t? Obviously, there are no rules that will magically solve your design process issues. This is because every product is different, and every team has different constraints such as team size, remote work, company type (consulting vs product) or even just the overall seniority of the team.
One very common aspect of various design processes are design meetings/critiques (i.e., a group conversation between designers/engineers/etc. with the ultimate goal of improving a presented design). However, I have encountered some issues with these and decided to write this article about it.
When I started working professionally, I used design meetings to get all types of feedback and I quickly discovered that the complex problems weren’t being solved because they were really hard to understand or discuss in a meeting. This is because people would give superficial or irrelevant feedback even when I was specific about the type of feedback that I was looking for (by saying, for instance, “I am looking for feedback on the user experience flow of this feature”). I have come to learn that this is natural and most people have a hard time abstracting away from nitpicks when discussing a presented design (it’s also hard for me to do this). This is commonly referred to as “bikeshedding” or the Law of Triviality.
A fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task.
(My favorite example to describe the bikeshedding problem)
Moreover, people need time alone to think about solutions or improvements (I really value my focused time alone to think about design problems). This is where tools like Abstract (“GitHub for designers”), Zeplin, InVision, Figma and others come into play. Using these, designers are able to ask for proper reviews and discuss both pixel-level adjustments as well as complex UX flows asynchronously. Reviews where there is no time attached and where designers can think deeply about the problem by themselves deliver better results. Here are some other benefits of asynchronous design reviews:
- Less time wasted in meetings and allows each designer to more easily focus at a time that is more convenient for them (this is perfect for remote employees!).
- Easier to keep everyone on the same page and happy about what they are building because it is easier for everyone to express their ideas.
- Newer team members can accelerate their knowledge about the product by reviewing things.
- Easier for reviewers to be extra-clear in their feedback since they have more time to properly write it.
As in the synchronous meetings, it is also important to specify what type of feedback you want to receive. It may not be obvious to others if you are presenting the final solution or the first iteration. Sharing unfinished work can create uncomfortable situations that lead to unwanted tension, which means you should be as specific as possible about the type of feedback you are looking for,. e.g., “I just want a review of the UX flow” or “I want to talk about the color scheme”.
To make sure that these suggestions work, it is also important to have a clear separation between the product-design phase and the implementation phase. This allows for getting validation from various team members, to do usability sessions with users, and to test ideas before shipping. Unfortunately, in order to match startups’ time constraints, it is not always easy to have these 2 phases separated. That is why designers should be involved in the final implementation review. This way, designers and engineers can reach a compromise on details that might not look exactly like the mockups.
To conclude, apart from design meetings, designers should be doing more formal reviews and participating in engineers’ pull requests. I still think that synchronous design meetings are great for creating the first wireframes and to discuss the briefing or problem goals (sitting down to work together with someone else can be very powerful, just like pair programming).
One important thing that I have learned throughout my career is that feedback is really hard to provide in general! However, input helps create higher quality work, accelerate junior designers’ grow, reduce frustrations and this leads to designers being more confident when presenting their work.
Feel free to let me know how many design meetings you have per week and what your design process is like!
