Posting a logo to a forum and asking "what do you think?" reliably gets you one of two useless replies: "looks good!" or "I don't love it," neither of which tells you what to change. Getting feedback that's actually usable, on a logo, a page design, or a full site, comes down to two things: where you ask, and how you ask. Get either one wrong and you'll collect opinions without collecting anything you can act on.
Where to actually ask
| Source | Best for | Watch out for |
|---|---|---|
| Design-focused communities (Designer Hangout, niche subreddits, Discord servers for your craft) | Peers who understand design vocabulary and won't just react on taste | Feedback skews toward what other designers would do, not what your actual audience responds to |
| Your actual target audience (a survey, a handful of DMs, a small paid panel) | Whether the design communicates what it's supposed to, to the people it's for | Non-designers often can't articulate why something feels off, so you have to ask the right questions (see below) |
| A hired critique (a freelance designer or consultant, paid by the hour) | Depth, someone who'll actually explain the reasoning, not just react | Costs money; worth it for a logo or brand mark you'll live with for years, less so for a one-off social graphic |
| Your own team or client, on the live page | Feedback tied to the real context, real device, real surrounding content | A screenshot or exported PNG strips that context out, the same design can read differently once it's actually on the page |
None of these fully replace the others. A logo benefits from a hired critique because it's a long-lived, high-stakes asset. A page layout benefits more from your actual audience and your own team looking at the live, working version, because a static export of a design file never quite matches how it behaves once it's real.
Why "what do you think?" doesn't work
The question itself is the problem before anyone even answers it. "What do you think?" invites a gut reaction, and gut reactions are almost always about taste ("I like blue," "not my style") rather than function (does the logo work at 16px in a browser tab, does the headline communicate what the product does in the first two seconds). Most people asked an open-ended question default to the easiest possible answer, positive or negative, because articulating why something works takes more effort than reacting to it.
We cover this exact pattern from the website side, the difference between a vague comment and one that's actually fixable, in website feedback examples, and the underlying shape is identical whether the thing being reviewed is a logo, a page, or a full brand system: specificity is the entire difference between feedback that gets acted on and feedback that gets acknowledged and ignored.
Questions that actually produce useful answers
Instead of "what do you think," ask questions with a narrower, more answerable shape:
- "What does this look like it's for, before you know anything else?" Tests whether the design communicates its category correctly, a fintech logo that reads as a kids' toy brand has a real problem, independent of whether anyone "likes" it.
- "Would you recognize this at a glance if you saw it small, on a phone, in a tab?" Most logo and icon failures show up at small sizes, not the large presentation view most feedback happens on.
- "What's the first thing your eye goes to?" If the answer isn't the thing you intended to be the focal point, that's a specific, fixable hierarchy problem, not a taste opinion.
- "Does anything here feel hard to read or unclear, and where specifically?" Forces a location, which is the difference between "the page feels cluttered" and "the pricing table's third column is unreadable," a comparison we go deeper on in website design feedback.
- "If you had to change one thing, what would it be?" Limits the response to something prioritized and specific rather than an unstructured list of every small preference.
Notice the shape all five share: each one has a single, checkable answer, not an open invitation to react. That's the actual mechanism behind why they work better than "what do you think," a narrower question structurally can't be answered with an unqualified "looks good" or "not sure," it forces the reviewer to notice and describe one specific thing. You don't need all five for every review, three or four asked in sequence, after someone's had a minute to actually look, usually surfaces more than a single open-ended prompt would in five times the time.
It's worth sending these in writing rather than asking out loud in a meeting, too. A reviewer put on the spot verbally tends to default to the quick, safe "looks good" answer just to keep things moving, while the same person given a written prompt and a minute to actually look tends to notice more and hedge less.
A ten-minute structured critique format
If you're running a critique with a small group rather than collecting async replies, a light structure gets you far more than an open "let's discuss." Borrowed from how design teams run internal crits, this fits in ten minutes per piece:
- Silent look (1 min). Everyone studies the design without talking. This prevents the first person's reaction from anchoring the room, the single biggest distorter of group feedback.
- State the goal (1 min). The presenter says what the design is trying to do and who it's for, once, so critique targets the goal instead of personal taste.
- Observations, not fixes (4 min). Reviewers describe what they notice ("my eye goes to the tagline before the logo") rather than prescribing solutions ("make the logo bigger"). Observations are data; premature fixes skip the diagnosis.
- Prioritized asks (3 min). Each reviewer names the one change they'd make first. Forcing a single top priority surfaces what actually matters instead of a flat list of every minor preference.
- Presenter recaps (1 min). The presenter says back what they heard, so misread feedback gets caught in the room, not three revisions later.
The "observations, not fixes" rule is the one worth enforcing hardest. A room full of prescribed solutions ("bigger," "bluer," "move it left") gives a designer contradictory orders; a room full of observations ("it reads as playful," "the CTA is easy to miss") gives them a diagnosis they can actually solve for.
Reviewing a logo vs reviewing a live page
A logo is usually reviewed as a static export, PNG or SVG, at a handful of sizes. That's appropriate for a logo, since it needs to hold up as a standalone mark independent of any one context. A page design is a different problem: reviewing it as a static screenshot or a Figma export strips out everything that makes a real page a real page, actual load behavior, actual responsive breakpoints, actual surrounding content and spacing. Feedback given on a static export of a page design routinely misses things that only show up once it's live, a button that looks fine in the mockup but sits at an awkward width against real body copy, for instance.
If what you're getting feedback on is a page or a full site rather than a standalone mark, the more useful move is getting reviewers to look at the actual rendered page, not an export of it, and to leave comments pinned to the specific element they mean rather than a general note. How to collect feedback on a website covers the methods for doing that in more depth, forms, widgets, and pinned visual comments compared directly.
Turning "I don't love it" into something usable
When you do get a vague reaction, the fastest recovery is a single, targeted follow-up rather than restating the same open question: "What specifically feels off, is it the color, the shape, the type, or something else?" narrows the response enough that most people can actually answer it. If someone says "it feels off" and nothing more, that's a signal the format of the ask needs to change, not that the design is necessarily wrong, some people simply won't self-prompt toward specifics without being asked directly.
Where Shotline fits
For a logo review, none of this changes, gather a small panel, ask the narrower questions above, and weigh a paid critique for anything you'll use long-term. For feedback on an actual page or site, the format matters more than the questions: a comment pinned directly to the live element it's about, with the viewport and context attached, structurally can't be as vague as a reply in a group chat or an email thread, because the location is already attached before anyone writes a word. Shotline lets anyone review a real, live page and drop feedback exactly where the issue is, no install for the person leaving the comment, no screenshot to interpret after the fact.
Shotline is free to try for 14 days, no card required, then from $19/mo (billed annually; $25 month-to-month). See the fuller comparison of feedback methods on the Shotline homepage, or read the best website feedback tools if you're evaluating options for an ongoing review process rather than a one-off design.
