Over the summer, I have been in several situations where feedback was collected from a group of contributors:
* agile ux retreat retrospectives
* internal design critique sessions
* London IA presentation coaching workshop for Euro IA speakers
Each of these occasions followed a different process, which allowed me to compare and reflect on what makes a feedback round truly useful. It's often the simple, basic ingredients of successful collaboration we forget when working with others.
Group feedback needs facilitation and structure
Group communication that isn't leading to something tangible is lost communication. For the receivers, feedback should be actionable. The process should allow feedback contributors to combine their own reflections with those of others. For interested people who weren't present, a synthesis of all feedback can be valuable.
1. Process and structure
For the agile ux retrospectives, we used a format well-known from agile retrospectives. Each contributor records their feedback on post-its. All input is collected following a structure that has been agreed with the group. This can be 'good - room for improvement', 'positive - negative - ideas for improvement', 'less - more - start - stop' or whatever categories work best for the purpose of the session. After clustering feedback, either the facilitator presents a summary, or each contributor briefly talks about their inputs.
An agreed process and structure focus the feedback and prevent the session from going off-topic. These ground rules are helpful for making sense of and synthesising the feedback, which makes sharing the outcomes easier. A process also ensures that everybody can have input.
While I focused on group feedback, I've found agreeing a process - and a shared understanding of how to give and accept feedback - helpful in one-on-one feedback sessions.
2. Facilitation
At the London IA coaching workshop, I was both in the role of the audience giving feedback, and on the receiving end. The contributing group was rather large, and we had no agreed process, and no facilitator.
When you are the person receiving the feedback, you can't facilitate the discussion at the same time. A group feedback session needs to have a process owner, who ensures that everybody has a say, that the discussion is not going off topic - but also that the things that need to be said are being said. If the receiver and facilitator are the same person, there's a risk they'll protect their baby by shutting up the people who wanted to help with their input. So, the more personal the feedback is - your talk, your wireframes -, the more important is a neutral facilitator.
3. Note-taking and sharing
Our internal design critique sessions were very informal. For one, we all threw comments at a set of wireframes in a group discussion, while one team member took notes. For another, we individually commented on the designs using post-its.
While the second approach's advantage was individual time to think about the design, the first approach benefitted from the group discussion. Sharing our feedback meant we learned from each other, and it triggered further interesting discussion. That said, the group discussion critique session would have benefitted from notes being taken publicly on a flipchart rather than on a notepad - some good thoughts got lost in the heat and fun.
Make sure your contributors have the opportunity to share their thoughts, and visualise what has been said.
Deciding how to give feedback, appointing a facilitator, and making sure the discussion is recorded - common sense, but especially when winging collaboration sessions, I've overlooked how important these principles are. Next time, I'll look at my checklist. What other ground rules should I add to it?