How to give feedback to your designer that actually improves the work
Good design feedback names the problem, not the fix: say what's confusing or off-brand and why, then let the designer solve it. Vague notes like "make it pop" or "just doesn't feel right" send a project in circles. Specific, honest feedback, given early and often, is what actually moves work forward.
Why most founder feedback slows the project down
Most founders have never been trained to give design feedback. They know their product cold and they know when something feels off, but translating that instinct into words a designer can act on is a different skill. So the feedback comes out as a fix instead of a problem: "make the button bigger" instead of "I don't think people will notice this button." The designer implements the literal instruction, the underlying issue stays, and the project loops back around a week later with the same complaint in a different outfit.
This is rarely about taste. It's about information. A designer working from "make the button bigger" only has one lever to pull. A designer working from "I'm worried people won't notice this button" has ten, and can pick the one that actually solves it, whether that's size, color, position, or removing three other elements competing for attention.
Separate the problem from the solution
Before sending feedback, ask one question: am I describing what's wrong, or am I prescribing how to fix it? If it's a fix, back up a step.
Instead of "make the logo bigger," try "I don't think the brand feels present enough on this screen." Instead of "add more white space," try "this section feels cluttered next to how clean the rest of the site is." The designer you're paying for has spent more hours solving exactly this kind of problem than you have. Let them.
There's an exception. If you have a firm constraint, a legal requirement, a technical limitation, a decision already made with your team, say so directly and say why. That's not prescriptive feedback, that's a fact the designer needs to work within.
Be specific about what's wrong, not just that something is
"I don't love it" is feedback a designer can't use. It's honest, but it doesn't point anywhere. The fix is almost always to name what triggered the reaction: is it the color, the copy, the layout, the vibe against a competitor you respect, a specific screen versus the whole flow?
A useful trick: describe the reaction a user would have, not your own. "A new visitor landing here for the first time won't know what this product does in five seconds" is more actionable than "this doesn't feel finished." One is a design problem the designer can trace to a specific fix. The other is a mood.
Batch it, don't drip it
Sending three Slack messages over two days with three separate reactions to the same screen is worse than one message with three points, even if the total feedback is identical. Drip feedback makes a designer redo work twice: once for message one, again for message two, layering changes on changes instead of solving the whole picture at once.
If you're reviewing a link, sit with it for fifteen minutes before responding. Write everything down, then send it as one pass. This alone cuts most feedback cycles by a full round.
Say what's working, not just what isn't
Founders default to flagging problems and staying quiet on what's right, on the assumption that no news means approval. It doesn't. A designer refining a direction needs to know which parts to protect as much as which parts to change, or the next round can quietly undo something that was already correct. A short "the hero section is exactly right, don't touch it" saves more time than it costs to type.
Put it in writing, even after a call
A live call is often the fastest way to talk through a direction, tone of voice comes through, follow-up questions get answered on the spot, and nothing gets lost in translation. But calls also evaporate. Ten minutes after hanging up, both sides remember the conversation slightly differently, and the designer is left reconstructing notes from memory.
Follow every call with a short written summary of what was agreed, even five bullet points in Slack. It forces you to confirm you actually reached a decision rather than just a good conversation, and it gives the designer something to point back to if a later round of feedback contradicts an earlier one. This single habit prevents more rework than almost any other change to how founders communicate with the people building for them.
Match your feedback style to how you actually work together
Some founders want to review every screen before it ships. Others want the studio to run with a direction and only step in when something's off. Neither is wrong, but feedback that doesn't match the working style creates friction either way: heavy, detailed notes on a project where the designer expected trust and speed, or silence and long gaps on a project that needed a founder in the loop weekly.
We build this flexibility into how we run engagements at Artone. Some clients hand us one task at a time and want a clear timeline before the next one starts. Others want us to take the initiative, build the task structure ourselves, and lead the direction with a weekly standup. Both work. What doesn't work is a founder pretending to be hands-off while quietly expecting hands-on scrutiny, or the reverse. Naming your style up front, even in one sentence, saves both sides a few rounds of guessing.
If you're mid-project right now and the feedback loop already feels stuck, that's usually a sign of a mismatch between how you're giving notes and how the work is structured around them, not a sign the designer is wrong for the job. Worth talking through on a quick call before it costs another sprint.
Trust the "why," push back on the "what"
The healthiest version of a founder-designer relationship isn't one where the founder approves everything or one where the designer never gets challenged. It's one where the founder pushes hard on whether a decision serves the business and trusts the designer on how to execute it. "I'm not sure this direction reflects how serious our product is" is a legitimate, useful challenge. "Move this three pixels to the left" almost never is, unless you're the one who's spent years staring at exactly that kind of detail.
If you're still deciding how much weight to put on this relationship in the first place, does design even matter for a startup is worth reading first. But once you've decided it matters, the return on that investment comes down almost entirely to the quality of the back-and-forth, not just the initial brief.
The short version
Name the problem, not the fix. Be specific about what's wrong. Send one batched pass instead of a drip. Say what's working, not only what isn't. And match your feedback rhythm to how the engagement is actually structured, task-based or proactive, weekly check-ins or async. Founders who do this consistently get better work, faster, from any designer they hire, in-house, freelance, or a studio like ours.
If you want a second pair of eyes on how your current feedback loop is working, or you're about to start a new engagement and want to set it up right from the first brief, book a call and we'll walk through it together.


