How to give good feedback as a client

One thing I've noticed over a decade of building websites for healthcare companies is that clients and the people they hire are both bad at feedback. Clients don't know how to give it. Developers and designers don't know how to ask for it. The result is the same on every project: a round of notes, a round of changes, a vague sense on both sides that the work is drifting away from what anyone wanted.

This post is for the marketing lead, communications director, or ops person who is the point of contact on a website project. Most of the examples are from site builds and content migrations, because that's what I do, but the idea applies to any creative or technical work you pay someone else to do.

What is client feedback?

Feedback is the set of notes you send back after reviewing a round of work. A staging link for the new homepage, a proposed content model for your Sanity CMS, a redesigned provider directory, a draft of the migration plan. You look at it, you have reactions, and you write them down so the person doing the work can act on them.

That's the whole thing. It sounds simple, and the mechanics are simple. Write every note for that round in one document, in one pass, and send it over. Don't drip comments across three Slack threads and an email. Don't send a note, wait a day, and send a contradictory one. One round, one document.

Feedback can be about the work itself or about the process. "The hero image on the cardiology page is the wrong one" is about the work. "I need the staging link at least two days before our review call" is about the process. Both are useful. Both belong in the same document.

Why does good feedback matter?

Because it is the only control you have over the outcome once the project starts.

Think about the last time you reviewed a page someone built for you. I'd guess it went something like this.

Developer: "Here's the staging link for the new services section. Let me know what you think."

You: "The layout feels off, the blue is wrong, and the form should be higher up. Can you fix those?"

Developer: "Sure."

Repeat for six weeks.

At the end of the project you're frustrated. You hired this person to solve a problem and you feel like you've spent the whole time telling them how to do it. They're frustrated too. They feel like a pair of hands. Neither of you wants to work together again, and the site is fine but not what either of you pictured.

The problem isn't the developer and it isn't you. It's that nobody involved knows the difference between two kinds of feedback, and everyone defaults to the wrong one.

What makes feedback good or bad?

Good feedback is descriptive. Bad feedback is prescriptive.

Prescriptive feedback tells someone what to do. Descriptive feedback tells someone what you're seeing, what's wrong with it, and why it matters. The first one gets you exactly what you asked for. The second one gets you what you actually need, which is usually better than what you would have asked for.

I'll take each in turn.

What does prescriptive feedback look like?

Prescriptive feedback is the default. It's what most clients send and what most developers and designers have been trained to expect. Here's what it looks like on a healthcare site project.

• "Make the 'Find a provider' button bigger."
• "Move the patient testimonials above the fold."
• "Change the headline font to something more modern."
• "Add a dropdown for locations in the nav."
• "Actually, take the dropdown out."
• "Make the hero image darker."

Sound familiar?

Every one of these is an instruction. You have a reason for each one. The button feels hard to find. The testimonials matter to you because referring physicians read them. The font reminds you of the old site you're trying to leave behind. But none of those reasons made it into the note. What arrived was a to-do list.

Why is prescriptive feedback the wrong approach?

Two reasons, and the first is that it wastes time. Yours and theirs.

Look at the list above and ask how any of those instructions connects to the goal of the project. You know why you want them. Your developer doesn't. They'll make the button bigger because you're the client and they don't want to argue. Then the bigger button crowds the phone number next to it, and the phone number was the thing 60 percent of your visitors actually use. Now there's a second round of notes to fix a problem the first round created. The project drifts away from the goal you started with, one reasonable-sounding instruction at a time.

The second reason is that it undervalues the person doing the work. You hired a developer who has built a dozen healthcare sites. They've seen how provider directories get used, where appointment request forms convert and where they don't, which consent banner patterns legal teams approve without a fight. Prescriptive feedback takes all of that experience and sets it aside. It tells them they're a tool. That's almost never the intent, but I can tell you from the receiving end that it's how it lands.

What does descriptive feedback look like?

Descriptive feedback describes the situation: what you're looking at, what's wrong with it, and why it matters. Same project, same concerns, written differently.

• "The 'Find a provider' action is the main thing patients come to the site to do, and on the staging homepage I had to hunt for it. It needs to be the obvious next step."
• "Referring physicians are a big audience for us, and the testimonials from other physicians are the thing that convinces them. Right now they're at the bottom and I'm worried referrers never get there."
• "The headline font reads like our old site, and part of the reason for this project is that the old site looks dated. Is there a way to make the type feel more current without going off-brand?"
• "We have eleven locations and patients often land on the homepage looking for the one near them. I don't see a path to that from the nav."
• "The hero image makes the headline hard to read on my phone."

Notice what changed. Every note now carries the reason. Your developer can read "patients come here to find a provider" and propose three ways to make that obvious, one of which might be better than a bigger button. They can read "referring physicians" and suggest a dedicated path for that audience instead of just moving a block up the page. They can look at the hero on a phone, see the contrast problem, and fix it properly instead of darkening the image and making the whole page gloomy.

Descriptive feedback leaves no room for miscommunication. Your developer knows what you see, what bothers you, and why. They can check your concern against the project goals, bring their own experience to it, and either do what you'd have asked for or propose something better. Either way, the decision is made with the whole picture.

I can't overstate the difference. Switching from prescriptive to descriptive feedback is the single biggest thing a client can do to improve a project, and it costs nothing. It's a night and day difference in the work and in how it feels to do the work.

How do you write descriptive feedback?

A simple structure helps. For each note, answer three questions.

What are you looking at? Be specific about the page, the section, and the device. "The appointment request form on the staging site, on mobile" is useful. "The forms" is not. If you're reviewing content, quote the sentence.

What's wrong with it? Describe the problem as you experience it, not the fix. "I had to scroll past three sections to find it." "The paragraph about insurance reads like it was written for clinicians, not patients." "I couldn't tell which fields were required until I submitted."

Why does it matter? This is the part most people skip and the part that matters most. "Because this form is how most new patients reach us." "Because the insurance page is the second most visited page on the current site." "Because our compliance team has asked that every form be clear about what's required and why."

You'll notice that writing the third part sometimes changes the first two. You sit down to say "move the testimonials up," ask yourself why, and realize the real issue is that the site doesn't speak to referring physicians anywhere. That's a much more useful note, and it's one you'd never have sent as an instruction.

What about feedback on content?

Content feedback has its own failure mode. On a site migration, you'll review dozens of pages of copy, and the temptation is to rewrite sentences directly in the document. Sometimes that's right. If you know the correct name of a procedure or the legally required wording for a disclaimer, just supply it.

But for anything about tone, structure, or emphasis, describe instead. "This page is for patients and it's using words like 'modality' and 'contraindication.' Patients don't know those words." That note lets the writer fix the whole page, not just the sentence you happened to mark. "The 'About' page leads with our founding date and buries the fact that we're the only pediatric specialty practice in the region" is better than rewriting the first paragraph yourself, because the writer can now fix the same problem everywhere it shows up.

One more thing about content: tell your developer or writer who the page is for. On a healthcare site, a single page can be read by a patient, a caregiver, a referring provider, and a pharmaceutical partner. Half of all content feedback comes down to "this was written for the wrong audience," and naming the audience up front prevents most of it.

How do you ask for feedback well?

This part is for the developer side, but it's worth knowing as a client because you can ask for it.

When I send a round of work, I say what kind of feedback I'm looking for. "This is a structural pass on the services section. I'd like to know whether the hierarchy makes sense for patients and whether anything is missing. Don't worry about colors or images yet, those aren't final." That focuses the review and saves everyone from a round of notes about placeholder photos.

I also say what's fixed. "The navigation structure was signed off two weeks ago, so I'm treating that as locked. If you want to reopen it, that's a scope conversation, not a feedback note." Clients are almost always relieved by this, because it tells them where the edges are.

If the person you're working with doesn't do this, ask them to. "What should I be looking at in this round, and what's already settled?" is a reasonable question and a good developer will have an answer.

What do you do when you disagree?

Descriptive feedback makes disagreement productive instead of personal. You've said what you see and why it matters. Your developer can say "I hear that, and here's why I'd push back," with their own reasons. Now you're two people comparing reasons, which is a conversation that ends. Prescriptive feedback produces "do it" versus "I'd rather not," which is a standoff that doesn't.

When you disagree, ask for the reasoning and give yours. If it comes down to a judgment call, the client decides. But most of the time, once both sets of reasons are on the table, the answer is obvious to both of you.

How do you move forward?

First, notice how you phrase things. Now that you know the difference between prescriptive and descriptive feedback, you'll hear yourself doing the prescriptive version. When you catch "make this bigger" on its way out, stop and ask yourself why. Write the why.

Second, set up the round properly. Ask what you're reviewing and what's locked. Review on the devices your audience uses, which for a healthcare site means mostly phones. Write all your notes in one document. Send it once.

Third, share this with the people you work with. If you're the client, send it to your developer and say this is how you'd like to handle feedback. If you're working with an internal team, send it to them. It's a small thing and it changes the whole project. A shared vocabulary for feedback means nobody has to guess what the other person meant.

You're paying for work and you want a good result and a good experience getting there. Good feedback is the cheapest possible way to get both.

To summarize

Prescriptive feedback prescribes actions. It leaves you feeling like you're directing the work and leaves the person doing it feeling like a tool. Descriptive feedback describes what you see, what's wrong, and why it matters. It leaves no doubt about what you want and opens the door for the person you hired to bring their experience to the problem.

For every note: what are you looking at, what's wrong with it, and why does it matter. One document per round. Ask what's being reviewed and what's locked. Name the audience for every page.

Do that, and the project gets better and so does working on it.

A note on where this came from: the idea of prescriptive versus descriptive feedback was first introduced to me by Paul Jarvis in his Creative Class. It stuck.