Don’t Ask for Feedback: Request Critique Based on Design Goals
Decision-making is an arduous task when it comes to design. As a field of study that blends science and art, it needs to be analyzed more based on visual appreciation criteria and evidence of personal preferences. I know. It is frustrating! That’s why a design review shouldn’t just be feedback left in your mailbox on a Friday night with urgent changes for the following Monday. Definitely not.
During my journey as a UX Designer, I was frustrated to be reminded of the phrase “The client is always right,” which advises that company regulations or procedures should never take precedence over the opinions and preferences of clients. But the clients of an agency, although they pay the bill, are not the end users. So that was not right.
Thus, I always asked those involved what the goal was for any new project. The answers were the same. “Design goal? Is that necessary?” That was the opportunity I had to show value in design.
I suggested we look at the problem to understand what we were trying to solve with design. I confess that the design goal definition took longer to elaborate than the first low-fidelity wireframes, but that was a good sign. Looking at the problem carefully before starting a project meant we were on the right track.
Find the problem to set realistic goals. Please ensure they are related to the findings in the UX research phase. Often, a detailed briefing can also help.
To simplify this explanation, I defined three perspectives for a helpful UX review: information, design, and technology.
Decision-making Framework
Here are some questions to start the discussion :
1. Information (Elements)
- Is the information properly presented?
- Have all the necessary features been properly included
- Is the content flow intuitive for the user to follow?
- Are there enough elements to allow the user to complete their intended goals?
- Are all the elements relevant and necessary?
2. Design (User Experience)
- Can users easily recognize the elements in the design?
- Is the design easy to figure out?
- Are the different parts of the design simple to understand?
- Are the components easy to understand?
- Can users predict what comes next?
3. Technical (Functionality)
- Do we have all the functionality required?
- Can the functionality be supported?
- Is the functionality achievable?
- Is the implementation feasible considering the timeframe?
- Can we make it happen based on what we have to work with?
The questions should help the stakeholders elaborate on the concept or prototype, always looking from the design goal’s perspective. Clinging to visual details without focusing on the plan can delay the project and create a Frankenstein.
Understand who the stakeholders are, what areas they are experts in and how they can help the project with their criticism.
Avoid individual feedback without interaction. Feedback is often based on likes and dislikes. Instead, create a workshop and encourage the stakeholders to define and review the best design concepts, always considering the whole project.
A Decision-making Workshop is an excellent exercise because it improves the work quality, opens new perspectives of seeing the same challenge from different standpoints, reduces the bias, and increases your chances of having a project in facts and not in tastes. In addition, it's possible to use collaborative tools in real-time, such as Miro or even the traditional paper and pen in face-to-face panels.
You can download my Decision-Making Framework template on Miro
Good arguments help us recognize complexity where we once saw simplicity. The ultimate purpose of debate is not to produce consensus. It's to promote critical thinking. — Adam Grant
Making rational decisions by fostering collaboration and reducing personal biases is achievable, but keep in mind that the client may be suitable as long as their opinions are constructive, bringing more value to the users and based on the design goals to be achieved.
