15 December 2015
15 December 2015

Not all feedback is good feedback

There is no doubt about it: feedback is essential fuel for designers. When we become blinkered towards the work we’re doing, it can help us get another perspective. When we’ve run out of ideas, it can help us explore new directions. Given the potential benefits, it’s well worth spending a bit of time designing how you get feedback to make the most of it.

“What do you think of this?”

Asking for design feedback is relatively easy – I find someone, or a group, with opinions, show them my work and ask “what do you think of this?” … and that’s when everything goes wrong.

I’ve invited a fire-hose of opinions and comments and, if I’m lucky, some might be useful and relevant to the work. More often than not most of this feedback will be subjective and won’t help me improve the work. An opportunity has been wasted and it’s all my fault.

When I ask for feedback on my work, I’m usually looking for a critique: it’s all about how the work could be improved. In order for someone to be able to usefully critique my work, they need to have some context and understand what I’m trying to achieve with the design. In the scenario above, I haven’t helped anyone understand the context so I end up with little useful feedback, and no fresh perspective or new ideas.

Why do you want feedback?

Before soliciting for feedback, ask yourself why you want it. Are you trying to improve the work you’ve done by getting it critiqued? Or is the work finished and you want to review it to make sure it’s good to go? A critique and a review are different activities:

  • A critique is about improvement, an iteration, e.g., what other ways could this be done
  • A review is about approval, a gate, e.g., does this design do what we need it to

Choosing one over the other will help you decide who you invite to provide feedback.

Pick your participants based on what you want from the feedback process. Forget about job titles and responsibilities – choose those who are most able to give useful and meaningful feedback for what you want. It’s not necessarily going to be other designers, it could be domain or customer experts. For reviews you’re probably more interested in those who are going to be moving the work forward, a client perhaps, or the development team involved.

Using a feedback “lens” can be really useful for providing focus for a feedback session. Agree up-front what the focus is so everyone participating can feedback accordingly. For example, you may decide that you want to look at whether your design work fits the design system you’re using. In that case, inviting participants who know the system and have used it for other pieces of work would be useful for the critique. Jared Spool has written more on using a feedback lens in Critique: The secret to growing your UX team skills.

Remember your manners

Whether you have ten minutes or a whole afternoon available, it’s a good idea to establish some rules and boundaries for feedback. This will help everyone participating to provide feedback that is relevant and useful for you and enable you to use the time efficiently.

  • Allow enough time to present the work / ideas
  • Qualifying questions from other participants are good but don’t interrupt the presentation
  • For those providing feedback, make notes of the feedback on post-its – this gives everyone a fair chance of getting their ideas out and makes collating feedback easier
  • Keep feedback constructive and objective – instead of identifying weaknesses in the design, provide ideas that could improve the design
  • If it’s your work, consider nominating a facilitator so you can focus on presenting your ideas and exploring the feedback

Be a better provider

So far I’ve mainly been coming from the perspective of someone who is looking for feedback. If you’re being asked to provide feedback, there are some things you can do to help the process as well.

If you’re not given some goals or context for the design then ask for them before giving feedback. This can really help the person seeking feedback because they might not have thought about it. Just asking why someone wants the feedback and what they are trying to achieve with the design can put you both on course for a more useful discussion.

Try to keep your focus on the goals or problem the design is trying to address and explain why your ideas could improve the solution. This helps you remain objective and provide something that is going to be constructive and useful for whoever is presenting their work. It’s okay to offer opinion without a solution, but make sure it’s focused on why you think the design doesn’t address the goals or problem.

Look for inspiration

There are lots of good resources about running good critique sessions and some that I’ve found useful are:

  • Atlassian have a process they call “Sparring“, which is their evolution of the design critique. Their focus has been integrating critique into the product development process.
  • UIE have shared some lessons for conducting great critiques. One insight is from Pixar, who make sure they only critique work that is between 25 and 75% done. The idea here is that before 25% an idea is too new to have meaningful critique, and after 75% too much work has been put in to make critique useful.
  • Google Venture’s guide to design critiques provides a nice framework for productive critiques.
  • Alisan Atvur has a technique he calls the critique cross that is great tool for structuring meaningful critiques.

Have you got any feedback?

Whether you’re designing, building, writing or creating anything, you can use the same techniques I’ve talked about to get feedback on your work. That said, are there any feedback lessons you’ve learned that could similarly be applied to design? If so, let me know.

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in Blog

The real origins of the Agile Manifesto

In February 2001, 17 people met at the Snowbird ski resort in Utah. They were the leading exponents of Extreme Programming, Scrum, and Adaptive Software Development, and they were seeking a set of com...

Also in Software development

Are your automated tests slowing you down?

Slow, unreliable tests prevent teams doing great work, and make continuous delivery impossible.

This was true for our SQL Source Control team when I started working with them. From pushing a commit t...