Mar 09, 2019 | by Budi Tanrim

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.


analyze

Analyze

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?
discuss

Discuss

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.
discuss

Suggest

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!

analyze

Hi, this blog is no longer active. I move to substack. You can subscribe below or go to newsletter.buditanrim.co

Continue reading
Newer post: Evolving Product Experience Principles at Bukalapak
Older post: Making a decision is hard, here's my rule of thumb

2022

Mar 05 Move to Substack, temporarily
Feb 28 Locks and keys
Feb 27 Learn from the bad design alternatives
Feb 23 Tying shoelaces while running
Feb 17 Problems are pathways
Feb 10 Persistence
Feb 09 Who's responsible?
Feb 07 Users vs. customers
Feb 06 How to design a listing page?
Feb 02 Fixated on the solution too soon
Jan 31 Good product designers vs. Great product designers
Jan 24 The problem with dot voting
Jan 21 Choosing your team's ideas with dot voting
Jan 19 Start a project with alignment
Jan 18 Aligning different people
Jan 16 Career discussion
Jan 12 Facilitation: Managing discussions
Jan 10 Facilitation: Overview
Jan 05 Designer maturity

2021

Dec 31 Build a habit, not plan
Dec 30 Find what excites you
Dec 29 Closing your 2021 chapter
Dec 27 Is interface design an art?
Dec 25 Hiding from the decision
Dec 15 The story in our head
Dec 12 Avoid pitching culture
Dec 09 Optimism is not enough
Dec 07 Optimist vs. complainer
Dec 01 Firefighting
Nov 28 Productive work vs. busywork
Nov 23 Leadership in the design system
Nov 08 No true Scotsman fallacy
Nov 06 Costly team celebration
Nov 03 Element of debates
Nov 01 Question the question
Oct 31 Discussion treemap
Oct 25 Carpenter toolbox
Oct 21 The questions from the candidate
Oct 18 Weekly goals...
Oct 12 Two things the team need to align
Oct 11 Cross-pollination
Oct 08 My view on design practice
Oct 04 Silent meeting
Oct 02 Triangulation
Sep 29 Groupthink
Sep 27 Before, during, after
Sep 21 Take a vacation to learn
Sep 14 LEGO Kits syndrome
Sep 02 Level 1 and level 2 decision
Aug 31 The alternative of hypothetical questions
Aug 24 End your meeting with reflection
Aug 18 We see what we want to see
Aug 14 Outcome-focused mindset
Aug 11 Hypothetical questions
Aug 09 A quick update and what's next
Aug 01 Silence is boring, but 50 million people would hope to hear silence
Jul 29 Asking questions
Jul 25 Inside out or outside in?
Jul 22 Poor thinkers vs. good thinkers
Jul 19 Ethical Design: Layer of consequences
Jul 16 Ethical Design: Profit over people?
Jul 13 Ethical Design: Harms of our work
Jul 07 3 questions to improve your interface design
Jul 06 Reflection questions I lately use
Jul 03 Accessibility: Irlen syndrome
Jun 30 Incomplete reality
Jun 29 Design system: Auditing color system
Jun 22 Puzzle vs. Problem
Jun 21 Side effects of A/B testing
Jun 19 Embracing inferiority
Jun 18 How to optimize apprenticeship?
Jun 15 Build alignment
Jun 14 How to choose a company?
Jun 09 Better product?
Jun 07 Different vs. weird
Jun 06 Falling seventeen times in an hour
Jun 02 Reflect: Learning through experience
Jun 01 The power of anti-goals
May 26 Lifelong learner
May 25 Learning over money
May 24 The reflection exercise during a pandemic
May 21 Constraint
May 19 Advocacy and inquiry
May 18 Resistance to new product
May 17 Balance
May 14 Skilled incompetence
May 12 Need and want
May 11 How to frame the design system rollout
May 10 Dancing with a stranger
May 07 Good decision
May 05 Confusing popularity and value
May 04 Objective, strategy, and tactic
May 03 Self-learning
May 01 Small actions for self-improvement
Apr 30 Slow thinker
Apr 28 Mindset in the new job
Apr 27 One-on-one guide for individual contributors
Apr 26 Team player
Apr 23 'It looks good to me'
Apr 21 Why do you work?
Apr 20 The Steve Jobs' Error
Apr 19 Design is like riding a bike
Apr 16 See your life as an experiment
Apr 14 Lead with respect
Apr 13 Lead with trust
Apr 12 My reflection on leadership
Apr 07 Five years from now
Apr 06 Design Thinking allergy
Apr 05 What should design managers do with OKR?
Apr 04 When was the last time you talked to users?
Apr 03 Three core questions for product team
Apr 01 Inspecting interface design — Exercise with heuristic
Mar 30 Inspecting interface design — HE vs. UT
Mar 29 Inspecting interface design — Overview
Mar 27 Modern product design principles for Millenials designers.
Mar 25 A confusing interface that creates fire.
Mar 23 If F1 drivers get a trophy, what's our trophy?
Mar 22 Getting it right for the first time
Mar 19 Use Peltzman effect to communicate risk
Mar 17 Be the best version of yourself
Mar 16 If you coach a designer, do you need to know all the answers?
Mar 13 Show up and practice
Mar 11 Reader question: How to deal with promotion rejection?
Mar 10 Reader question: How to measure success?
Mar 09 Product design leadership - Managing and leading
Mar 07 How to draw an owl
Mar 05 Product design leadership — Persevere
Mar 04 Product design leadership — Establish urgency
Mar 02 Product design leadership — Strategic focus
Mar 01 Product design leadership — Setting direction
Feb 26 On GUI history, learning, and writing.
Feb 25 Product design leadership — Create changes
Feb 24 Product Design Leadership series
Feb 22 Documenting is a good team’s habit
Feb 18 Have a hard time getting design feedback?
Feb 18 I'm writing a book.
Feb 16 A manager cried in front of me.
Feb 15 Should I move to the managerial role?
Feb 12 Friday diary 01: On personal development, being senior, and breaking small task.
Feb 11 Evangelizing the human-centered practice
Feb 09 Human-centered team vs. Feature-centered team – Strategic insight
Feb 08 Human-centered team vs. Feature-centered team – Strategic relationship
Feb 08 Human-centered team vs. Feature-centered team – Overview
Feb 05 Dealing with top down request
Feb 03 Every team has its unique challenges.
Feb 02 Business aware designer – Recognize your competitors
Jan 29 Business aware designer – Job to be done
Jan 27 Business aware designer – Value proposition
Jan 26 Business-aware designer - overview
Jan 25 What do product designers do?
Jan 22 Announcement for mentorship program
Jan 21 Community story: impostor syndrome
Jan 20 Should startups build a design system?
Jan 18 How I overcame my impostor syndrome
Jan 17 User metrics - Signals and Metrics
Jan 15 User metrics - Vision
Jan 14 User metrics - Overview
Jan 13 Give back to the community
Jan 12 4P: framework for choosing job
Jan 11 Take things with a grain of salt
Jan 09 Principles of good portfolio design
Jan 07 An effective product design portfolio – Constraint
Jan 06 An effective product design portfolio – Structure
Jan 05 Connect user and business with AARRR framework
Jan 05 My blog in 2021
Jan 03 Should I build the feature request from customers?

2020

Dec 30 Feature requests are stupid business activity
Dec 21 The benefit of creating a design portfolio
Nov 24 About self-doubt
Nov 11 Don't confuse design with artifacts
Nov 06 What if you need to find another job tomorrow?
Oct 26 Making sense of your design project by writing
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

2019

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

2018

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 yellowstroke.com