Client feedback that survives the brief
The review call goes well. Everyone is warm, the client says three things they like and two things they are not sure about, and you come off the call knowing exactly what to do. Three weeks later the work goes back and the client says, kindly, that this is not quite what we discussed.
The frustrating part is that you are both right. What they said and what you heard were the same words, and somewhere between the call, your notes, the handover to whoever actually did the work, and the version in your head, it became a different instruction.
Feedback decays in three specific ways
This is not a memory problem, which is why trying harder does not fix it. Feedback degrades in ways you can name, and each one has a different countermeasure.
It gets relayed. The client speaks to the account lead, who summarises for the designer, who explains it to the editor. Each pass is a person compressing something to fit what they think the next person needs. By the third retelling the feedback is short, confident and roughly half invented.
Preference gets promoted. "I am not sure about the blue" is a thought someone had out loud. By the time it reaches the file it has become "no blue", which nobody ever decided and which may not even be the view of the person who has to sign it off.
And the reason falls off. This is the expensive one. "Make the logo bigger" carries no information at all, and is the most quoted sentence in the industry. "It has to be readable at forty pixels on a phone" is a specification, and it survives being relayed, because anyone downstream can work out what to do with it even if the original instruction is lost.
Four things come out of a review
Before you can protect feedback you have to sort it, and most reviews produce four different kinds of thing that all sound identical in the moment.
- A direction: a change to what the work is trying to do. Rare, important, and usually said quietly.
- A correction: something that is factually wrong. A name, a price, a date, a legal line. Non-negotiable and cheap to fix.
- A preference: somebody's taste. Legitimate, but only binding if the person holds the decision.
- An aside: thinking out loud. "What if we did an animated version." Should never reach the file.
Almost every argument about creative feedback is really an argument about which of these four something was. The client believes they voiced a preference; you treated it as a direction and rebuilt half the work. Or they gave you a direction in an aside voice and you filed it under thinking out loud. Sorting them is the job.
The change list
What comes out of a review should not be notes. It should be a short document that goes back to the client the same day, and gets a yes before anyone opens the file. Recording the review is what makes it quick to write: the transcript, the summary and the list of what was decided all come out of Meeting Notes without anybody typing during the call.
Review to change list, same day
- Ask at the top of the call"Do you mind if I record this, so the change list I send you afterwards is accurate?" In our experience that framing gets a yes more often than any other, because the benefit in it is obviously theirs. Take a hesitation as a no and take notes instead.
- Watch the work land, do not transcribeThe thing worth having from a review is what someone's face does in the four seconds before they speak. You cannot see that from behind a notepad, and it is not something a recording will capture for you.
- Sort into the four bucketsGo through the summary and mark every piece of feedback as direction, correction, preference or aside. Ten minutes, and it is the step that decides how the next three weeks go.
- Write a reason next to every lineNot "increase logo size" but "logo to read at forty pixels — Priya raised it for the app store listing." A change with a reason attached can be executed by someone who was not on the call.
- Send it and wait for a yesThe change list is a small contract. Send it the same afternoon, ask them to correct anything wrong, and do not start the work until they have replied. A day of waiting is cheaper than three weeks in the wrong direction.
Here is what the sorting looks like on four real-sounding lines from one review, which is the fastest way to see why the change list reads so differently from the notes.
| What the client said | What it actually is | What goes on the change list |
|---|---|---|
| "Make the logo bigger" | A symptom, not a direction | Logo must read at 40px on a phone — showing two sizes at the next review |
| "I am not sure about the blue" | A preference, until the decision-maker repeats it | Blue flagged by Sam; not changing it pending Dana's view |
| "That price is out of date" | A correction | Price updated to the March rate card throughout |
| "What if we did a whole animated version" | An aside | Noted, out of scope, not started |
Where the list lands matters almost as much as what is on it. In an inbox it is one email among sixty. In the tracker the studio actually works from, each line is a task with a reason attached that whoever picks it up can read. Ona connects to Notion, Slack, Asana, Linear and Google Drive, alongside Google and Outlook calendars, and the current list is on the integrations page.
The copy that goes inward
The change list goes to the client. A second copy goes to whoever actually does the work, and it needs one thing the client's version does not: what you decided not to pass on. The editor does not need the aside about an animated version, but they do need to know it was raised and parked, or it arrives as a surprise in three weeks and looks like new scope.
If that person was not on the call, let them read the summary themselves rather than hearing your account of it. It takes them ten minutes, it takes you none, and it removes an entire compression pass from the chain the feedback has to survive. The relay problem is mostly solved by deleting relays.
Three weeks later, when it is disputed
Sooner or later a client will say they asked for something you have no memory of. The useful move is not to produce a transcript, which reads as defensive and makes everyone feel worse. It is to check quietly first. Ask Ona answers across the reviews you have recorded, and every claim in the answer carries a link back to the review it is drawn from. You can find out privately whether they are right before you decide what to say.
Sometimes they are right and you missed it, which is worth knowing privately and worth conceding quickly. Sometimes it was an aside that you correctly did not act on. And sometimes it never came up at all, which makes it a scope conversation instead of a quality one, and a much easier one to have when you are certain.
The argument about what the client asked for has mostly stopped. The change list goes back the same afternoon, they correct one line of it, and that corrected line is what we build against.
Joss T., Creative Director, design studio
Working with the brief you already have
A change list is an amendment, which means it needs something to amend. Reviews that drift are usually reviews where nobody reread the brief first. Five minutes before the call, read what the project was for, so that when a direction arrives you notice it is a direction. The Ona for creative professionals page covers how the rest of a studio's week fits around this.
The other habit worth forming is numbering. Give each change list a number and a date, and put at the top of it which earlier one it replaces. Creative work accumulates contradictory notes by default — a brief, three reviews and a late email can all be live at once — and the only defence is that anybody picking the project up can tell at a glance which set of instructions is the current one.
The parts this cannot do
It cannot tell you which feedback is right. A client is not always right, and part of what they are paying for is your willingness to say so. A change list makes disagreement specific enough to have out loud; it does not settle anything on your behalf.
It records what was said, not what was shown. This is the real limitation in creative reviews, because half of a review is someone pointing at a screen and saying "that bit, there". A recording of that is a recording full of the phrase "that bit". Either say what you are looking at out loud, or note the frame and the timecode yourself while it is on screen.
It also hears volume rather than authority. The person who talked most in the review is often not the person who signs the work off, and a summary will treat them equally. You know who holds the decision; the record does not.
And it will not chase the yes. A change list that nobody replied to is not approval, however reasonable it was. If the work is expensive to undo, wait for the reply, and if the reply does not come, ring them.
When the feedback gets complicated
Most of it. The change list is what does the work here, not the recording, and you can write one from your own notes on the same afternoon.
What you lose is the ability to check a disputed line later, so write the list closer to the call than you otherwise would.
Do not resolve it yourself. Put both positions on the change list with the names against them and ask the person who signs off to pick one, in writing.
Teams sometimes read that as passing the problem back. It is the opposite: you are making a decision that was always theirs actually visible to them.
That is outside the record and it always will be. Paste it into the change list yourself, sorted into the same four buckets, so the project has one document rather than two channels.
One list, dated, covering everything since the last one, is worth more than perfect capture of any single source.
Keep the feedback they actually gave
Record your next review, sort it into the four buckets, and send the change list back before the end of the day.