At some point or another you'll be asked to review someone else's work, but there are some key differences between giving strategic level advice versus prescriptive design feedback.
I recently came across this short article by Fabricio Teixeira on that specific topic which covered some simple ways to ensure we're all encouraging ourselves to consider how we give feedback and how it might be received - after all, you don’t want to get asked for it once, but then never again due to a hasty or an aggressively-perceived approach.
It doesn’t matter what you intended, what matters is how the audience felt.
Fabricio’s article is worth the read, even leaving this blog right this second to go read that first… I’ll wait… as he describes what you can state to build the context for your feedback, and then how to phrase it. The following key questions rang true in my head around what to think about when reviewing and enquiring with design teams or any team for that matter (haha because I ran over the character limit on my other channels when trying to share this article so I had to reformat it for here instead haha):
What is actually needed for each step of the activity/journey and does this cover it too little or even too much? (i.e. What is the user/customer/audience trying to accomplish here and is this helping or hindering?)
How will the business, stakeholders, and users/customers be positively (or negatively) impacted by this?
How might I comment on this or provide suggestions whilst fostering and maintaining a strong working relationship so that the teams themselves can remain creatively in control and confident about their work?
Overall, basically everything we produce is directly or indirectly designed in some way - it might be a UI, but it also might be a research survey or a communications email to customers or even an internal slide presentation to a leadership team - and the same feedback principles generally apply.
For example, maybe you’re tapped on the shoulder by a colleague to read over a business case email they want to send to their manager or it’s a slide pack they have to present next week. You can still structure your feedback using the same types of design intent questions you might ask when reviewing an app, website, feature, etc:
What is it we want the user/audience to take away from this or be able to decide/accomplish as a result?
Is each page or element strongly contributing to task success or helping to tell a cohesive story?
What are some ways this could possibly be better and why should or shouldn't we consider them?
What does the team think about the problem before I tell them my idea and how do I phrase it so they're open to hearing it? Is it the right time or place? Are they asking for simple things like grammar/design checks or, instead, advice on the purpose and nature of the entire piece?
So, in reflection of Fabricio’s suggestions and these example above, what are some of your hot takes on giving good design feedback?