Feedback can be hard to take, but practicing it often and early makes it an integral part of the process to get your team’s best work out the door.

Good designs get buy-in and feedback from your team and stakeholders throughout the design’s evolution. This means getting feedback early with your concepts, then later on the execution of that idea, and then finally on the nitty-gritty details before handoff.

Ever had an amazing design solution to a problem you’ve been tasked with, you have it all worked out and then you present it to someone else and it falls flat — really flat? What went wrong?

Feedback can be hard to take, but practicing it often and early makes it an integral part of the process to get your team’s best work out the door.

Here are some things to incorporate into your daily design practice to ensure quality feedback on your designs.

Set expectations

Setting expectations should be done for both the overall design project and during specific feedback requests.

Expectation setting for the design project should begin early in the process. Depending on your team’s structure this could be during project planning or at a project kick-off. Make sure to get this topic on your team’s agenda and lead the discussion on which design stages you’ll ask for feedback in. Agree on clear timelines on where design deliverables fit into the timeline of the project, and be clear on what you’ll deliver at those milestones.

When you’re asking for the design feedback, set expectations again by being explicit with your request — what type of feedback you need and when you need the feedback to be completed by. For example, “At this stage in the design process, does my solution make it easy for our customers to find what they need? Where do you see potential places for them to be confused?” (Also see the “Timing and methods” section below for more details on this.)

You’ll also need to set expectations with yourself, to know that you’ve set up your feedback request for success. Who are the decision makers on your project? If your team is not working with a RACI framework (or another variation) for the project, identify the people that you’ll need to obtain feedback and receive approval from.

Illustrate the context

Each time you ask for feedback, be sure to take some time in your design presentation to give the background and illustrate the context in which you made these design decisions. This helps to get everyone on the same page about the design’s intent and why the design you’re asking for feedback on looks the way it does.

This introduction to your design can also include feedback that you received in previous rounds of review that were incorporated into this version. If you weren’t able to include the feedback, illustrate the challenges you ran into with it and the objectives of the project that conflicted with that option.

The phrasing and section titles for this context setting can vary for your team and per project, but generally the start of each design review should include the following sections:

1. The problem statement. More widely this can also include the project goal.
2. Considerations and challenges. In your design solution, what parameters is the design working within for context and what challenges the design ran into.
3. Alternates or options that didn’t make the final design. Walking through why these weren’t included or aren’t the primary solution.
4. Show where their feedback was incorporated into the design, or, if it didn’t make sense, what you considered and why it didn’t make the cut.

Timing and methods

The timing of when you ask for design feedback and the method used can either help you to gather interesting insights or cause the feedback to be focused on the wrong places.

What to present and what to ask for feedback on depends on the level of design fidelity. You should solicit frequent and early feedback regardless of fidelity, however.

• User flows and wireframe concepts. Start with the problem statement, the flow of your solution and wireframe concepts and request feedback at this stage. The feedback you’ll be looking for at this stage should make sure your solution correctly solves the problem for your main user. It should also establish that the scope of what you’ve presented seems generally do-able in the time allotted.

If there’s significant feedback at this stage, present revised version(s) as needed until key approvals needed are obtained. No amount of color or fancy graphics will “fix” a poorly architected design in the future.

• Mid-fidelity designs. At this stage of your design, you’ll want to start blocking out draft text, graphics for proportions, and interactive elements to make sure the specificity of these elements doesn't necessitate major design updates.

Making changes becomes more difficult as the level of fidelity increases, so be doubly sure that everyone is on board with the design at this stage.

• High-fidelity designs. Designs at this stage should include exact copy, graphics and layouts. You may need to get feedback from different team members at this stage of the design such as content or copy editors. Be sure the key decision makers sign off for a final time before your hand-off, congrats!

The method in which you ask for feedback is extremely important. In early design phases, your work is best presented at meetings. This allows you to describe the project’s history and context and guide the conversation for obtaining feedback.

Not only does this prevent any rough sketches and concepts from being misunderstood, these meetings also play a larger role in the project in getting everyone on the same page.

In later design stages where concepts have already been agreed upon, asynchronous feedback can be used. This method of feedback works well for getting eyes on a few versions of a specific component or for copy edits.

The tools you ask for feedback in can make a significant difference in the quality of the feedback given. Where possible, do not send the feedback request via a tool that your team member has to learn first. Although that might be easiest for you, frustration around the tool may lead to poor quality or no feedback. Be sure there’s a low barrier way for the person giving the feedback to engage.

Think about how the design will be seen by the user — mobile, desktop, large scale, etc. Try to request feedback that displays your design in that format so the person giving the feedback is seeing it without having to make the mental leap themselves.

Summary

While getting feedback on your designs early and often may seem like a scary proposition to jump into, take small bites of what’s most applicable to your team’s current team dynamic and add it in. Keep doing it bit by bit.

In time you’ll be confident and well-polished in getting feedback on your designs and helping your team to prepare for and give constructive feedback in many other aspects as well.

Stay well and keep creating!