The feedback life cycle.
First comes work, then comes feedback, then comes…?
You get feedback every day of your life. You start getting feedback the first time you put your chubby toddler hands on a stove burner that hasn’t cooled down enough. Every time you step on a scale, you get feedback about how you’re doing on your fitness goals. When you try out that new pick-up line and spend the rest of the night drinking alone, that’s feedback.
Feedback is part of the human experience, but rather than feeling natural, getting feedback triggers our fight or flight instincts. (Sure, these are also part of human nature but not as helpful while you’re reviewing designs with a client as they are when you’re being chased by bears.)
When we present our work and start getting feedback on it—get questions we weren’t prepared for, hear that some things aren’t working as well as we thought, get suggestions of varying degrees of helpfulness—our animal nature kicks in. We either fight every comment tooth and nail like the client is trying to eat our young, or we play dead and acquiesce to every assertion or change request they make.
Getting feedback and responding to it are so tangled up that designers conflate them into one terrifying bear attack. Designers hear feedback and react to it immediately, first emotionally and then by either instinctively pushing back or rolling over. But there’s actually a whole life cycle to feedback, and it doesn’t have to have any bears at all.
When feedback comes in, you do have to respond to it, but responding to feedback is not the same as making changes—or even agreeing to make changes—to your design.
Think about how you respond to non-design feedback in your life. If you and your buddy are on a road trip and they tell you you missed your turn, that’s good feedback. But do you immediately bang a uey in the middle of traffic to catch your exit? Do you slam on the breaks and ream out your friend for backseat driving?
No! Maybe the next turn will get you where you’re going just fine. Maybe your friend is reading the map wrong, and you didn’t miss your turn at all.
On design projects, you are behind the wheel, and reacting to feedback without thinking can take you off course and lead to bloody wrecks.
Feedback is a tool for making decisions. You may decide to change your design after getting it, but feedback is not in and of itself a decision.
Listening to and working with feedback does not always require action. When it does, that action usually isn’t immediate, so stop jumping to agree or disagree with feedback as you soon as you receive it.
Feedback is a tool for making decisions. You may decide to change your design after getting it, but feedback is not in and of itself a decision.
Feedback goes through a whole life cycle that only just begins when we present our work.
The feedback life cycle actually begins before you make anything for review when you define the project’s goals. Good feedback is framed around the goals of the project. In this project life cycle, defining goals is the Big Bang. Nothing else is getting made without it.
As you work toward those goals, things really get rolling. The feedback starts as soon as you present your work (and sometimes during). Yes, you respond to feedback in the moment as we receive it, and that won’t change after reading this. What will change, hopefully is how you respond.
- You also get feedback asynchronously. You’ve presented your work, and the email with additional thoughts comes in from the client. You’re reviewing all of the feedback with your team. This is when you’ll move from receiving feedback to working with it.
- Yes, incorporating any design changes you decide on is part of working with feedback, but it follows receiving and evaluating it.
- The last phase of the cycle is when you close the loop with peers and clients. This is when you present back any decisions informed by the feedback for validation.
Understanding these phases and how to move your work through them will help take the existential dread out of getting feedback and help you make project decisions for the right reasons.
Receiving feedback
Responding to feedback makes a lot of folks nervous. You have no idea what’s going to come your way!
What if there’s more feedback than I expected? What if they have a “big idea” that would change the whole course of the project? What if they ask me how to address something I didn’t even think of?
You do have to be ready for all of those things and more. The nervousness doesn’t come from what might happen in the meeting or on the call, though. You can handle those things, right? With time.
The nervousness comes from the unfair expectation that you will handle those things in the meeting or on the call. It takes time to listen to, digest, and resolve feedback. Trying to do that all at once is an unrealistic goal. But your fight or flight instincts kick in and you feel like you have to do or say something in the moment.
The goal of feedback sessions is to receive the feedback. Now receiving feedback is an active process, there’s lots for you do during those meetings, but acting—or agreeing to act—on every piece of feedback isn’t helpful.
The goal of any feedback session is hearing the feedback, not deciding how to use it.
Maybe your ego is bruised and your reaction is emotional. Maybe addressing a piece of feedback comes with complex implications. Not giving yourself time to fully consider feedback will keep you from making the best decisions in your work.
So how do you actively participate in a review of your work as a feedback recipient?
Manage expectations
There are three major expectations you need to manage as people give you feedback, and they’re expectations we’ve already reset for ourselves today. The first is that everything will be decided by the end of the meeting. The second is that every piece of feedback will result in a change in the design. The third expectation is that both of those things will happen within the original timeline and budget.
You start setting these expectations at the beginning of the project when you establish your goals and a shared understanding of how feedback will be used to make decisions.
Then, you reinforce those expectations throughout the project as you set the stage for receiving feedback. When you introduce work for feedback, you should remind your audience of the goals of the work and the goals of the current round of feedback. As part of this, you also articulate the goal for the feedback session.
You will need to remind everyone of this throughout the conversation. Other people’s expectations are wild animals: you can train them, sure, but over time they’ll revert to their true nature, and they will bite you.
How you respond to feedback can either reinforce or undermine the expectations you set for feedback. Going too deep into a problem-solving brainstorm invites prescriptive feedback. And responding to feedback too quickly or too positively creates the impression that you’re agreeing with the feedback and any changes being suggested.
Remember this response for whenever the conversation veers to sharply into specifics over problem-solving:
The goal of this meeting is to hear your feedback on what’s working and what’s not. Addressing issues will happen after we’ve heard all your feedback and have had time to give it the consideration it deserves.
If problem-solving conversations start creeping toward the edge of your scoped timeline or budget, you might say:
That’s an interesting idea, let us think it over and look at how it might impact the rest of the project.
The fact that you got some feedback isn’t justification to be late, and scope shouldn’t be used to shut down important project conversations. However, when you’re discussing feedback for the first time, it’s important to focus your energy on what you know is addressable and also not write any checks in the room that are going to bounce as soon as the client’s off the line.
Acknowledge feedback
Instead of worrying about responding to every piece of feedback in the moment as a to-do item, start by just acknowledging it.
When someone gives you feedback, the first step is to thank them. Whether or not you agree with it or if it results in revision to the design, that person is sharing their time and expertise with you. That’s a huge contribution. And even feedback you don’t act on directly can inform the changes you do make.
Whether or not you agree with someone’s feedback or if it results in revision to the design, that person is sharing their time and expertise with you. That’s a huge contribution.
The next step is to repeat what you’ve heard in your own words. This demonstrates that you are, in fact, listening, and confirms that you’re understanding the feedback correctly.
One of the most frustrating experiences from the point of view of the feedback giver is not seeing it reflected in the design and feeling like they wasted their time. Acknowledging feedback is a great way to ensure they feel their input is valued.
Discuss feedback
If the feedback is minor and your understanding of it is solid, listening and repeating might be all the discussion you need; but most feedback warrants more investigation than we give it. We make a lot of assumptions when receiving feedback.
When we get feedback we assume:
- We understand what the feedback giver means.
- That they understand the full implication of their suggestions.
- That they understand the technical language they’re using and not incorrectly parroting something they’ve heard us say.
- That someone is speaking for everyone on their team.
- That they remember the countless decisions that have been made on the project until now and are intentionally changing course.
So while receiving feedback usually isn’t the right time to dive into solutions, there’s still plenty to discuss!
After acknowledging feedback, you’re free to ask for clarification, provide additional context, and even push back—especially if feedback is based on a misunderstanding or false information. This is all a part of your responsibility to get the feedback you need to do your work well.
If at any point you’re feeling pressure from other participants to make a decision before you’re ready, buy yourself time with:
You’ve given us a lot to consider. Let us keep thinking about this offline and come back to you when we come up with a solution or identify additional information we might need.
Document feedback
Of course, if you say you’re going to follow up on something later, you need to do it. To help with that, you should be documenting feedback as you discuss it. Even if the client owes you consolidated written feedback later, you don’t want to lose track of any ideas, information, or discussions shared live. And if later written feedback contradicts what you heard from them live, you will be able to reconcile the two pieces of feedback before they cause conflict.
These notes should be shared with participants afterwards, as well. Again, this will demonstrate your listening, provide a solid reference while looking at revisions, and provide a record of any decisions that do come out of the conversation.
Establish next steps
When you’re wrapping up a feedback session, end with next steps. Next steps might be:
- “Our team will discuss what we just heard and get you revisions.”
- Or “We will wait on making any changes until we get your consolidated feedback once you’ve shared with the rest of your team.”
When possible, it’s ideal to get all your feedback live. When folks are providing feedback offline, that’s when they’ll try to sneak in their political battles, or contradictory feedback, to trick you into doing their work. And then there’s the lag when you get offline feedback that doesn’t make sense and have to clarify it before you can do anything with it. A longer feedback session will be more efficient than weeks of tag over email or Slack.
No matter what your next step is, it should always have a date attached.
Working with feedback
Ok, so you’ve received feedback, either during a meeting or asynchronously. Now what? Now is the right time to make decisions with that feedback and act upon them.
Depending on the size of the team, the complexity of the deliverable being revised, and the scope of the feedback, this may be a quick solo exercise, but reviewing as a team is a great collaborative habit. It keeps everyone in the loop, even when they’re not the ones moving pixels; and when your team is on the same page, you’re able to support each other in the event that you do need to push back against feedback. Plus, team members can help spot things in the feedback you might miss and help check your ego if you find yourself getting a little defensive.
At Mule, we have a structure for these meetings to make them as productive as possible. We gather up all the feedback we have to work with and meet somewhere with a whiteboard—you can use your preferred whiteboard substitute. On that whiteboard—or what have you—we draw three columns:
Yes | ? | No
As you go through each piece of feedback, evaluate it. Is it good, useful feedback? Is it feasible? What other considerations does it need to be weighed against. Once you’ve spent some time with the feedback, you’re going to put it into one of the three columns. Or our imaginary fourth column: ignore.
In the “Yes” column, you’ll put every piece of feedback you agree with along with any actions it requires. If a client says the design needs to make more of an emotional appeal, and you agree, put it in the yes column. Note who is responsible for the work that will address that feedback and deadlines.
Collaboration doesn’t mean every team member needs to be a part of every step of the process. You can decide as a team that a change needs to be made, and then let individual team members or small teams execute on their own. Just make sure that whoever has an action item assigned to them is clear on what’s expected of them and has what they need to be successful.
Collaboration doesn’t mean every team member needs to be a part of every step of the process.
In the “Question Mark” column, put anything you need to go back to the client with before acting. Don’t understand a piece of written feedback? Question mark column. Need assets from the client to make a change? Question mark. Need to check with a technical partner about a change’s impact on cost before committing to it? Put it up there.
Also in the question mark column, put any questions the feedback giver had for you, who will answer them, and if the answers need to be provided before or after revisions are made.
The “No” column is where you will put anything you’re deciding not to incorporate into the design. If it’s out of scope or impossible, put it in no. If there’s a piece of prescriptive feedback you disagree with, put it in no. The most action you’re going to take on items in the no column, is providing a rationale to feedback giver about why you’re not reflecting that feedback directly in the design—even though you heard them, value their input, and thought about it long and hard.
In the ignore column, you can put most positive feedback, and anything that’s not good, useful feedback: venting, housekeeping notes, stream of consciousness processing of the design, and so on.
Closing the loop
By the time the team has sorted all of the feedback into the appropriate columns you’ve got a list of decisions and corresponding action items. Now you can start revising your design. You’re very skilled at that already, so let’s skip to closing the feedback loop.
To close the feedback loop properly requires re-presenting the work with the dual framing of how the feedback informed the revision and how the new-and-improved version of the design does an even better job solving the project’s goals.
Thanks to the exercise you did to help decide what to do with the feedback, when you present decisions back to the client, you’ve got a handy outline for everything you need to discuss: begin by highlighting the changes you made in response to their feedback that made it to the “Yes” column, then discuss anything still open in the question mark column, and touch briefly on anything that needs further explanation from the “no” column.
And with that, the feedback cycle begins anew (the feedback life cycle is a little bit like reincarnation), unless you just landed yourself sign-off. In which case, it’s time to celebrate a job well done.
Celebrate anyway because going through feedback cycles is hard work, and you’ve survived another day!
Deeper reading on design feedback
If you’re still not sure why you should care about feedback as a designer, read this:
When you’re ready to share your work for feedback, follow these guidelines to make sure you’re getting the feedback you need:
For more on what makes feedback good, read this:
