Every designer has experienced overlooking something along a project lifecycle. We are so focused on the task at hand that we want to keep going and fail to request feedback. In a context of remote work there’s even more room for this to happen as there’s more isolation, and we need to have mechanisms in place to avoid it.
In remote environments it’s common to have access to all on-going projects. So most information is available and everyone is welcome to share their opinion. This is a great thing as it promotes conversation, but it can create anxiety when it’s time to share something we’ve been working on.
On initial stages of a project I used to request feedback on a one on one basis. It was easier to provide context, process and discuss the feedback received and iterate to move on. But this lead to going forward without getting feedback from various sources. I had a tendency to fall back on the same people I “trusted” and thus focusing solely on their views.
At Automattic we are always experimenting and adapting the way we work. Teams are open to adopt working methodologies that fit their formats and needs.
I recently had two experiences in different teams where keeping track of individual projects and sharing feedback is done in a way that makes everyone comfortable.
In my current team we meet twice a week. This might seem a lot, but we work remotely, so we need to make an extra effort to communicate often. In these meetings designers are encouraged to show their work in progress so that everyone can keep track and help out. This way we avoid having people working in isolation for long periods of time without receiving any feedback. Team members can help out by identifying things that might have been overlooked or not thought of carefully.
It’s easier to share concepts and receive feedback on a smaller circle of people we are familiar with. It also provides an extra degree of confidence when it’s time to move on to the next phase. Since some form of validation is provided it becomes easier to share the work with a wider circle of people.
A while back I had the opportunity to do a rotation in one of Automattic’s product design teams and took part of a couple of design challenges to kick-off projects. Team members were presented with a problem to solve and asked to go to their little corners and come back with a solution within a timeframe. This allowed people to do research and create concepts on their own time and use their favorite methodology for ideation.
The format for the designs was not important, we could do whatever we wanted, as long as it was easily shareable: doodles on paper, wireframes or functional prototypes.
This methodology allows designers to come up with their own solutions and avoiding being influenced by group thinking. When there are one or more individuals with stronger voices there’s a tendency for others to follow to avoid idea confrontation.
We then proceeded to present each solution and receive feedback on the concepts we came up with. Doing design critiques with individuals that share the same knowledge gives room for deeper conversations and solving issues that would not be visible to less engaged and informed spectators.
In these sessions it’s common to have similar solutions as designers will end up doing similar research, but because people weigh things differently they take distinct approaches to solving the same problem. In the end everyone is trying to achieve the same goal.
Once ideas were presented the group highlighted the best ideas and formulated a solution to move forward.
The added value in this ideation process is that the differences between the concepts, when combined, create a more thoughtful and robust solution for the problem at hand.
When the project continues moving it’s likely that fewer people are involved, but everyone will feel familiar to the problem and will feel comfortable sharing feedback. They will feel that they were part of the initial solution, thus feeling some ownership and responsibility.
These are a couple of ways to make sure designers don’t feel isolated on the course of a project. Remote working is something somewhat new and brings challenges that need to be solved. This is just one of those challenges. I’m sure there are many design teams out there trying to find the best way to solve problems like this. I’m curious to know if you’re involved in designing in a remote environment what methodologies has your team found to solve issues such as designing in isoltation?
Originally published on Automattic.design. Featured photo by Kimson Doan.