Asynchronous Design Critique: Giving Feedback

One of the most powerful gentle abilities we have at our disposal is the ability to work together to improve our designs while developing our own abilities and perspectives, regardless of how it is used or what it might be called.

Feedback is also one of the most underestimated equipment, and generally by assuming that we’re now great at it, we settle, forgetting that it’s a skill that can be trained, grown, and improved. Bad comments can lead to conflict in projects, lower confidence, and long-term, undermine trust and teamwork. Quality opinions can be a revolutionary force.

Practicing our knowledge is absolutely a good way to enhance, but the learning gets yet faster when it’s paired with a good base that programs and focuses the exercise. What are some fundamental components of providing effective opinions? And how can input be changed for workplaces where workers are located and distributed?

On the web, we may discover a long history of sequential suggestions: from the early weeks of open source, script was shared and discussed on email addresses. Designers and sprint masters discuss ideas on tickets, designers make comments in their favourite design tools, and so on.

Design analysis is frequently referred to as a form of collaborative feedback that is used to improve our work. So it shares a lot of the rules with comments in public, but it also has some variations.

The information

The material of the feedback serves as the foundation for all effective critiques, so we need to start there. There are many versions that you can use to design your content. This one from Lara Hogan is the one I privately like best because it’s simple and actionable.

This calculation, which is typically used to provide feedback to users, even fits really well in a design critique because it finally addresses one of the main issues that we address: What? Where? Why? How? Imagine that you’re giving some comments about some pattern function that spans several screens, like an onboard movement: there are some pages shown, a stream blueprint, and an outline of the decisions made. You notice anything that needs to be improved. You’ll have a psychological model that will enable you to get more accurate and effective if you keep in mind the three components of the equation.

Here is a reply that could be given as a part of some comments, and it might seem reasonable at a first glimpse: it seems to casually serve the elements in the equation. But does it exist?

Not sure about the hierarchy and styles of the buttons; it seems off. Can you change them?

Finding a perspective that is as specific as possible when conducting design feedback refers to more than just pointing out which area of the interface. Do you offer the user’s viewpoint? Your expert perspective? from a business perspective? The perspective of the project manager A first-time user’s perspective?

I anticipate one to go forward and the other to go back when I see these two buttons.

The why is the focus. Just pointing out a UI element might sometimes be enough if the issue may be obvious, but more often than not, you should add an explanation of what you’re pointing out.

I anticipate one to go forward and the other to go back when I see these two buttons. But this is the only screen where this happens, as before we just used a single button and an “×” to close. This seems to be breaking the consistency in the flow.

By provoking the designer’s critical thinking while receiving the feedback, the question approach is intended to provide open guidance. Notably, Lara’s equation includes a second approach: request, which instead provides instructions on how to find a particular solution. While that’s a viable option for feedback in general, for design critiques, in my experience, defaulting to the question approach usually reaches the best solutions because designers are generally more comfortable in being given an open space to explore.

For the question approach, consider the difference between the two:

I anticipate one to go forward and the other to go back when I see these two buttons. But this is the only screen where this happens, as before we just used a single button and an “×” to close. This seems to be breaking the consistency in the flow. Would it make sense to unify them?

Or, for the request approach:

I anticipate one to go forward and the other to go back when I see these two buttons. But this is the only screen where this happens, as before we just used a single button and an “×” to close. This seems to be breaking the consistency in the flow. Let’s make sure that all screens have the same pair of forward and back buttons.

In some situations, adding an additional reason why you think the suggestion is better might be helpful at this point.

I anticipate one to go forward and the other to go back when I see these two buttons. But this is the only screen where this happens, as before we just used a single button and an “×” to close. This seems to be breaking the consistency in the flow. Let’s make sure that all screens have the same two forward and back buttons so that users don’t get confused.

Choosing between the request and question approaches can occasionally be influenced by one’s personal preferences. I did rounds of anonymous feedback and reviewed feedback with other people before putting a lot of effort into improving it a while ago. After a few rounds of this work and a year later, I got a positive response: my feedback came across as effective and grounded. until I switched teams. Surprise surprise, one particular person gave me a lot of negative feedback. The reason is that I had previously tried not to be prescriptive in my advice—because the people who I was previously working with preferred the open-ended question format over the request style of suggestions. However, there was a person in this other team who had always preferred specific guidance. So I modified my feedback to include requests.

One comment that I heard come up a few times is that this kind of feedback is quite long, and it doesn’t seem very efficient. No, but also yes. Let’s look at both sides.

