Giving better design feedback
From a young age we’re told not to complain about something unless we have a solution, not to disparage someone else’s idea unless we have a better one. While sometimes this may be good advice, I’ve noticed that this mantra has frustratingly slipped into our thinking when it comes to design feedback. It may not come as a conscious, fully formed thought however many people seem to have an ingrained and wholly incorrect belief that in order to criticise a design direction, one must also suggest an alternative.
This misconception often manifests itself as a statement like “I’m not sure that button is working, have you tried purple instead?” or even worse, “I think that button should be purple instead”. This feedback is a missed opportunity for a coherent exploration of design directions and it often leaves the feedback-recipient feeling misunderstood. It also creates an A vs. B mentality when it comes to product decisions, its the old idea verse the new one with little room for further discussion. Lets unpack what the feedback “I think that button should be purple instead” is really saying:
- I can’t see that button very well and I think that other people may also struggle to see it
- I assume this button is a primary action and thus you want users to quickly and easily identify it
- Therefore not being able to find the button quickly is an issue in the design
- I think one of the ways this button’s visibility could be increased is through increasing the color contrast between the background and and button
- Given the current background color, I think making the button purple could achieve this increased contrast
By breaking this down it becomes immediately apparent that a) there are a lot of assumptions being made in that feedback about what the problem is and b) there are a lot of other ways that problem could be fixed and changing the button colour to purple is just one of many options.
The seminal problem with this feedback is that it jumps past all of the formative steps and offers only a final solution without any of the context that gives this solution meaning or value. Without a why behind the feedback it becomes impossible to debate or improve upon and we’re left with the A vs. B mentality I mentioned earlier. Chances are that making the button purple isn’t actually the best change that the designer could make to this interface. Maybe purple isn’t part of the established colour palette and the confusion caused by breaking the visual consistency would negate any benefits of a salient button or maybe the button wasn’t even supposed to be the primary action in the first place! Given the current exchange the designer may hear the feedback, realise its not the best idea for any number of reasons, throw out the suggestion and then be none-the-wiser as to how their design could be improved.
What can we do differently?
From the feedback-recipient’s perspective its important to recognise when you get feedback that is actually an observation, assumption and suggestion all packaged into one statement. When this happens, rather than dismissing the feedback for the bad design suggestion it probably is, unravel the feedback-giver’s thought process by asking them “why”.
- Why do you think the button would be better off purple? “Oh, it would make it easier to see!”
- Why do you think it needs to be easier to see? “Well I can see it now, but it’s getting lost amongst the other elements, I can’t spot it at a glance”
- Why do you think its important that people see this at a glance? and so on.
By doing this you will get a far greater depth of design feedback and, as most good design feedback does, you will hopefully end up discussing the goals of the design and whether or not the current design is meeting those goals in the most effective way possible. Once you begin to talk on those terms, you will receive a wealth of helpful, interesting and actionable feedback. Going back to the button example, as a result of the feedback you might realise that you first need to answer what do users come to this page to do? and is that intention reflected in the primary actions of this page? and finally is the primary action of the page the most visually salient element? This is obviously far more helpful than “I think that button should be purple instead”.
From a feedback-givers perspective first and foremost we must learn to untangling our ability to identify problems with our propensity to see their potential solutions and we should become very comfortable saying “I think x, y and z but I don’t know what the solution might be”.
We must also learn to ask questions before we give advice. Ask for clarification of what the design goals are, what the purpose of that button is, ask why the designer chose to give that button a color identical to the background colour. It is only after you get an understanding of these things that you can begin to speculate what the problems might be, and then what the solutions may be. For the sake of the feedback-receiver, this train of thought should also be articulated. Before you give any kind of solution, make sure that you’re identifying a real problem. In actually stating “I can’t see that button very well, and I think that other people might also struggle to see it too” you and the designer get the chance to discuss together if the visibility even is a problem.
When being introduced to a new idea to give feedback on whether it be in the form of a mockup, a new product direction or a a new design process its vital we learn how to start with questions and then to break up our thinking into its individual assumptions and hypotheses. This doesn’t always come naturally and at first may be a very deliberate process but it will soon become second nature to question and explore a problem before “solving” it. Useful feedback isn’t a solution to a problem, rather it successfully explores, builds upon and challenges ideas and hypotheses. The identification of issues can indeed become the starting point for to brainstorm of directions or forms a possible solution could take but notably, useful feedback or indeed any design critique does not need to include a solution to be valuable.
