How to Get Feedback on Your Designs

You can have the strongest design in the room and still walk out of the review with feedback that sends you in circles. The difference is rarely the work itself. It is how you present it.

Creating your first Figma file and getting comfortable in the tool is only half the job. The other half is presenting that work clearly enough that the people in the room can give you feedback worth acting on. Done well, a feedback session compresses weeks of guesswork into a single conversation. Done badly, it produces a pile of contradictory opinions that leave you more stuck than when you started.

This guide walks through the exact approach I use at DoxAI to present design work and pull out feedback that actually moves a project towards the finish line. If you want the upstream half of this, how to design faster in Figma covers the habits that get you to a presentable file in the first place.

---

The 7 habits of a good feedback session

Before the detail, here is the whole loop in one glance:

• Lead with context so people understand what they are looking at
• Read the room and tailor what you ask for to who is in it
• Set clear expectations for what you will cover and what you need
• Pause for questions so early confusion does not snowball
• Repeat to confirm that you heard each point correctly
• Get feedback from everyone, then filter for what is useful later
• Be the driver and own the direction of the conversation

Run that loop a few times and the quality of the feedback you get climbs noticeably.

---

1. Lead with context

The goal of any feedback session is to give people enough background to understand what they are looking at, so the feedback you get back is useful instead of generic. If the room has no context for the project, start there. The trick is balance: give enough to orient everyone, but not so much that you bury the work under twenty minutes of preamble.

Before you show a single screen, cover:

• The name of the project and who it is for
• The problem you are solving
• The constraints you are working within
• The specific feedback you are after
• The parts you are not looking for feedback on yet

That last point matters more than people expect. Telling the room what is out of scope saves you from a stream of comments on things you have not touched yet.

Try this script:

Hey all, right now I am focused on [project name], which helps [target users] solve [the problem]. I am at the [stage of design] stage, and I am looking for feedback on [the challenge you are facing].

A real example from my work:

Hey team, I am working on updates to the DoxAI landing page case study. We need to avoid using real brand names because of the privacy commitments we have with our clients, so I am at the high fidelity stage and unsure about the logos in the thumbnail. Do they resemble the originals closely enough without copying them?

Framing the work this way hands your audience a lens to look through and relieves them of the burden of figuring it out for themselves. It is completely fine to flag the challenges you are facing and the areas where you have made assumptions. The point of the session is to improve work that is still in progress using the collective knowledge of the team, not to defend something finished.

---

2. Read the room

Every person in the room is different and brings a different taste and a different set of priorities. Taking a moment to understand who you are presenting to, and what they care about, pays off every time. The more you know about your audience, the more precisely you can ask for what you need.

Two questions are worth answering before you present:

• How much does this person know about the design process?
• Do they have the authority to make decisions, or do they report to someone who does?

The answers change what you ask for. If I am presenting to a group of designers, I will ask for feedback on specific interactions or design patterns. If I am sharing the same work with a product manager, an engineer, or a C-level stakeholder, I switch: I ask about the overall flow, implementation challenges, and legal or business implications, not whether I should reduce the spacing by 8 pixels.

This is the same muscle you build when you plan and prepare for a design project properly. Knowing who the real decision-makers are before the work starts saves you from designing for the wrong audience.

---

3. Set clear expectations

Good feedback comes down to reducing the mental effort it takes for your audience to understand what they are looking at, so they can spend their attention on what actually matters. Tell them what you are about to cover and what you need from them before you dive in.

If you are about to walk through a set of screens, say so up front. A simple "I am going to show you three onboarding screens, and I want to know if the flow feels obvious" gives everyone a job. Without that, half the room is still working out what they are supposed to be looking at while you are three screens deep.

---

4. Pause for questions

When we see something for the first time, we tend to have basic questions that need answering before we can absorb what comes next. If those questions go unasked, everything you say afterwards lands on shaky ground.

As the person presenting, build in moments to invite questions between your talking points. It keeps the room engaged and stops anyone from quietly checking out.

Try this script:

Next I am going to cover the onboarding flow. Before I get into the details, do you have any quick questions or comments?

---

5. Repeat to confirm

Repeating a question or comment back before you answer it is a simple way to confirm you have understood it the way it was intended. It also gives the other person a chance to correct themselves if the point did not come out the way they meant it.

Try this script:

If I understood that correctly, you are asking [their question]. Is that right?

It takes five seconds and saves you from solving the wrong problem for the next twenty minutes.

---

6. Get feedback from everyone, filter later

The art of gathering feedback is making sure everyone shares their point of view once you have finished presenting a screen or a flow. Collect widely first, then filter for what is useful afterwards. Trying to judge feedback in real time, while you are still presenting, is how good ideas get dismissed too early.

If a few people are dominating the conversation, finding a way to bring in the quieter voices can change the outcome of the whole session. Some people do not want to speak up straight away; they would rather hear what others think first. Simply naming that and inviting them in is often enough.

Try this script:

Thanks for that, [name]. Given your experience designing for mobile, [quieter person's name], is there anything you would add before I move on to the next phase?

Putting someone gently in the spotlight nudges them to share the thought they were sitting on.

---

7. Be the driver

When you are the one gathering feedback, you own the conversation. That is a position of control, not a passive one. You decide which questions to ask to really understand someone's point of view, when a topic is worth digging into, and when to note it and move on.

Try this script:

I really like how you put that, [name]. I will make a note of it. I would love to spend a little more time on [the challenge you are facing].

Driving the session well is the difference between leaving with a clear list of next steps and leaving with a vague sense that people "had thoughts". The feedback you gather here feeds straight into the next loop of the UX design process, where you turn it into the next round of designs.

---

Common mistakes that sink a design review

Even with the loop above, a few habits quietly undermine the feedback you get:

• Showing finished-looking work when you wanted structural feedback. Polish signals "done", and people critique done work less honestly. Present at the fidelity that matches the feedback you are after.
• Asking "what do you think?" Open-ended questions get open-ended, useless answers. Ask for something specific instead.
• Defending every comment. You are there to collect, not to win. Note it, thank them, and move on.
• Letting the loudest voice set the agenda. The most senior or most talkative person in the room is not always the most right.
• Forgetting to close the loop. Tell people later what you did with their feedback. It is the cheapest way to make them give you better feedback next time.

---

Bringing it together

Great design feedback is not luck, and it is not about having the most talented people in the room. It is a process: lead with context, read the room, set expectations, pause for questions, confirm what you heard, gather from everyone, and drive the conversation. Run that loop a few times and you will watch the quality of the feedback climb, along with the speed at which you move from a rough file to a shipped product.

If you are building a product and want a designer who runs this process for you, I take on a small number of engagements each month. You can book a free consultation and we can talk through what you are building.

---

About the Author

Sanjay Tarani is the Head of Design at DoxAI, helping entrepreneurs and business owners build scalable, user-focused digital products. Sanjay has led design system initiatives behind 50+ successful projects and has been recognised with the Website Wizard award. Sanjay brings experience from high-growth startup environments, including learning within the Startmate ecosystem, and shares practical insights on design, product strategy, and building profitable apps. Connect with Sanjay on LinkedIn.