One of the hardest things to learn in a creative occupation is the art of giving and receiving feedback. In my experience, most of us start getting defensive when being confronted with information that can be construed as criticism. It’s only natural to want to defend something we’ve created, after all. But the idea with feedback is not to attack a thing but to make it better by pointing out weaknesses ans shoring things up to make a product stable.

A fairly common occurrence for those of us working with design that is at least partially visual is that feedback tend to be only skin deep. This is because most of us don’t think that much deeper than the first layer of things. A design that might otherwise be solid can be harshly judged due to a lacking presentation, and something that looks pretty might not be very useful. This is particularly true for the design area I’m currently working in, which is UX design. A not insubstantial part of UX is UIs. In their primitive form, UIs are not that exciting. UIs are ultimately utilitarian and they also rely on how the masses experience it rather than one expert user due to that utilitarian nature.

As a designer I can make assumptions of how my UI will be used, and I can guess at reactions. But in some cases, it only takes one word to make or break an entire UI screen. Use the word ”teleport” instead of ”fast travel” and it will have an impact on how the players experience your UI. User testing is in a word, vital. Part of that testing is receiving feedback from the users and learning how to parse it.

Feedback is hard to give, almost harder than it is to receive. To be able to accurately feedback on something you ache to go deeper than the first layer of visuals. Imagine that you’ve been given a game to play. You’ve anticipated this release of the game for a long time – this is something you love deeply, perhaps by legacy or for some other reason.

You’ve been given this game to give some feedback on the UI or gameplay or similar, but when you start it up you realise that the game is flawed in so many ways. At the same time you really want to like it, and you don’t want to hurt anyone’s feelings by being critical. The thing to remember is that you’re not giving feedback on the person who has created the thing. You’re giving feedback on the thing.

What does good feedback look like?
Primarily it is concise, it points to the problem and it tells you exactly what that problem is. Let’s say we have a screen that uses dark blue text on a black background, In such an instance I would say ”the screen has readability issues” which the definition of the problem. ”The low contrast between background and text causes and text causes the text to disappear in the background”. Which is a definition of why it is a problem. ”I would look into changing the color of the type or the background to create a better contrast.” which is the solution to the problem.

You don’t always have to solve problems, though. Sometimes its enough to just state that there is a problem and that is it.

Feedback such as ”I don’t like this” is not really feedback, it’s just a statement of dislike. That is useless from an improvement perspective. Okay, someone doesn’t like this – I have no idea why. Toss all that away unless you have the opportunity to interrogate the person and find out why.

”I don’t like this, I think the font is ugly” is better, but it’s stilla judgment call. An ugly font and is based on opinion. While opinions are sometimes valuable, they’re still highly personal.

”I don’t like this, I think the font is ugly and unreadable” is getting into true feedback territory. If the font is unreadable then we have a problem and a real one. Thankfully one that can be fixed, in particular if this feedback recurs.

Giving feedback hinges on the same principles you can certainly dislike something and that might be enough for you, but if you want that feedback to be useful and valid for the people you’re feed backing to, you also have to be aware of why you think it doesn’t work and how you would change it.

Sometimes all you can do is give your opinion based on taste or judgement. In those instances, be aware that your feedback may still be welcome, just not acted upon.

This goes for everyone receiving feedback as well. Look at it, listen to it, but know that in the end, you’re responsible for any change you want to do based on the feedback you get. If you, like me, on occasion end up in a situation where you have to give feedback on someone’s work and you happen to not like that person – try extra hard to be impartial and not let your feelings cloud your judgment.

I review games for a Swedish table-top role-playing game magazine, and let’s just say that doing that has put me at odds with the game making community in Sweden multiple times. It is sort of a constant. Just as I think the controversy in me saying what I think has died down, someone else pops up and tells me I should shut up and not be such an SJW. Those opinions normally doesn’t include constructive criticism, only ad hominem attacks and speculation about my motives.

Sometimes I have to return to authors and designers who have hurt me, or authors who have a very opposite view on things like equality and diversity. When I do, I try to stay as objective as I can when it comes to mechanics and be aware of my own bias in the regard of content.

One important distinction to make is to separate between content and function and to be aware of which of those two you’re actually feedbacking on. Content can be fact based, of course, but more likely it’s flavour based. Function is not. Function is intended to be fairly specific and the result of a function can often be answered yes or no.

Conclusion: giving and receiving feedback is bloody hard. Practice both. Be humble and gentle and don’t let your own biases color your feedback. Remember that you’re criticising a thing, never the person behind the thing, and if you do, you’re doing it wrong.

Giving feedback took be about 5 years to learn. I still don’t know how to receive it gracefully.