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.
2016-08-01 at 17:39
Sorry for the long comment, I hope it is worth your time reading it. 🙂
When leaving feedback (mostly program source code, but recently English-to-Swedish translations fo said programs) I conciously try to avoid opinionated comments (“I don’t like…”) and try to go for a more precise reasoning (“You improve … if you change…”). This seems less confrontational to me.
Sometimes I attempt to cheer the reviewee on (“It would be great if you have the time to …! You’re doing great!”) as sometimes I have to comment on trivial matters (typos in translations and formatting in source code (because companies often have strict rules concerning formatting)).
I concur with the post and I believe that doing good feedback that is being well received is like being a part time teacher. For me personally I know the material best that I have to teach to others since I have to organize my thoughts on the subject at hand. When doing reviews you basically do the same thing as you need to organize your thoughts and succinctly motivate what is good and what can be improved upon and why.
As a person whose work is being reviewed you _also_ need to stay humble and gentle. Sometimes you have been the one to actively ask for feedback, sometimes the work process just encourages/enforces it. In my opinion as the reviewee you must realize that the feedback attempts to improve the quality of the work you’ve done, it is not a personal vendetta. And most importantly you must set aside time to work on the improvements being requested (many people fail this one (even if they are the ones requesting feedback!) and assume that they are already done
with whatever they are doing and so the feedback is just a nuisance to them). Also the feedback is a learning experience becuase you will (hopefully) stay away from doing the same mistake next time. Right..? 🙂
One thing I have learned is that you should ask for feedback early on and quite possibly several times. Doing this avoids having to redo a major part of your work because of a simple feedback comment at the very end. Instead you get the opportunity to think about and handle it while writing/doing the majority
of the work, before your work is too big/too detailed.
If possible specify what kind of feedback you are looking for (“This round I care about RPG rules and how the work together, don’t bother commenting on grammar/typos”). So you don’t get overwhelmed by correct, but at a particular point in time, non-essential feedback.
The article suggests in the second to last paragraph that while content can be reviewed it is often is less strict about what the contents should look like (compared to the relative strictness of fact-based function). Have you experienced that you appreciate different kinds of feedback in these two cases? How do you as a reviewee want content feedback to look like?