How to Get Feedback from Clients on Designs

Your client sends you a screenshot with a red circle drawn in Paint. Below it: “looks off.”

That’s the whole ticket. No URL. No indication of which page, which viewport, or what interaction led to that screen. No clarification of what “off” means: color, spacing, font, the whole layout?

This is not an edge case. It’s Tuesday.

Most designers and freelance developers have a client feedback problem that has nothing to do with the client’s taste. It’s a tooling problem. When the only available feedback channel is email or Slack, clients give email-quality feedback. Vague, decontextualized, hard to act on.

The fix is structural: make the feedback channel require specificity. Here’s how to set that up.

Why client design feedback is almost always terrible

The standard client feedback workflow looks like this:

1. You send a Figma link or a staging URL over email
2. The client opens it on their phone (probably), has thoughts, closes it
3. Three days later you get an email: “I was looking at the dashboard and the sidebar color feels too dark. Also can we make it feel more modern?”

Problems with this:

• No visual reference. “The sidebar” could mean the left nav, the right panel, the collapsed state, or something they saw on mobile that doesn’t exist on desktop.
• No URL. You have no idea which page they were on or which state the app was in.
• No severity signal. Is “too dark” a blocker or a preference?
• No thread. The feedback lives in their email client. By the time you respond with a clarifying question and they respond back, a week has passed.

Voice notes are worse. “So I was looking at the… wait, let me get back to the page… OK yeah so the thing at the top, is that supposed to be there?” Zero timestamps. No way to know what “the thing at the top” is.

Screenshots pasted into iMessage are almost worse than no feedback at all. They arrive without URL, without description, without context about what interaction triggered that state. And they’re in iMessage, which is not your issue tracker.

The consistent pattern across all of these: the client describes their reaction to the screen without giving you the screen.

What structured feedback actually looks like

Structured design feedback has three parts, attached together:

1. A screenshot of the exact screen the client was looking at
2. An annotation marking the exact element they’re commenting on
3. A note explaining the comment, attached to that annotation

That’s it. When all three exist, you can open the issue and immediately see what the client saw, what they pointed at, and what they said about it. No follow-up questions needed in 90% of cases.

The workflow you’re aiming for:

Client sees something → clicks feedback button → draws on the screen 
→ types comment → submits → issue appears in your tracker with 
screenshot + annotation + note attached

Compare that to:

Client sees something → composes email → forgets key details → sends 
→ you read email → ask clarifying questions → wait 2 days → iterate

The first workflow takes the client about 45 seconds. The second takes 3 days and still often ends with you guessing.

Setting up Loupe for client projects

Here’s the setup depending on how you’re delivering work.

Option 1: Live web app or staging environment

If you’re building something clients can access in a browser (a SaaS product, a client portal, a staging environment), use the Loupe web SDK to add a floating feedback button directly to the app.

Install it once:

npm install @loupeink/web-sdk

Initialize it in your app entry point:

import { init } from '@loupeink/web-sdk';

init({
  apiKey: 'lp_your_project_api_key',
  buttonLabel: 'Leave feedback',
});

Your client sees a small button in the corner of every page. They click it, draw on the screen, type their comment, hit submit. The annotated screenshot lands in your Loupe project with the URL, viewport, and browser attached. No manual triage required.

For clients specifically, you might want to set the button label to something softer than “Report a bug”:

init({
  apiKey: 'lp_your_project_api_key',
  buttonLabel: 'Leave feedback',
  position: 'bottom-right',
  color: '#6366f1',
});

Clients don’t feel like they’re filing bug reports. They’re giving feedback. Same result, less friction.

Option 2: Sharing static designs or desktop apps

If you’re sharing a design file, a PDF mockup, or a build they’ve downloaded, use the Loupe desktop overlay. It floats above whatever is on screen and lets the client annotate directly on the design. Export goes to your Loupe project the same way.

Pushing feedback to Linear or GitHub

Client feedback that lives in Loupe but not in your actual issue tracker is feedback that gets missed. Wire the integration so every submission auto-creates an issue in the right place.

For Linear: go to your Loupe project settings and connect the Linear integration. Every annotated screenshot becomes a Linear issue with the image and comment attached. You triage from Linear, same as internal bugs.

For GitHub: the GitHub integration works the same way. Feedback from clients becomes a GitHub Issue with the annotated screenshot as the body image. Assign, label, close. Standard workflow, zero extra steps.

You only set this up once per project. After that, client feedback routes to the right place automatically.

Comparing feedback channels

Channel	Visual context	URL captured	Trackable	Setup for client
Email	None	No	No	None
Slack	Optional screenshot, no annotation	No	No	Needs account
Loupe web SDK	Annotated screenshot	Yes	Yes, auto-pushed	None (button in your app)
Loupe desktop	Annotated screenshot	Manual	Yes	Download app
Marker.io	Annotated screenshot	Yes	Yes	Browser extension

The Loupe web SDK wins on client setup friction. No extension to install, no account to create. The button is in your app and they can use it in under a minute. If you want to compare features more closely, see how Loupe stacks up against Marker.io.

The actual conversation shift

When clients know they can click a button and annotate directly, the feedback emails stop. Not because you asked them to stop. Because the button is faster than composing an email.

You still get feedback, often more of it, because the barrier is lower. But it arrives with context attached. “Make it pop” becomes a circle drawn around the hero headline with a note: “This font feels too light against the dark background. Can we try heavier weight or a lighter background?”

That’s a ticket you can close in 20 minutes. The email version of the same feedback takes two days to decode.

Set it up once per project. It changes how clients interact with your work.

---

Building something? Add the Loupe web SDK to your next staging build and share the feedback link with your client instead of a Figma URL.