One topic that’s been top of mind for me recently is design feedback. Working in an environment where the core of our process is having daily internal meetings every morning (where we review progress from the day before and give each other feedback on what is working and what could be improved), knowing how to deliver feedback is as important as knowing what feedback to deliver.
I have written about it recently, here:
The feedback you choose not to give is as important as the one you do
The other aspect that keeps going through my head in each of those review sessions is the level of feedback that will be the most helpful for the team: from more prescriptive to more strategic.
It’s a fine balance.
As a designer with more experience than others in the room, it is easier for you to visualize a few potential ways to solve that design challenge. On the other hand, you want to make sure the designers who are actually working on that challenge on a daily basis feel like they own what the final solution is.
Many times, out of instinct and without considering the implications of giving tactical feedback, I have resorted to telling other designers exactly how I think certain screen should look and behave.
“You should use a dropdown instead. When users click, the UI expands to show a list of other locations; when they click again, the page refreshes to show the location they selected.”
I am not proud of that.
Tactical feedback can not only limit how innovative and exciting certain solution is, but can undermine the team’s confidence in coming up with solutions on their own.
Designers who are a little more senior naturally understand that the solution presented is just one of the many ways that challenge can be solved — and know how to use that suggestion as a starting point to collectively think about new ideas that are even stronger and more interesting than the original one. But younger designers might run the risk of simply following that suggestion literally: they do it either because they can’t think of another solution on the spot, or because they care too much about titles (“well, if the design director is telling me this is the solution I should use, I better use it”).
Over the years I have developed this quick mental framework to try to force myself away from feedback that is too tactical and prescriptive:
1. Remind them of what that page is trying to achieve (user goals)
Start your sentences reminding the other designers of the goal of that page, screen, or feature — phrasing it from the user’s perspective. This is a good reminder that you and your team should always be putting user needs before anything else.
“The goal of this Location Finder page is really to get users to select one of our locations as quickly as possible, so they can see the space and make a decision. We don’t want people to spend too much time searching.”
2. Explain the why (business goals and KPIs)
Follow with a reminder of how a successful experience on that page will help the business and meet the overall project goals.
“Getting people out of the Location Finder and into a Location Detail Page will allow us to communicate location-specific selling points more effectively and more accurately — and increase the chances of users signing up.”
3. Give the team some initial ideas without being prescriptive
This is an important step to get the team unstuck, and to show them that meeting both user need and business goal is not an impossible task. If you’re giving feedback on the initial solutions they have tried, coming up with new solutions on their own might be more challenging than it was in the first round. Don’t be too prescriptive; phrase your own solutions as quick suggestions that will require further analysis and exploration.
“There is probably a number of things we can try to achieve those goals: maybe it is a dropdown where you can see the full location list, but maybe there is also a map on the right column. I also like how [insert brand here] solves for a similar challenge: they let users easily toggle between list and map.”
4. Encourage the team to figure out the “how”
The final solution will rarely come from a design feedback meeting. After ideas (the “what”) are discussed, the team has to actually sit down and invest time exploring and refining the execution (the “how”). It is important that designers have the final say on how something will look, move, and behave. At the end of the feedback, make sure to give them the encouragement they need to go out and refine the solution.
“Next step is for you all to try to make this work. It is not an easy challenge, but refining the ideas we talked about today will be really important to deliver the best-in-class experience we want to provide to our users.”
5. Make yourself available
Some ideas work really well in theory, but are harder to pull off once you start actually designing the interface. Being available to sit down next to your team and work through solutions side-by-side has numerous benefits: it will help them move faster, it will avoid designers spinning their wheels heading in the wrong direction, it will show how accessible you are, and it will help you and your designers connect at a deeper level — through the one passion you share in common.
What are some of the techniques you use to give your peers feedback without being too prescriptive?
This story is part of Journey: learnings from the amazing ride of being a designer.
Top comments (1)
That's it's a great article, I like the part where you provide some feedback on initial ideas.
Which the designer create their own building on top of yours as a point of reference.