UX designer communication ─ ─ how to digest design feedback?

What I mean by “design feedback” here, in my opinion, refers to the feedback that the program reviews and collects in the team before it is put into development.

I guess every designer probably loves and hates this “design feedback” — sometimes letting more people check together to make the solution better, but sometimes there are several rounds of feedback, except for Repeated changes are constant controversy, and even the entire program was overthrown.

So how do designers better digest design feedback? I usually guide myself in the following ways:

Feedback will be “target” or “means” to classify

I tried to divide the feedback into “ goals “ and “ means, “ because we often say: I want to design a menu, and I want to design a pop-up window … I know that these are all “means.” The “target” is often effective and can be out of the concrete solution — I think it can be called “demand”, for example: I want to make more tourists into registered users to bring the user’s growth, or I Let users know the latest version to enhance brand reputation …

When each requirement is transformed into a design, there are innumerable evolutions from “Goals” to “Means.” “Goals” are more rational, and “means” are more subjective. Among the many sites I read, I find that designers have too much idea of ​​colors, shades, fonts, etc., and more designers will either Too much attention to “means” ignores the goal, I think we must make it clear: a good design must be built on solid goals. Designers in the show before the program to introduce the background of the project and the process of early thinking process is very necessary.

Similarly, during feedback gathering, some of the feedbacks are for “goals” and others are for “means”. If the feedback is categorized in time, not only can a large amount of invalid communication be reduced, but also a good feedback can be found quickly Solution: If the feedback is about the difference between the means, you can compare or improve according to the target; if the feedback is about the target, then continue to analyze the target, and each target must be guided by the macro target.

Do not fall into the feedback of “examples”

When I was giving a speech, I often used the words “an example” to express my views, and the more I wanted to make it clear, the more specific the examples were.

But there is also a problem.

When the comment after the speech is over, everyone will be drawn to the example solution and then compare the alternatives or think of more temporary new solutions. Then the designers asked them one by one and questioned … All the details in the plan were compared and an endless debate began.

I think we should not immediately go to refute the examples. Instead, we should stand at another angle to help each other clarify their thinking and even follow each other’s ideas to describe and diverge until we can accurately locate the core ideas that each other would like to express. Reach a consensus with each other. Next, depending on the scenario, quickly determine whether this feedback deserves to be discussed further.

Any feedback needs to be carefully considered before adoption

I found a phenomenon, some designers will be used to thinking immediately how to modify the program, including myself. But many of those who come back are not the people who ask for it. They can not remember the goals behind quickly and accurately. Therefore, no matter what kind of feedback, should be considered carefully before adoption. So we should always remind ourselves that we have to design for the target user.

And my friend usually talks to me about such a problem — what should a designer do if he encounters a leader / boss?

This phenomenon is very common in China, I think because of the different perspectives. Designers generally look at the problem from a “user perspective” and the boss often thinks about the design in a “business perspective.” And I think, designers have to weigh between the two, and then give the right program. But this trade-off does not mean that designers must compromise on experience.

If the feedback from the leader / boss sounds subjective, think of it in combination with the previous two. Of course, this process is not easy, may rely on bottom-up communication, designers need to take the right time to provide timely feedback when others express their views.

Here’s a small picture to ridicule the issue between the leader and the designer

(Pictures will lead to eyes uncomfortable, please watch carefully)