Asynchronous Design Critique: Giving Feedback

One of the most successful soft knowledge we have at our disposal is the ability to work together to improve our patterns while developing our own abilities and opinions, in whatever form it takes, and whatever it may 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 feedback can cause conflict in jobs, lower motivation, and negatively impact faith and teamwork over the long term. A revolutionary force may be quality feedback.

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 suggestions be changed for isolated and distributed workplaces?

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. Developers and sprint masters discuss draw requests, designers make comments on their favourite design tools, and other things.

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 content of the feedback serves as the foundation for every effective analysis, 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 personally like best because it’s obvious 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 flow blueprint, and an outline of the decisions made. You notice something that needs to be improved. You’ll have a mental model that can help you be more precise and effective if you keep the three components of the equation in mind.

Here is a comment that could be given as a part of some feedback, and it might look reasonable at a first glance: it seems to superficially fulfill 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?

Observation for design feedback also refers to providing a perspective that is as specific as possible, not just by pointing out which portion of the interface your feedback refers to. 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?

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

Impact is about the why. 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.

When I see these two buttons, I anticipate one to go forward and the other to go back. 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.

The question approach is intended to give open guidance by encouraging the designer to think critically while receiving the feedback. 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, the difference between the two can be demonstrated as an illustration:

When I see these two buttons, I anticipate one to go forward and the other to go back. 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:

When I see these two buttons, I anticipate one to go forward and the other to go back. 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.

When I see these two buttons, I anticipate one to go forward and the other to go back. 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 a matter of personal preference. 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. Quite unexpected, my next round of criticism from one particular person wasn’t very positive. 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 member of this other team who preferred specific guidance. So I changed my feedback so that it included 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. Yes, but no. 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, if we zoom out, it may lessen 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 new features might be introduced, and perhaps the change won’t make sense anymore. 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 atmosphere

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 to have 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 is viewed as useful and fair, regardless of whether it’s positive or negative.

Timing refers to when the feedback happens. If given at the wrong time, to-the-point feedback has little chance of being well received. If a new feature’s entire high-level information architecture is about to go live when it’s about to be released, it might still be relevant if that 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 morning? Iteration later? Polishing work in progress? Each of these has unique needs. Your feedback will be received favorably if the right timing is chosen.

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.

A few years ago, I asked for some feedback on how I respond. 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 recently realized that I had been giving them months of feedback without ever feeling stupid. I was horrified … but also thankful. I quickly changed the way I typed “oh” into my list of replaced words (your choice between aText, TextExpander, or others ), so that it was instantly deleted when I typed “oh.”

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. The best thing you can do for someone is to encourage their growth.

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. Let’s try to think about some factors that might be helpful to consider, as there are many ways to accomplish this, and context is of course a factor.

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 know the project well, or do you just see it for the first time? 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 your feedback? Is the design iteration at a point where it would be acceptable to ship this, or are there significant 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 a must when providing cross-team feedback. If I were to review a design that might be directly connected to my work, I would say that, underlining my opinion as external, and if I had no idea how the project came to that conclusion.

We often focus on the negatives, trying to outline all the things that could be done better. That is obviously important, but focusing on the positives, especially if you saw improvement in the previous iteration, is even more crucial. Although this may seem superfluous, it’s important to keep in mind that design is a field with hundreds of possible solutions for 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”. This can be changed in your writing very quickly by reviewing it just before sending.

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 easier 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 exploration, open alternatives, or just a note when I’m not sure what to make. 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 I’d have to reframe how I’d 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—When I see these two buttons, I anticipate one to go forward and the other to go back. 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 our version 1. 1.0 release candidate.
� � 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 that it is a positive action because green is typically seen as a confirmation color. Should we look for a different color?
🔶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.

One last word: avoid the obvious. 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. You might have to reword it 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 are all there. 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 way to take them one by one is to first identify the area you most need from both your own perspective and feedback from others. Then the third, 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 initial review of this article.