I’ve been lucky enough to participate and conduct some rather helpful feedback sessions, and also unlucky enough to attend some that were just rubbish.
When we were doing feedback sessions on a fancy kind of new UI widget we wanted to see if people could easily figure out how to use it well, so we conducted a series of user interface trials. We had a mix of novices and trained UX folks.
If you have done these you probably know how hard it is for developers to gather feedback without biasing the user.
Luckily we had a short list of rules we use for such events, and this list has been successful for us in many cases. We were able to gather a lot of good information and create a useful UI control.
But the same is true of other kinds of feedback, including when you have to challenge a subordinate, coworker, or boss. Maybe some training in crucial conversations may deliver additional nuance and guidance, but for many cases this list has been sufficient:
Listen.
No puppeteering.
Don’t defend or explain.
Ask only clarifying questions
Don’t make promises on the spot.
Thank the feedback giver.
Let’s take those each in turn.
Listen.
The purpose of a feedback session is to hear what other people think, or see what other people do with the tools you give them. As such, the focus is on what they see/hear/think/assume and not on what you intended.
If we are to get any value from a feedback session, it’s crucial that we spend the time listening. Taking notes is good, too.
Even listen when the person is wrong. If they’ve got it all turned around sideways and backward and were completely wrong, this is a time to hear them rather than a time to square them away.
No puppeteering.
Don’t put words in their mouth, don’t control their conversation, don’t take charge.
A classic blunder is to ask someone “so didn’t you like the way the color scheme changed when you clicked the button?” That kind of leading question is how you get them to say what you like. You’ve offered them the option to either agree with you (which isn’t feedback really) or to take a chance on disappointing you.
With UI work, we don’t direct them on how to use the control. This isn’t training (see Listen, above) but feedback. We need to instead give the user a task, and see how they go about figuring out how to do it.
This also applies when asking for feedback from teammates. “Tell me how you liked the improvements I made to simplify your code; isn’t that great?” is puppeteering. Don’t direct the person giving feedback as to what they should notice or what they should say.
Don’t defend or explain.
This part is really hard. I’m not kidding. It’s tough.
This relates back to “listen” but it’s even more important.
When someone gives you feedback about what they did not like, or what seemed odd/wrong to them, if you explain it away or defend then you’ll find them less eager to talk about anything else.
Imagine how you feel when you make a suggestion or give a complaint and the other person deflects it. You immediately feel that they’re not interested in your opinion, that they don’t see it as a problem. They have communicated that they feel your input is trivial or irrelevant.
“I’m having trouble fitting into the culture here.” “Oh, relax, you’ll get it.” “No, really, I’m not connecting with Fred or Alice on the team.” “Well, Fred is an introvert so that’s normal, and Alice is very busy.” “Yes, … but …. never mind.”
This is a similar drill when someone says “I wanted to be given an option to search by name instead of using a drop-down list” and everyone who built the control is twitching with an urge to say “that’s what the box was for at the TOP!!! Use your EYES!!!”
You don’t explain. You don’t deflect. You don’t defend.
You make a note. You’ve listened and you’ve heard. You can talk it over amongst yourselves later, but you’re accomplishing your goal of listening and learning about others’ expectations.
Ask only clarifying questions
This continues the uncomfortable work of staying OUT of the control game and listening.
Don’t ask “why didn’t you click in the white box above the drop-down?” that’s taking control, and educating the user. Remember that a good UI is like a good joke: you shouldn’t have to explain it.
Likewise, when someone confronts you about something in the workplace, perhaps with an accusation, your job is to figure out why they think the thing that they think. You probably shouldn’t have to explain it away.
Ask what they saw. Ask what that meant to them. Ask why they interpreted it that way. Ask what else was on their mind connected to what they say/heard. Ask how it affected them. Review your notes and see that you’ve gotten them right.
If you ask about their experiences without deflecting or directing, then you’ll be more likely to get some information you can use.
Don’t make promises on the spot.
It doesn’t get any easier as we come down the list, does it?
When the person giving feedback is right (or important) then there is always a strong urge to make a promise to correct or change.
This is usually a mistake.
You’ve just gotten some information - it may be good or it may be hard to swallow. You are practicing a lot of self-restraint, and it is hard to remain calm and centered while trying to not control or explain or defend.
The only promise you should make on the spot is to consider what they’ve seen and what they’ve heard and how they’re experiencing it. Even if they’re wrong, you should keep it to “I’m/we’re going to think this over.”
Sometimes we feel pressure to make a promise just to defuse the situation and relieve the intensity of the moment. We want to reassure the other whether we want to change or not, and an idle promise to “try harder” for them often will make them feel better.
But don’t. This isn’t the time for resolution, but for understanding.
Thank the feedback giver.
No matter how right or wrong the other person is, they’ve taken a vulnerable position by coming to you with feedback.
In the UX context, they’ve been muddling about trying to figure out your UI and fumbling about the application in full sight. They probably feel a little foolish.
In a behavioral context, they’re vulnerable because they are admitting to their feelings and expectations and the presence of some difficulty. They could ignore it or smooth it over, but they’ve brought it to you.
The least we can do is thank them.
If you want them to keep doing it, you should thank them for giving it.
Does This Mean I Can’t Defend Myself?
Are you being attacked?
If you have asked for feedback, then you have asked for something to be criticized or complimented as the other person desires. Hopefully you asked them to comment on some piece of work, with the intention of learning whether/how to improve it.
If the discussion is about the work, then you aren’t being attacked. The work is being discussed.
If the other person starts assigning motivations to you, you can ask them to please stick to feedback on the work, and not on your alleged state of mind, please. You can ask them to keep it impersonal. You can ask them not to assume your motivation or intention, but talk about their experience.
If they misunderstand the work, then that’s okay. You now know that it’s possible to misunderstand and misattribute the work. It might even seem to others that you had bad intentions, maybe you can work on that image (or change intentions).
Again, the goal is to gather information about how people have experienced some bit of work or behavior, and understand it from another person’s point of view.
Behaving in a defensive manner or, worse, mounting a counter-attack, does not encourage honest sharing of feedback. Remember the mission here, and don’t let ego get in the way of learning.
Resulting Context
You’ve had feedback. You’ve heard a person out. You’ve clarified what you’ve heard, taken some notes, thanked the person.
Now you have some internal work to do. You, who have received and understood feedback, now have more information than you had before.
Go think about it. Talk about it if you’re a member of a team or organization that has received feedback on joint work. Retrospect on it. Work out a plan. Figure out how to go forward, and whether you’ll act on the feedback.
If the feedback is wrong, you have some image work to do.
If the feedback is right, you have some new plans to make.
Either way, you are on your way to improvement.
If you choose to do nothing, at least you had a fair chance to think it over and make that decision honestly with your eyes open.
If you do make some changes, consider letting the feedback givers know. Also consider repeating the process after you’ve made those changes.
