Mar 09, 2019

A framework to give better design feedback: Analyze, Discuss, Suggest

A simple framework to give constructive design feedback.

Feedback is a gift. Feedback has a vital role in product development. Not only it can nurture the product, but it also could nurture the people who build the product. Yet as we’re all know, giving good constructive feedback is damn hard. Hence, I have been experimenting with this framework to make myself better at it; which hopefully can be useful for you too.

The framework

Analyze, Discuss, and Suggest

This framework helps me navigate when I’m reviewing works. I’ll explain a little bit of each point and guiding principles on each. Let’s dig into it.



The first thing you’ll need to do is to listen and analyze the work. What I mean here is to see if anything stand out from work presented, which can be both good things and bad things.

A few things to keep in mind:

  • First thing first, the intent of the feedback should always be helpful and not be offensive nor destructive. Be respectful to the team presenting. Sure, you can analyze everything, but if the presenter asks for specific feedback, you should respect that and make that as a priority. Also, be sincere, it’s not quite useful to give any insincere compliment (like sandwich method) and focus on what matters.
  • If you spot something that doesn’t feel right, pay attention to that and try to complete the blank of this statement: “I’m not sure about X because…”

A few questions that I’ll try to answer while analyzing:

  • What is the goal of this project?
  • What human problem is this trying to solve?
  • How close is this design achieve the goal?
  • How do I feel about this in general?


Now it’s the time to discuss what you’ve analyzed. Whenever possible, try to spark the conversation around the room rather than giving a statement.

A few things I’d pay attention at this point:

  • Now, let’s say the work presented is 180-degrees from where you think it needs to be or maybe there’s an aha-idea in your head. Well, hold on. Ask questions first, try to understand why the team did that in the first place. Maybe the team has thought about that and have a rationale on why not to pursue that idea. And most importantly, do not dominate the conversation so you can learn and read the room better, this can be a good opportunity to do a gut check.


Once you analyze and discuss, it could be helpful to suggest a sort of direction or guidance. This part often blends together with the discussion. And, by the way, this doesn’t mean you always have to give a suggestion.

A few things I’d pay attention at this point:

  • When suggesting a direction, try to make it solution-agnostic, which mean the suggestion should not imply any sort of specific solution because you want to give a room for the team to explore. At the same time, you have to be articulate, you have to be clear on what you think needs to be improved. Otherwise, it will be very hard for anyone to know what do they need to improve upon.
  • Once the discussion started, things can get pretty messy. Maybe some people in the room start to raise different philosophies or opinions about which direction to take, which is normal. When it happens, what I find useful is to lay out all the options on the table and this can be helpful for the team or the decision maker to weigh on what’s the best direction moving forward.

Additional note

I don’t feel great about the last feedback session I had, what should I do?

Don’t worry, we’re all been there! Try again. With this framework, you can analyze which part you are at the most? It’s all about the balanced seasoning.

  • Analyze 20%, Discuss 10%, Suggest 70% = Possibly destructive
    If you spend more time suggesting your thought, that can lead to destructive feedback because you spend a lot of time articulating your thought without trying to understand the context or the situation of that team.
  • Analyze 30%, Discuss 60%, Suggest 10% = Somewhat balance
    This is the combination that I’d prefer. If you spend more time to discuss and understand, chances are, you will be able to help the team in the area they struggle with.

Sometimes, I suggest a solution, is it a bad thing?

Although I’ll try to avoid that. Sometimes, I do that too when I’m running out of time or maybe I’m running out of patience. But, this shouldn’t happen often. Giving a solution-agnostic suggestion is healthier for the team because it will let them go through the process.

Closing chat to the reader

I hope this is useful. You can try it, maybe experiment with it a little bit. I’d love to hear if you have another framework, or maybe you have questions – you know you can reach me out. And as always, if you think the post is worth sharing, share it with your friends, colleagues, or (maybe) the rest of the world!






Sep 30

When was the last time you reflect?

Sep 29

Methods are tools

Sep 24

How can I get a bigger project?

Sep 23

Entering product design – Chapter 7: Craft and analysis

Sep 22

Entering product design – Chapter 6: Narrow collaborator

Sep 21

Entering product design – Chapter 5: Soloist product designers

Sep 17

Entering product design – Chapter 4: Product designer key skill areas

Sep 14

Entering product design – Chapter 3: Misunderstanding of business

Sep 11

Entering product design – Chapter 2: Principles over steps

Sep 10

Entering product design – Chapter 1: Silver bullet

Sep 10

Entering product design – Overview

Sep 04

SAR: A framework for concise storytelling

Aug 27

Start your design with outcome

Aug 24

New medium post: Collaboration ground for design systems

Aug 17

Action points

Aug 13

Pulse check: Listen to your team

Aug 11

You should actively apply for a new job

Aug 10

Design systems' area of influence: Service (3/3)

Aug 04

Design systems' area of influence: Offering (2/3)

Aug 03

Design systems' area of influence: Identity (1/3)

Aug 01

My mom ran me to the hospital

Jul 29

Reader question: Do we need to build MVP for every product?

Jul 27

Reader question: Do I need formal design education?

Jul 24

Recognize assumptions

Jul 21

Sandbox for your personal growth

Jul 20

Start your week with questions

Jul 17

Specificity in feedback

Jul 15

Don't sell the design. Sell the business impact

Jul 14

Overwhelming inspiration

Jul 13

The framing trap

Jul 10

Everyone vs. Specific

Jul 09

The blind horse designer

Jul 08

Set the context in your meeting

Jul 07

Let's just try and see what happens

Jul 06

Managing expectation

Jul 05

Low UX maturity company

Jun 17

A simple exercise for career reflection

May 31

The “Coach sheet” – A paper-based system for people management

May 26

Bring calm to your remote team

Feb 13

Workshops can be more efficient than meetings

Feb 07

3 questions designers should be asking

Feb 06

Walking 1on1: A refreshing way to connect


Nov 21

My hope for stubborn 'Innovators'

Jul 18

Five simple actions to help you gain more time

Apr 23

Evolving Product Experience Principles at Bukalapak

Mar 09

A framework to give better design feedback: Analyze, Discuss, Suggest

Jan 28

Making a decision is hard, here's my rule of thumb


Dec 04

Essential skills for Product Designers

Nov 16

Quick life update

Nov 06

Things I learned from working at Shopify

Oct 15

About design critique

Sep 17

Common icon design problems you should avoid

Sep 06

Preface: Welcome to