Key takeaways
- Feedback depends on who gives it. Designers, users, managers, developers and family see different parts of the project.
- A complaint is a signal, not a solution. I look for the real problem behind the words.
- Emotion and information are two different things. I keep the information and leave the mood.
- Something good first, then one specific point. This is how I give feedback on a design.
- The work is not the person. In both directions, feedback talks about the design, never about who made it.
How to interpret design feedback: start from who is speaking
Every person looks at a project from a different place, and most of the time they see only a small part of it. This is normal, but it changes a lot the meaning of what they say, and it is the first thing I keep in mind when I interpret design feedback.
| Who | What they can see | How I read their feedback |
|---|---|---|
| 📐 Fellow designers | The design itself, with the same language I use | Close to how I think about the work, often precise |
| 👀 Users | What they live while using the product, not how it is built | A real experience, even when the cause they imagine is wrong |
| 🫰 Marketing and project managers | The project from another angle, with the team goals in mind | Often a feeling that I need to translate |
| 👵🏻 Family and friends | No context at all | Fresh eyes: what a new person notices first |
Interpret design feedback from users: a complaint is a signal
Let me make a simple example. A user tells me that the app is slow when they do a certain action, without knowing that behind that action there is a process that is technically quite complex.
I could answer “It’s complicated, that’s why”, but this doesn’t help anybody. The frustration of the user is real, and maybe it shows a general slowness in some processes of the app. For me, to interpret design feedback from users means to listen to what they feel, more than to the cause they imagine. So, if on the technical side we cannot do much, the question becomes: what can we do on the design side to show that the app is not blocked, but that it is thinking and working for them?
From a feeling to a design question
Other times the feedback is not about the design, but about a sensation. A project manager can tell me that something “doesn’t feel right” without being able to explain what. For me this is a starting point, and it is my job as a designer to interpret this design feedback and translate it into something concrete. Here are some examples of how I do it:
| What they say | What it can mean | The question I ask |
|---|---|---|
| “The app is slow.” | A process takes too long, or feels too long. | Where does the user wait, and what do they see while waiting? |
| “It doesn’t feel right.” | The hierarchy, the spacing or the tone is off. | Which moment feels wrong, and compared to what? |
| “I don’t like the colors.” | It can be taste, or a contrast and readability problem. | What were you trying to read or find? |
Interpret design feedback without the emotion
Feedback very often arrives together with an emotion: someone is annoyed, worried or excited, and you can feel it in the way they talk. I think the role of the designer, in these moments, is to take a step back and interpret the design feedback for the information it contains, because a comment said with a strong tone is not more true, and a comment said calmly is not less important.
The work is not the person
When someone tells you “this design doesn’t work”, it is easy to hear “you are not good at your job”. But the feedback is saying that the design is not in line with some expectations, not that the person who made it is not good. The Interaction Design Foundation says the same thing: a design critique should be about the design solutions, not about the designers. When I keep this line clear, I listen better and I improve the work faster.
How I give constructive design feedback
When I give feedback, I often use a technique that I learned from my American colleagues in Paris: I start with one good thing about the work, and only after I give my feedback on the point that, for me, does not work.
For example: “I really like how you set up the widgets and how you structured the design system. However, I expected that a widget this important would take a bit more space, and respect the white space a bit more.”
In my experience, when the critique comes after something positive and stays on one specific point, there is a better chance that the other person thinks about the solution with you, instead of defending the design.
A real case: a difficult one-to-one at a hackathon
Giving feedback on a design is one thing, but giving feedback to a person about the way they work is much harder.
During one of the hackathons at Campus Fonderie de l’Image, I was the project leader of my group, and one person was not really contributing to the work. I decided to talk with him one to one, not in front of the group, because I didn’t want him to feel exposed. First I thanked him for the small part he had done, then I explained that the rest of the team was putting a lot of effort into the project and I asked him if he could align with this effort, to balance the workload. I told him that if there was any problem we could talk about it, and I also pointed out the facts: he arrived late, and one thing he said he would do was not done at all.
What changed after? I want to be honest: not much. He completed one part I had asked for, and then nothing more. Maybe you cannot change a person with one feedback, but as the project manager of the group it was my responsibility to at least try, and for me it was also a good training.
What I would do differently
Give the feedback even when it feels basic. Sometimes I am worried that my comment is too simple, but a feedback also works as a question. If I ask “Why did you do it this way?”, the designer can explain the reason to me, and in this way I understand the project better and I see if my comment still makes sense.
Restart from the context. When someone with little knowledge of my project gives me feedback, I want to first ask them “What do you know about this part?”, and explain from the point where their knowledge ends. In this way I can interpret their design feedback correctly, and very often, after this exchange, I can say: “Ah, you mean this. You are right.”
How I collect design feedback on my own work
I also try to apply all this to myself. On my portfolio I added a leave a feedback page, connected directly to Notion: I receive a notification in real time, and an automatic system sorts every feedback into my tasks. In this way a feedback doesn’t stay forgotten in an inbox, but it becomes something I can plan and work on.
Conclusion
For me, to interpret design feedback is to treat it as a raw material. Before I act on it, I ask who is speaking, what they can see, and what is the information under the emotion. When I give it, I start with something good and stay on one point. And in both directions, the feedback is about the work, not about the person.
In Part 2, I will share my critique process step by step. In the meantime, you can read how I measure the results of a design change in Metrics That Matter: How I Measure the Success of a Redesign, or how I use AI in my workflow in AI as a First Draft, Not a Final Answer.
Want to see how I work?
Visit my portfolio to see my projects, or contact me on LinkedIn to talk about a role. And if you have a feedback on this article, the “Leave a feedback” page is there for you.
