What to do when people in your team say “I have no feedback” in a design critique session

Question

I started doing design critiques with my team of developers (I am the only designer within my team) to get feedback from them as early as possible and all along the process. I am really trying to engage them as much as possible by making design critique sessions more interactive. But often the main outcome of the session is “I have no feedback”, not really challenging for me. But the real problem is that issues and opportunities arise later in the process when the design has already been validated by the client and users. Some of those problems could have been seen earlier. Why is this happening? Do you have some advice for me?

Answer 1

Engineers tend to assess design solutions from the perspective of whether the product can be built or not based on project, technology and team constrains and what future work they will be performing so as to not get any surprises.

Try the following:

Setting the right expectations
Maybe the engineers are going into the meeting with a "can this be built" lens rather than a "does this solution accomplish the goal of the project" lens.

Try communicating the rules and structure of the critique before the meeting for them to come in prepared. Post the rules in the meeting invite and in the room itself to reference during the meeting.

Safe environment
Emphasize the safety of giving feedback by stating it as such or showing lower fidelity work. People tend to give more feedback when the design is visibly a work in progress and not a final high fidelity iteration.

Common Goals
Throughout the discovery and during the design, share the goals, principles, personas and scenarios with all team members. Framing critique based on goals, principles, personas and scenarios focuses conversation in the product and not personal preferences.

Contextual Reasons
Who is in the room and your overall company culture matters. Usually, a hierarchical structure or someone trying to dominate a conversation will prevent junior members from sharing feedback. Sometimes too many non-familiar people in the room can also cause people to withdraw. There may be personal reasons too, like shyness or quietness. Consider one-on-one sessions after.

Also, you could meet dominating members before to collect their feedback first and hope that they don't be as vocal during the meeting. Furthermore, you can use their feedback to keep them accountable during the meeting.

Laddering
This is asking the five "why?"s technique. Simply put, it tries to dig into the reasons for a feedback and whether they are based on personal preference or project goals. It may come as too direct and confrontational, try to rephrase and ask in a way to invite more feedback.

Answer 2

If issues have arose in previous designs, it is best to perform a post mortem analysis to determine whether any involved parties had knowledge that could have prevented those issues, and then determine why they did not bring up those concerns. It is often the case that constraints are discovered as a project is being worked on, especially when there are more teams involved.

It could be that no one had foreseen the problems, or an organizational problem that no one had the incentive to produce a good product in a fast way. In the former case, maybe it is good to encourage participation in the form of questions which can be recommunicated to appropriate parties.

Answer 3

it's good to hear that you are putting in effort to gather as much feedback as possible on the designs at the beginning and also in the process. Good designs save time, cost and everyone's efforts in building products.

However, engineers do not do critic designs. They are trained to make things work, and not deciding the manner which things will work. As an analogy, architects and civil engineers co-exist in a construction project because architects set the direction of how the buildings should function and look like, and engineers follow the direction to make sure the buildings are built to specifications. You don't ask an engineer to critic on the architecture of the building. Instead, you consult other architects to check see the aesthetics, functionalities and usabilities of the building design.

If you are restricted to getting feedback on the designs from your team, perhaps due to project confidentiality, you may consider asking for design critics from the graphic designers, and/or front end UI developers in your team. They would have a better sense of what works well with users compared to backend developers (no offense intended). This is because graphic designers and UI developers need to work with the user in mind, as compared to the backend developers.

When presenting the user research, business goals and strategy to the team, you have to be as objective and as factual as possible. And lastly, if there is a disparity in job rank, e.g. if you are their project manager or supervisor, you may not participate in the design critic session and allow the team to submit their feedback anonymously, so as to get the most out of their ideas.

Hope this helps and good luck!

Answer 4

I believe either you have done a very good job or the stakeholders/team members doesn't actually know the design concepts/they are unable to empathize with users or don't able to understand users problems.

If second one is the case what you can do is for getting proper feedback, you can ask for critiques in any design community in which ever you're, every guy had different view of seeing things, they can give you a better feedback over your designs.

Answer 5

Firstly, how are you running the session? Are the users you are speaking to, the right ones? Just asking "what is your feedback" is too open and you need to be a more directive about how the design satisfy the pain point you are trying to resolve. Asking the user to complete tasks with a paper prototype is for more engaging and you're likely to get better feedback than speculative conversation.