No, this style of feedback is actually efficient because the length here is a byproduct of clarity, and spending time giving this kind of feedback can provide exactly enough information for a good fix. Additionally, it can reduce misunderstandings and back-and-forth conversations in the future, boosting overall collaboration’s effectiveness and efficiency beyond the single comment. Consider the example above where the feedback would be simply” Let’s make sure that all screens have the same two forward and back buttons.” The designer receiving this feedback wouldn’t have much to go by, so they might just apply the change. The interface might change in later iterations or they might add new features, and perhaps that change no longer makes sense. The designer might assume that the change is about consistency without the explanation, but what if it wasn’t? So there could now be an underlying concern that changing the buttons would be perceived as a regression.

Yes, this type of feedback is not always effective because some comments don’t always need to be thorough, some times because some changes may be obvious ( the font used doesn’t follow our guidelines ), and others because the team may have a lot of internal knowledge, making some of the whys may be implied.

The equation above is not intended to provide a predetermined template for feedback, but rather a mnemonic to reflect and enhance the practice. Even after years of active work on my critiques, I still from time to time go back to this formula and reflect on whether what I just wrote is effective.

The tone

The foundation of feedback is well-rounded content, but that’s not really enough. The soft skills of the person who’s providing the critique can multiply the likelihood that the feedback will be well received and understood. It has been demonstrated that only positive feedback can lead to sustained change in people. It can be determined by tone alone whether content is rejected or welcomed.

Tone is crucial to work on because our goal is to be understood and create a positive working environment. Over the years, I’ve tried to summarize the required soft skills in a formula that mirrors the one for content: the receptivity equation.

Respectful feedback comes across as logical, solid, and constructive. It’s the kind of feedback that, regardless of whether it’s positive or negative, is thought to be useful and fair.

Timing refers to when the feedback happens. When given at the wrong time, to-the-point feedback has little chance of receiving favorable reception. When a new feature’s entire high-level information architecture is about to go on sale, it might still be relevant if the questioning raises a significant blocker that no one saw, but those concerns are much more likely to have to wait for a later revision. So in general, attune your feedback to the stage of the project. Iteration in the early stages? Iteration that was later? Polishing work in progress? Each of these has unique needs. The ideal setting will increase the likelihood that your feedback will be appreciated.

Attitude is the equivalent of intent, and in the context of person-to-person feedback, it can be referred to as radical candor. Before writing, it’s important to make sure the person we’re writing will actually benefit them and improve the overall project. Sometimes it might be difficult to reflect on this because we might not want to admit that we don’t really appreciate that person. Hopefully that’s not the case, but that can happen, and that’s okay. How would I write if I really cared about them, aside from acknowledging and having that to help you make up for it? How can I stop acting aggressively? How can I be more constructive?

Form is important especially in diverse and cross-cultural workplaces because having excellent writing, perfect timing, and the right attitude might not be effective if the writing style leads to miscommunications. There could be many reasons for this, including the fact that occasionally certain words may cause specific reactions, that nonnative speakers may not be able to comprehend all thenuances of some sentences, that our brains may be different and that our world may be perceived differently; hence, neurodiversity must be taken into account. Whatever the reason, it’s important to review not just what we write but how.

I asked for some feedback on how I gave it a while back. I was given some sound advice, but I also got a surprise comment. They pointed out that when I wrote” Oh, ]… ]”, I made them feel stupid. That’s not what I meant to say! I just realized that I had been giving them feedback for months and that I had always made them feel foolish. I was horrified … but also thankful. I quickly changed my spelling mistake by adding “oh” to my list of replaced words (your choice between aText, TextExpander, or others ) so that when I typed “oh,” it was immediately deleted.

Something to keep in mind because it’s quite common, especially in teams with a strong group spirit, is that people frequently beat around the bush. It’s important to remember here that a positive attitude doesn’t mean going light on the feedback—it just means that even when you provide hard, difficult, or challenging feedback, you do so in a way that’s respectful and constructive. You can help someone grow the best way you can.

Giving feedback in written form can be reviewed by someone else who isn’t directly involved, which can help to reduce or eliminate any bias that might exist. I found that the best, most insightful moments for me have happened when I’ve shared a comment and I’ve asked someone who I highly trusted,” How does this sound”?,” How can I do it better”, and even” How would you have written it” ?—and I’ve learned a lot by seeing the two versions side by side.

The format

Asynchronous feedback also has a significant inherent benefit: it allows us to spend more time making sure that the suggestions ‘ clarity and actionability meet two main objectives.

Let’s imagine that someone shared a design iteration for a project. You are commenting on it while reviewing it. There are many ways to accomplish this, and context is of course important, but let’s try to think about some things that might be worthwhile to take into account.

In terms of clarity, start by grounding the critique that you’re about to give by providing context. This includes specifically describing where you’re coming from: do you have a thorough understanding of the project, or is this your first encounter with it? Do you have a high-level perspective, or are you just learning the details? Are there regressions? Which user’s point of view are you addressing when offering feedback? Is the design iteration at the point where it would be acceptable to ship this, or are there important issues that need to be addressed first?

