Designers Love Feedback!

Well... it depends on the feedback. If it's constructive, specific, and focused on helping improve the design, it's incredibly valuable. But what should the feedback look like then? In this post, I will examine both designer's and reviewer's perspective. So let's dive in!

First Rule: Feedback Is a Gift

The first and probably most important lesson I learned as a receiver of the feedback that I have to take it is a gift. Every comment represents an opportunity to learn something. The earlier feedback arrives, the better. A critique during exploration is much cheaper than discovering problems after development has started.

For designer, it's completely normal to have mixed feeling at first during feedback sessions. With practice, however, you become more confident in your design decisions and more objective when evaluating feedback.

Method WHAT – WHY – HOW

One of the biggest mistakes in design critiques is jumping straight into solutions. Try to explain the problem first.

Structure your feedback into:

1. WHAT (The item you are giving feedback on)

2. WHY (Why it is creating a problem)

3. Optional: HOW (Discuss a possible solution — "how might we improve it?")

For example: "The onboarding flow feels difficult to scan (what) because all sections have the same visual weight and nothing guides me toward the next step (why). You might explore stronger hierarchy or visual grouping (how)."

Notice how this approach leaves room for the designer to find the best solution.

Many experts recommend stopping after the "why" and allowing the designer to explore solutions independently. Instead of prescribing a solution, try asking a question, for example:

"I'm feeling a little confused because I expected to find account settings here, but I don't immediately see them. What do you think?"

Then stay silent so you give the designer time to think. Those few seconds may seem easy to incorporate, but in reality they often require practice.

Balance Positive and Constructive Feedback

Feedback should be balanced. If something works well, say it. For example:

"I really like how you simplified the setup process. The progress indicator makes it easier to understand where I am in the journey.

The second step feels a little unclear (what) because I can't immediately tell which fields are required and which are optional (why)."

Positive feedback helps designers identify what should stay. At the same time, avoid giving only positive feedback, because constructive feedback is what helps move the design forward.

Three Types of Feedback

I've found it helpful to sort feedback in three categories:

1. Direction

This type of feedback is quite common and provides enough context to suggest a direction. Examples:

"This padding feels off. I’d recommend reducing it to 16px to better align with the rest of the layout."

"The primary button doesn’t stand out enough. Increasing its contrast could help make the main action clearer."

2. Simple Feedback

Simple feedback identifies a problem but leaves the solution open. Example:

"I’m not sure why this option is disabled here, or what I need to do to enable it."

3. Thoughts

Thoughts are observations that may inspire future improvements but don't necessarily require action. Example:

"This interaction pattern feels similar to what I’ve seen in [.....]."

If you are a reviewer, before you speak, try to take a moment to consider which type of feedback you're about to give. It helps make feedback more focused and reduces the risk of creating confusion or unnecessary stress for the designer.

If you are a designer who got this feedback, sorting it into one of these categories helps you to understand what to do with it.

Structure for Running Design Critiques

Prepare Introduction

A designer should introduce the topic with:

• Who are we designing for? (e.g. first‑time users, power users, administrators)

• What problem are we solving? What business goals are we supporting? (e.g. reduce drop‑off in onboarding, increase feature adoption)

• What stage of the design process are we in? (e.g. early exploration, low‑fidelity, high‑fidelity, or near‑final)

• What specific feedback are you looking for? (e.g. information hierarchy, interaction flow, copy clarity, accessibility)

Prepare for "Why"

One tip I'd like to share: before the review starts, try to predict the questions that might come your way and write down your answers. You will be surprised that this exercise not only improves your communicating skills, but often helps you to discover your own mistakes before anyone else does.

Great framework for these (from Tom Greever's Articulating Design Decisions) is:

"To address [user need],

I've decided to [design solution].

I considered [alternative solution],

but it didn't support the user's needs as effectively because [reason]."

Share Designs in Advance

Whenever possible, send designs beforehand. This allows participants to review the work before and come prepared with thoughtful questions. It also makes the session more efficient and inclusive.

Running Design Critique

1. Introduce the Context

Start with a brief overview of the user, the problem you’re solving, and the goals you’re trying to achieve. I also like reminding new participants: "Your feedback is valuable regardless of your role or seniority. There are no right or wrong answers."

2. Present the Design

Walk through the flow and explain your reasoning. Instead of simply showing screens, explain decisions. For example: "To help users understand their progress, I introduced a stepper navigation." Or: "To reduce cognitive load, I grouped these actions together." And, avoid jargon where possible! A simple rule is: If I can't explain it to a friend in five minutes, I probably don't understand it well enough myself.

3. Gather Feedback

Reviewers take turns sharing observations. Designers should focus on active listening and clarifying questions, not being defensive :).

4. Wrap Up

Before ending the session, summarize key feedback and clarify next steps. One surprisingly common mistake is running out of time and skipping this step entirely.

Don't Forget Asynchronous Feedback

Not every critique needs a meeting. When designs live in tools like Figma or Lovable, where comments can be left directly on specific elements, asynchronous feedback is often a great option. It’s usually much more efficient for iteration, especially in agile teams. Having a clear deadline helps avoid endless review cycles, co you can tell your teammates for example:

"Please add comments by Wednesday so I can consolidate all feedback before moving into the next iteration."

I especially like asynchronous feedback because:

• It's more inclusive

• It gives people time to think

• Introverts often contribute more

• Feedback is documented automatically

• Distributed teams can participate

After the Feedback Session

As I mentioned before, the critique isn’t finished when the meeting ends. Make sure to clearly communicate the next steps to participants. This builds trust and shows that their feedback was heard and considered. A common mistake is collecting feedback and then disappearing. If the session marks an important milestone or there was a large amount of reviewers and comments, it can be helpful to cluster similar feedback and analyze it together, much like you would do after a research session.

Final Thoughts

So, if you managed to read until here, you might be looking forward to your next feedback session a bit more! Thank you for reading my post and stay tuned for the next one...