Making Feedback Helpful in Design Discussions

People create better things together. More people bring wide set of ideas, perspectives, assumptions and use-cases. And as designers, we put so much trust in collaboration. Design sprints, design critique, design clinic, design insert your choice of word here. The underlying idea is simple — work with multiple people to make design solutions more robust. But how exactly might we do that? How might we set the stage for receiving good feedback? And how might we give feedback that actually is helpful?

At least for once, we all have heard feedback that goes like:

Oh god! This looks horrible?!?

You should use the radio buttons instead of toggles!

I think those icons are confusing.

Can you reduce the clutter?

And the list could go on and on. These are not good feedback. These are reactions and opinions that are preferential in nature. These reactions also lack any direction and don’t explain “why” something looks horrible. Or why we should use radio buttons instead of toggles? These reactions are backed by a hefty set of assumptions— the presenter didn’t consider radio buttons or other icons. Maybe they did, maybe they didn’t but verifying it by framing these as question might work better.

Setting the stage for receiving better feedback

Any design that we create, tries to achieve a particular outcome. It might be attempting to improve a metric by solving a problem. OR it could be leveraging some business opportunity by filling in the user need. The point is, whatever we are designing, we are designing for a desired outcome.

As designers often we are so engrossed in the “how of things”, that we forget the “why of things.” We are often eager to share how we are planning to do, what we are planning to do—often ignoring why it was worth doing in the first place.

Setting the stage for receiving better feedback is a step by step process. I first came across this simple yet effective framework from the book called Discussing Design by Adam Connor, Aaron Irizarry. It looks quite obvious in the first sight but after following it in the past few months I’m convinced of it’s effectiveness.

From: [Discussing Design](http://shop.oreilly.com/product/0636920033561.do)
From: [Discussing Design](http://shop.oreilly.com/product/0636920033561.do)
From: Discussing Design

  1. State the problems and constraints to help set the context. The more convinced stakeholders are of the problems, the better feedback would be.

  2. State the objective of the design.

  3. Point out design elements that are related to the stated objective.

  4. Explain why (or how) those elements are working to achieve the stated objective.

Following this framework not only means that we’re setting the informative stage for receiving feedback, but it also means that we need to be very clear about our own thought process while designing. We have to be constantly asking “Why am I doing what I am doing…?”

Giving better feedback

On the other end, when a design is presented around this framework, it makes it easy to give feedback about. For every step, the reviewers can simply exercise the critical thinking — taking each of the presented statements and find out if it’s true or false.

It’s important that we agree on the stated problems and the objective before thinking about the presented solution. Once done, we can make sure that our feedback revolves around the stated objective.

An example of a constructive feedback could sound something like this:

“If the objective is for users to use filters more often, putting it in the top along with search bar might not be effective because it gets lost in all other components in the header.”

If the objective is for users to use filters more oftenstates the objective the critic is analysing.

… putting it in the top along with search baridentifies the design choices made that are being analysed.

… might not be effective because it gets lost in all other components in the header.” Explanation of why the critic thinks the design choices made won’t be effective.

Making feedback is not about establishing processes. It’s about individuals taking lead of presenting their work better with relevant context. It’s about reviewers making sure they provide thoughts around the stated objective. There’s no limit to the amount of improvements we can do to a product with infinite resources. But in reality, we need to work under constraints and limited resources. Staying focused around the objective — while presenting work and reviewing work — can improve the product within limited time and achieve objective that matters to us, efficiently.

Good feedback is hard and that’s why we don’t hear it often enough. However, with just a little mindfulness from the both sides — while presenting and reviewing — we can be more effective in making better things together.

⦿

Written on April 11, 2019 in Singapore

← All writings