How to give and receive great design feedback

As we continue designing and building MetaGame, or specifically the MetaOS, we regularly end up in situation where we either ask feedback of others, or are asked to provide it.

This can be hard, due to many factors. It certainly doesn’t come naturally, because we humans are, before all else, driven by emotion.

In order to handle these sensitive matters in a better way, let’s please all read this article on the art of giving and receiving great design feedback:

https://uxdesign.cc/how-to-give-and-receive-great-design-feedback-ca5e37eea4b9

You are welcome to chime in with your thoughts on the article afterwards.
Note: if you are a designer looking to join our ranks, and came here from Designer Path (Notion), it is mandatory that you leave a reply in this thread.

5 Likes

I appreciate you picking this post! Giving and receiving feedback is one of those soft skills that can often go unnoticed and it’s so important to bring attention to it especially in multicultural and multidisciplinary teams, even more so if it happens online, since not picking up tone from text, or not seeing someone’s face when they talk, can affect the quality of the dialogue. When you’re conscious of this it can feel like walking on eggshells at first, trying to use the right words and not saying things like “like/don’t like”, or bringing the individual into the conversation, but we can get used to it.

It’s great that he starts with the foundation of trust, because sometimes we can find ourselves in situations where we have to give or receive feedback from people we know very little of, or have barely shared any work or conversations, and it can be a bit awkward since you know nothing of how that person communicates or works, and vice versa. Plus, sometimes people just have “off” days and their mind might not be 100% on what they’re reviewing, they may not have the energy to be mindful of how they are communicating, and if it’s someone you know better you can tell it’s just an off day and nothing else. I know, personally, I’m sometimes sensitive to rejection/feedback, can’t turn that on and off. It can be hard to separate yourself from your work (the more “creative” it is, the harder it is), as it can be hard for others to separate you from your work.

This is why going from freelance graphic design to digital products with a team, I struggled with leaving behind the “reveal and expect a wow response” mentality. We need to iterate and have early feedback on the most basic things we start working on, but initially it can feel like “this looks bare and I could work on it more before someone sees it”, and that can be tricky because you may end up having to retrace your steps because the decisions you took to further work on it, aren’t valid anymore after incorporating feedback.

I think it’s a good idea to practice these tips when giving asynchronous feedback because you’re not on the clock trying to spot these things while you build the feedback in your head and try to formulate it following these things you may not have been paying attention to before. And sometimes that comes with incorporating simple things you hadn’t thought of. For example, instead of writing up feedback and attaching screenshots, or putting up comments in Figma, it could be more useful for someone to use something like Loom or Bubbles or record your screen on Zoom while you’re talking and moving through designs, after you’ve reviewed the work and have compiled feedback. Sometimes it comes with really thinking, as a team, “how can we best optimize our time together (calls/meetings) to make progress efficiently and deliver good work”.

On the topic of “describe problems, not offer solutions” I think it’s worth taking into account this is written focused on the work of a designer, and what’s described in this section makes complete sense: tell me what’s not working on the design, and I, as the designer, will find the solution, but I welcome any thoughts you might have on what that could look like (sometimes you do need the non-designer, for example when working with UI elements/interactions that may represent a technical challenge and might require a workaround). However I’ve found myself in situations describing problems in perhaps not specifically design work, but related pieces of work I had to provide feedback on, and I kept being told “ok fair enough, but don’t just come to me with problems, be prepared to suggest solutions”. So this I think is something to keep in mind here- it might not be that useful to someone, and ultimately, the team, to go and, even if you can describe and bring awareness to the problems effectively, start pilling them up in front of people without having at least some initial thoughts on solutions. But this depends entirely on what it is we’re providing feedback on and what our involvement with it or with the people working on it is. And even between just designers, not all of what we do is solely design work.

One thing I’ve learnt from experience is, when you’re presenting designs to someone or a group of people and it’s pretty much the first time they’re seeing it, don’t expect to both present things, receive good feedback and maybe also have a discussion about it in one call. Absorbing a large piece of work for the first time takes time and you need to do it by yourself, and then have the creator’s context, but it’s not time effective to do all in the same hour. Maybe provide the designs before the call, or record a presentation and provide the source of the designs and give them time to review before a call where everyone’s prepared to give and discuss the feedback, if a live discussion is needed at all.

All in all, nobody’s perfect at this. Patience, tolerance and respect always go a long way.

PD: I still need to work in my love sandwich :smile:

4 Likes

be clear and specific describing problems in a loving objective way, and explain your thinking.