Providing context is helpful even if you’re sharing feedback within a team that already has some information on the project. And context is absolutely necessary when providing cross-team feedback. If I were to review a design that might be directly connected to my work, and if I had no idea how the project might have come to that conclusion, I would say so, highlighting my opinion as external.

We often focus on the negatives, trying to outline all the things that could be done better. That’s obviously important, but it’s even more crucial to concentrate on the positives, especially if you saw improvement in the previous iteration. Although this may seem superfluous, it’s important to keep in mind that design is a field with hundreds of possible solutions to each problem. So pointing out that the design solution that was chosen is good and explaining why it’s good has two major benefits: it confirms that the approach taken was solid, and it helps to ground your negative feedback. Sharing positive feedback can help prevent regressions in things that are going well because those things will have been deemed significant in the long run. Positive feedback can also help, as an added bonus, prevent impostor syndrome.

There’s one powerful approach that combines both context and a focus on the positives: frame how the design is better than the status quo ( compared to a previous iteration, competitors, or benchmarks ) and why, and then on that foundation, you can add what could be improved. There is a significant difference between a critique of a design that is already in good shape and one that isn’t quite there yet.

Depersonalizing the feedback is another way to make it better: it should always be about the work and never the creator. It’s” This button isn’t well aligned” versus” You haven’t aligned this button well”. Just before sending, review your writing to make changes to this.

One of the best ways to assist the designer who is reading through your feedback in terms of actionability is to divide it into bullet points or paragraphs, which are simpler to review and analyze one by one. For longer pieces of feedback, you might also consider splitting it into sections or even across multiple comments. Of course, it’s also possible to include screenshots or indicators for the specific area of the interface you’re referring to.

Emojis have been a method I’ve personally used to enhance the bullet points in some situations. So a red square � � means that it’s something that I consider blocking, a yellow diamond � � is something that I can be convinced otherwise, but it seems to me that it should be changed, and a green circle � � is a detailed, positive confirmation. A blue spiral is also used for either something I’m uncertain about, an exploration, an open alternative, or just a note. However, I’d only use this strategy on teams where I’ve already established a high level of trust because it might turn out to be quite demoralizing if I deliver a lot of red squares and change how I communicate that.

Let’s see how this would work by reusing the example that we used earlier as the first bullet point in this list:

🔶 Navigation—I anticipate one to go forward and the other to go back when I see these two buttons. But this is the only screen where this happens, as before we just used a single button and an “×” to close. This seems to be breaking the consistency in the flow. Let’s make sure that all screens have the same two forward and back buttons so that users don’t get confused.
Overall, I believe the page is strong, and this is a good candidate for a version 1. 1.0 release.
� � Metrics—Good improvement in the buttons on the metrics area, the improved contrast and new focus style make them more accessible.
Button Style: Using the green accent in this context, which conveys a positive action because green is typically seen as a confirmation color. Do we need to look for a different shade?
🔶Tiles—Given the number of items on the page, and the overall page hierarchy, it seems to me that the tiles shouldn’t be using the Subtitle 1 style but the Subtitle 2 style. This will maintain consistency in the visual hierarchy.
Background: Using a light texture is effective, but I’m not sure if doing so will cause too much noise on this kind of page. What is the thinking in using that?

What about using Figma or another design tool that enables in-place feedback to provide feedback directly? These are generally difficult to use because they conceal discussions and are harder to follow, but they can be very useful in the right context. Just make sure that each of the comments is separate so that it’s easier to match each discussion to a single task, similar to the idea of splitting mentioned above.

Say the obvious, please. Sometimes we might feel good or bad about something, so we don’t say it. Or sometimes we might have a doubt that we don’t express because the question might sound stupid. Say it, that’s fine. Don’t hold it back, though, because you might need to change the phrasing a little to make the reader feel more at ease. Good feedback is transparent, even when it may be obvious.

Another benefit of asynchronous feedback is that written feedback automatically monitors decisions. Why did we do this, especially in large projects? could be a question that pops up from time to time, and there’s nothing better than open, transparent discussions that can be reviewed at any time. For this reason, I suggest using software to save these discussions without keeping them hidden until they are resolved.

Content, tone, and format. Each one of these subjects provides a useful model, but working to improve eight areas—observation, impact, question, timing, attitude, form, clarity, and actionability—is a lot of work to put in all at once. One effective way to approach them is to start with the area you lack the most, either from your point of view or from feedback from others, first. Then the second, followed by the third, and so on. At first you’ll have to put in extra time for every piece of feedback that you give, but after a while, it’ll become second nature, and your impact on the work will multiply.

Thanks to Mike Shelton and Brie Anne Demkiw for their contributions to the initial draft of this article.