6 lessons we learned from feedback sessions in Figma

And it’s true, working remotely, while still being part of the hive, is extremely challenging when it comes to team collaboration. So, how did we collaborate before the pandemic forced us to stay at home?

How we started pre-COVID-19

We were looking for a collaboration solution even before we went remote. Primary reasons for that were projects that were growing in size. And more often than not, we were in a situation where we had to increase the number of designers working on the project. This was especially true for products with longer timelines or some large-scope website projects.

Our tech stack at the time relied on Sketch, Abstract and Zeplin. While this is something that still worked for the product part of our company (Abstract’s versioning is a life-saver for product design workflow), our Creative unit (peeps focused on interactive/websites) needed something that focused more on quick ideation rather than producing and maintaining a single source of truth. At this moment, the pandemic situation was getting worse, and it was evident that we’re going to need to adapt our workflow to work from home.

Lockdown and the need to work together (again)

So the start of WFH (work from home) was a copy/paste of our usual workflow. Each designer was working on their own in Sketch, and occasionally, we would have a sync where we would show each other what we were up to. Over time, designers ended up being somewhat isolated from each other, and we were missing that knowledge-sharing component of our company. We quickly realized that we need some kind of collaboration mechanism, and we needed it for two reasons: 

• it enables designers to ideate in the same file 
• it facilitates real-time creative reviews

 So… Figma? Yup, let’s do it in Figma.

Adopting a new form of Design reviews

Our weekly design reviews took a completely new shape. We prepared and shared our progress on progress meetings and exchanged feedback twice a week. That ended being a big part of our day, and we were discussing a lot in these meetings: visual design, project strategy, or client communication.

Real-time collaboration features in Figma helped us tighten the feedback loop in our projects, and you could see the quality of our work starting to improve.

But as a result, this ended up requiring a large investment of energy trying to maintain normal project workflow and implementing feedback from senior designers at the same time. Our process did not plan for that. At that moment, it became apparent that we’re going to have to reinvent our workflow more thoughtfully than just adopting an initiative pulled from an article on the internet and slap it on without changing anything.

So what are the lessons that we learned from our feedback sessions?

1. Know exactly what you’re looking for from a feedback

Receiving feedback in a general sense is a useful tool to see another person’s perspective. However, you should have clear expectations from a feedback session. Is it an improvement on visual skills? Maybe you need a tip or two on how to do effective research or inspiration? Once you define desired outputs, make those expectations clear to the rest of the team that’s going to do a critique. That makes for a more focused session, and it makes good use of everybody’s time.

In our case, we almost always defaulted to the visual communication critique since this is something that we decided would be the primary purpose of our sessions.

2. Define the actionable of a feedback

After receiving feedback from a team, you should be able to have clear next steps. That enables you as a designer to apply feedback and adopt new good habits. Feedback sessions should not leave you confused or overwhelmed.

3. When you receive feedback, you still hold the decision-making power

There will be cases where feedback you receive from other team members will be in direct conflict with each other. That’s perfectly fine because there is more than one correct solution to a given problem. It’s up to a project designer to decide what to implement and in what way. 

Here are a few key reasons for this: 

a) The lead designer has a lot more context: knows the client better, has a greater awareness of the client’s needs, knows possible limitations of the project. 

b) Authority on how to implement feedback gives the designer power to maintain the vision that was established. If you react on everybody’s whim (however reasonable it might seem at that moment), it can water down a design. 

Bear in mind that if a whole team agrees that something needs to be changed, you should probably do it 🙂

4. Keep an open mind

Feedback sessions should be a safe place to voice your concerns, and you should feel comfortable receiving feedback. Receiving feedback is not always an easy thing — and that is natural, as you’ve put an effort into something that is being critiqued. But remember the goal of feedback: getting better should be the focus.

When I receive feedback, I remember all the instances where different perspectives made me a better designer. 

5. Maintain a positive attitude while giving feedback

As we expect that the person receiving feedback to keep an open mind, we also need to take care of how we voice our feedback. The point of feedback is to unblock, inspire, or share knowledge. You’re doing it wrong if you create a bad atmosphere in a session, and that can be counterproductive. Be direct, but also be neutral.

6. No big project strategy decisions

What also happened to us was that we fell into a trap of changing the workflow of a project after a feedback session. That is something that definitely should not be in the scope of feedback. 

Folks at Figma said it best: 

“Design critiques are not the forum for that [making major product decisions]; teams should have separate road-mapping processes to determine direction.”

What’s next?

We’re yet to unlock the full power of remote collaboration in Figma. As we integrated a new tool in client projects, some new possibilities opened up. A cool example of it would be presenting to a client via prototypes or streamlining our developer handoff process all within Figma.

It turns out that just by adopting a tool for a single thing solved many more challenges than we initially planned for. 

That being said, it does take a little bit of getting used to (as is the case with most of the new things). Quick (and dirty) adoption of new tools can leave much of the processes in a need for an update. 

You could say that WFH made us collaborate even more closely and it tested our internal processes, and we can honestly say that with those new experiences we became a bit more robust as a team.